Long time...

So, I guess it's been ages since I made a blog post. A lot has happened in that time:

• We released Purple Plugin Pack 2.2.0 without the ignorance or smartear plugins being properly fixed and included. It's not looking particularly promising for 2.3.0 either.
  
• We adopted new plugins into the plugin pack:
• dewysiwygification - An old plugin written by Tim Ringenbach
  
• enhancedhist - A plugin written by Andrew Pangborn.
• timelog - A plugin written by Jon Oberheide.
• buddytime - A plugin written by Martijn van Oosterhout and Richard Laager.
• Sean Egan promoted me to Pidgin developer.
• I rewrote over half of the Pidgin man page to reflect the current features present in Pidgin.
• I've continued to slack off on the Guifications 3 project.
• I hatched a plan to remodel the living room in our house without letting my parents know. I'll probably be yelled at endlessly for this one.

I've also been trying to watch more movies. Recently I've watched Dangerous Minds, A Beautiful Mind, and Mentor. All interesting movies in their own right. I also started to watch Tin Man, the new Sci-Fi channel reinvention of The Wonderful Wizard of Oz. So far I've only seen the first part, and it is quite a trip. I'll be catching up on it when I have a chance to watch my backlogged DVR stuff this weekend.

At any rate, time to go to work, I suppose. Maybe I'll post something later.

Purple Plugin Pack 2.1.0 and 2.1.1; Plans for 2.2.0

Well, last night I released two versions (yes, two!) of the Purple Plugin Pack. The initial release was 2.1.0, which included a new plugin and the completion of a plugin that's been in our tree for ages. However, what I did not catch in this initial release is the fact that there were files missing from the convbadger plugin that would prevent it from building on any platform. I didn't want a duplicate tag in our monotone database, so instead of trying to rerelease the same version, I just did a quick micro version increment, added the files, tested the new version, then tagged and released 2.1.1. As a result, I called 2.1.1 "The rekkanoryo is an idiot release" to indicate it was largely my stupidity that caused two releases in such close proximity.

That said, I'm sure I'm going to hear complaints because I signed the packages. With the 2.0.0 release, there was a complaint because I signed the package with my GPG key, which has no signatures. Because of that I'm reasonably sure I'm going to hear complaints again about my signature being worthless because there is no relation to the web of trust. To that I have one response--find me a key-signing party within a 45-minute drive of my home and I'll show up with all the identifying documents I need for someone to verify my identity and sign my key. Otherwise, shut up and don't ever complain to me about it. I live in an area where technology seems to be a foreign concept, and anyone having a clue about GPG or any other sort of useful technological tool just doesn't happen. People here have trouble determining whether a website is SSL-secured or not, let alone something more complex. I work a full-time job which does pay my bills but doesn't provide me with the luxury of enough money (or time off at the correct times!) to travel to random conferences where I would be presented with keysigning opportunities. Because I attended a local school for postsecondary education, I didn't exactly gain exposure to any keysigning opportunities there either.

With that out of the way, I'll get to my plans for Purple Plugin Pack 2.2.0. I have a few things in mind:

1. Merge autorejoin and irc-more. Autorejoin is IRC-specific, as is irc-more, so there is no need to have two plugins whose function is to enhance IRC.
2. Add processing capabilities for libpurple's blist.xml file into the listhandler plugin so that users who have managed to destroy their server-side buddy lists can import their backed-up blist.xml file to restore the server-side list.
3. Split the alias list support that was patched into listhandler into its own files.
4. Hopefully finish the smartear plugin integration work I've had on the back burner for way too long.

I'm already working on item #1 there. At this rate, I might have the entire list done in weeks instead of eons.

The downside to popularity

As many people reading Planet IM know, I am a developer on the Guifications project and the Purple Plugin Pack, and a "Crazy Patch Writer" for Pidgin. Over the course of my time with these projects, we've seen our fair share of...well, pretty much everything. New developers; departing developers; people stepping back due to frustrations, busy schedules, etc.; and the biggest of them all, spam.

Not too long ago, Guifications and the Plugin Pack were hosted at SourceForge. Back then, things were pretty good--our website was pretty well static, although it was done in PHP so we could do cool stuff like pull in our SourceForge project news feed to use as our home page and have extensible menus with XML and whatnot. We also operated under one project at SourceForge. Over time, we (Gary most of all) became displeased with and irritated by things that we saw happen and things we experienced while there, and we eventually decided to leave SourceForge for self-hosting.

When we began self-hosting, Gary started renting a virtual private server from Steadfast Networks while waiting for a dedicated server to become available. It was a bad time for us to have been VPS customers, though, as performance was bad due to overloading. We were finally able to move to a dedicated box and couldn't be happier with it. I personally rented a VPS from them as well, and initially had similar frustrations. In the 9+ months since we've had Guifications and the Plugin Pack hosted on the dedicated server, the VPS performance issues have been resolved. The VPS I have is fast enough that I can barely tell the difference between it and a real box.

With the move to self-hosting, we needed something that could replace SourceForge's trackers. The solution was simple--we'd heard quite a few good things about Trac and tried it out. We've been with it ever since, and Gary even went to the trouble to update the SourceForge to Trac migration script to migrate our tracker items into tickets.

Over time, we discovered issues on one of the two Trac environments we were running--spammers were attacking us. At first it was comment bombing, where the spammers would flood us with links in comments on tickets--primarily closed tickets, but any ticket was a target. After the third attack, we cracked down and locked our Tracs to the point that only developers could open tickets or edit the wiki. This caused some friction in our user community, because we had bugs that no one could report and no one could make feature requests. Our apache logs showed a continued series of attempts to attack, growing similarly to our popularity with Pidgin users.

Thankfully, several people pointed us toward the Spam Filter plugin. It's a great plugin because now we can have authenticated users making ticket submissions, comments, wiki changes, etc. but at the same time we have blacklisted regular expression filtering, IP throttling, evaluation via Akismet, and external links filtering. Since installing and configuring this plugin we've had a whopping three successful spams. The monitoring feature is useful for adding blacklisted regexes, as well.

The only problem with the spam filter is that it requires work. That is, it's not perfect. On occasion it will have false positives, although this has happened significantly less frequently since we moved to requiring new registered users supply a first name, a last name, and an email address at the time of registration. Also, on occasion, we have to teach it about new bad expressions by editing the BadContent wiki page. It is sometimes funny, though, to see the karma scores assigned to some of the spam attempts. The karma can go wildly negative, especially if multiple filters are invoked multiple times on the same message. Currently the record for our Tracs is -41, due mostly to external links subtracting 35 points from the post's initial karma.

And this, my friends, is the downside of popularity--the spammers are out and ready to strike, and we have to fight them at every step of the way. Thankfully, for every group of spammers that don't deserve the privilege of using a computer, much less the privilege of an internet connection, we also have at least one talented programmer creating a tool to help in the battle against spam. It does make you wonder at times, though, what the spammers can possibly gain from attacking us.

Random Ramblings

This blog post is going to be a bit of . . . well, quite literally, random rambling. I guess the title of the post should make this a dead giveaway, but I'm in a bit of a weird mood tonight so I'll just get to the topics I was thinking of.

I'll start off with music. My tastes in music are a bit eclectic in some respects, and usually downright unpopular. I was raised primarily on country and oldies. In the US this means late 80's and 90's country music, which isn't a whole lot different from pop, and music from the 50's and 60's that fit into pretty much any genre but country. My one older sister (I have two older sisters and no other siblings) has always liked music in general, and so growing up with her around I occasionally picked up on some other forms of music, including rock. I find myself now, at 25, to be a somewhat picky music lover. For example, I despise rap, although a few mainstream country songs that have introduced some rap elements fall within my range of acceptability. My usual fare (as is quite obvious from my Last.fm profile) is country, although I branch out into Bon Jovi, Kelly Clarkson, and others. There's even a bit of Japanese music in there for good measure.

There's nothing specific that I look for in music to make me say I like it or I don't. I usually disagree with the majority of critics, although exceptions to the rule have happened. For example, the Dixie Chicks released an album called Taking the Long Way, their first album since being shunned from the music world following their criticism of President Bush (who I was stupid enough to vote for in 2000 as an 18-year-old first-time voter because I thought Gore was too stupid). Several critics loved the album, giving it very high praise. I too enjoyed the album. It had a pretty solid pissed-off tone throughout, while still covering a diverse range of stylistic influences and topics. Wow, I sound like a critic myself now. I need to stop that.

At the same time as I agree with some critics on select albums, I often disagree with critics and find myself quite liking albums that the critics have written off as pathetic. Essentially my musical taste runs the gamut from Neal McCoy's fun "Billy's Got His Beer Goggles On" to Sophie B. Hawkins' "The Darkest Childe", hitting numerous high points on the way, such as Massive Attack's "Teardrop" (House fans will recognize this as the theme song) and the entire body of Martina McBride's recordings.

The real point I am getting at here is that while I may gravitate towards some artists or styles, my taste is not limited to such. Even so, I've taken quite a bit of flak over it. Coworkers, codevelopers, etc.; you name the person, I've gotten remarks from them ranging from well-meaning jabs to acid-infused comments. I don't really care what people think of my musical tastes; I don't ask them to pay for the music I listen to, nor do I force them to endure it. It's my life, my money, and my ears. It's a legal practice, so I will use them in the way I see fit. I also won't take any crap from anyone over it.

With the music topic pretty much resolved to my satisfaction, I'll move to the other topic that I had in mind when I started this post--development fatigue. Every developer at some point reaches the point of being fatigued from the process. Every developer has his or her own breaking point, so there's obviously no sure-fire way to tell when this is going to happen. The important thing here is that we realize our limitations, push them at the appropriate times, and step back to take a breath when needed. The point of fatigue is the most important time at which to step back and breathe. If we don't stop at that point, burnout will follow soon. Stepping back before burnout happens and taking the needed rest and relaxation time away from the world of computers and code is an important step for both our mental health and our continued productivity as developers.

If a developer allows him/herself to burn out, it will likely take longer to "recover" from the burnout and return to productivity. If development projects are taken too personally, that burnout can also spill over into other aspects of life quite easily and cause a whole host of problems. Furthermore, once you've burned yourself out once, it's easier to do it again.

This all seems pretty obvious, right? Really it is; it just isn't a thought that occurs to us frequently. These are all pretty easy things to overlook. They're important, though, so we should try to be a bit more aware of them. When we're feeling particularly stressed over our projects, it's time to step back and go read a book or take a walk or something else relaxing. Maybe even do some manual labor like mowing the lawn or doing a home repair/improvement project. Or kick back, watch TV, and be lazy for a while. There's nothing wrong with any of these, most especially if it helps you take your mind off the problems for a while so you can come back later with a clearer head and attack from a different angle.

Several people have noticed the C Plugin HowTo that I've been writing on the Pidgin wiki. It's far from complete--I'm less than halfway through the libpurple part, and I intend to give a brief overview of writing UI-specific plugins for Finch and Pidgin. This project, though, is an exhausting one for me. It takes a lot of thought to write a how-to document that I'm willing to publish, with or without my name on it, and I'm trying to strike a balance between people who are starting out like myself, with a basic understanding of the C syntax and concepts, and those who have a firm grasp on it all but just need to see the structure of a plugin and how to interact with the libraries and application. For the most part I'm striking this balance by focusing solely on the former class--the ones who started like me. The latter class is generally intelligent and/or experienced enough to read the API documentation, use existing code as examples, and come away with the necessary understanding of what needs to be done. This isn't to say that the inexperienced or beginning plugin developer is stupid; it often takes a bit of orientation for these less experienced developers to be capable of finding their way through the plugin API.

Being an exhausting project, this how-to series has gotten me to the fatigue point more quickly than I expected. I realized this, however, and have taken the appropriate steps backwards to try to catch my breath. I'm still poking and prodding here and there, but so far the mini-vacation from wiki editing is proving to be a good thing, and I think I'm ready to start attacking the wiki again. I hope to pound out the Request API how-to, which will likely be the hardest one for me to write, this weekend. If it's not done by Monday, I will finish it the following weekend.

On an unrelated note, I'm messing around with CentOS 5 on a test server at work for use as replacements for our public DNS servers running older versions of the OS. The installer impressed me by having more granular package-level control, although I'm still having to go through and rip out a ton of crap that a public DNS-only server with ssh for the only allowed remote access has no need for. Once I have it pared back to bare minimums, the real fun starts.

Now I think I'll go to bed, since I have to be awake in two hours to go to work.

Everything Changes (a.k.a Pidgin-SNPP is dead; long live Purple Plugin Pack!)

Ok, I know the title of this post is a bit lame, but you'll have that. Deal. :-P

The title is supposed to be an obvious reference to the maintainer of the Pidgin-SNPP protocol plugin for the Simple Network Paging Protocol has accepted a long-standing invitation to bring his plugin to the Purple Plugin Pack.

rizzo, the maintainer of pidgin-snpp, had mentioned that he needed to set up a Windows Pidgin build environment and work on his plugin. I reextended the offer to join the Plugin Pack by saying that the plugin would already have been released, and rizzo accepted. We're working on making the plugin compatible with Pidgin 2.x.y now.

Hopefully we'll release again around the time Pidgin does, new plugin and all. :)

Projects, Progress, and Competition

In my last post, I mentioned that I was wanting to push a release of the Purple Plugin Pack. Hard to believe it's been over two weeks ago already. Friday night, just before midnight, I finally released Purple Plugin Pack version 2.0.0. We changed our versioning scheme in the process too. The biggest, and most important, thing to mention here is that our major version will always match libpurple's. The other numbers have their significance as well, but they're not all that important--users should always be using our most current release. This release was significant in a number of ways--we introduced a few new plugins, added new features to several plugins, and also fixed a number of bugs.

In other areas I'm involved with, progress continues, even if it is slower than anyone would like. Gary's work on Guifications 3 has had some progress, and Pidgin has had some progress toward a 2.1.0 release. I wouldn't call this progress significant yet, but hopefully things work out with both projects.

For Pidgin, I'm hoping the infopane Sean is implementing improves significantly before the release of 2.1.0. If it doesn't we're never going to hear the end of it, and a ton of people are going to demand plugins to fix the many deficiencies currently present. The issues are numerous:

• Infopane-as-single-tab introduces dancing UI. This is very bad. If I have one conversation open, the infopane takes the place of the tab that used to always be displayed. When a second tab opens, the notebook magically appears, shrinking the history area and throwing off the history pane's scrolling. Keeping a second tab open at all times to avoid this dancing UI is stupid at best and a pathetic hack at worst.
• There is still no tooltip for the infopane. The whole point of the infopane was to provide blistnode-like functionality in the conversation window. We don't have any of this functionality except a status icon and buddy icon yet. No tooltips, no context menus, nothing.
• It appears the infopane will be fixed at the top of the window. I disagree with this design decision, but a preference for this does seem overkill. I'm hoping a plugin will be able to change the widget order so that I can have a plugin to move the infopane below the history pane like Sadrul had in his screenshots of changes he had made.
• Window size history is constantly being screwed with. It seems to me that I was once able to have my chat and IM windows (since I had them separated via the tab placement options) have their own sizes be remembered correctly. Currently I find myself having to resize every window when one gets created, because the most-recently-resized window seems to win out with remembering size.
• Not strictly related, but the argument about the status icon on the tabs is somewhat flawed. The close button on each tab wastes just as much space on the tab as the status icon yet provides no useful information to the user. I still know several users who dislike the close buttons on the tabs, even after nearly three years living without them (the prefslash days of 0.78 or so killed the ability to turn this stuff off, as I recall). I strongly advocate a boolean preference labeled "Use simple tabs", which defaults to false. When set to true, both status icons and close buttons would not be shown on the tabs.

Don't get me wrong--on the whole, I'm happy with the direction Pidgin seems to be moving in. Simplicity and consistency without getting in the way too much. This is a very elusive and quite respectable goal, but getting there is a painful process which unfortunately requires a reasonable amount of experimentation and willingness to give into what the other developers and contributors want.

Speaking of Pidgin, Luke Schierer made a blog post the other day mentioning forking. In it he specifically stated that I was correct in closing a ticket on the Pidgin Trac that was soliciting a fork. I would like to take this opportunity to thank Luke for his support on my actions. Thanks, Luke. I may have been condescending and/or rude to the user who opened the ticket, but I feel justified in my response, especially given that the user actually agreed with me on all but one of the points I made.

When I started this post (roughly 0110 US EDT), I had initially intended to complain about the complaints I see on the Pidgin Trac. However, I've proven that I'm not much better than the users complaining in the tickets. Instead, I'll comment on something that I wish a few more users understood.

Occasionally a user in a ticket will have a complaint that, while valid, the user tries to justify by comparing to so-called competing IM clients. I would like to note that Pidgin is not in competition with any other IM client. There is more than adequate room in the IM client space for the myriad of IM clients that exist. This is simply proof of a point that Luke Schierer made, which is that no single IM client's user interface can satisfy everyone. Yes, Pidgin lacks features other clients have, such as default keybindings for smileys (a triviality to begin with that can be resolved within the realm of reasonability with .gtkrc-2.0), voice and video conversations, or more configuration options than ten copies of the Linux kernel combined. If the user interface doesn't meet your needs or wants, you probably should be using another interface. Ideally we'd love to see many different clients using libpurple as the backend code, enabling libpurple to serve a much wider audience in a better way by providing the facilities for others to reinvent the UI without having to reinvent the entirety of the backend.

On another Pidgin-related note, we've recently had a number of complaints about the lack of documentation on plugin development. Apparently the insanely large body of existing documentation--the doxygen docs and all the existing plugins--is not sufficient to satisfy some would-be plugin developers. In an attempt to address this, I've started to write a basic how-to series on the Pidgin Trac's wiki. I started by taking Gary Kramlich's existing start to a C Plugin HowTo and migrating it to the wiki, and I am now adding additional "chapters" to it. I'm not necessarily following any fixed format, but I'm trying not to half-ass this thing. My hope is that when I'm finished, I'll have a solid set of documents and accompanying plugins that will silence this set of complaints.

I think I'm done ranting for now. I might have more later.

The frustrations of development and work

The last week or so has been an interesting love-hate relationship between me and all of my assorted projects and my regular job. I'll try to summarize:

• The Purple/Pidgin Plugin Pack
• I had wanted to push a release of this on June 21. This didn't happen for a couple of reasons. Stu Tomlinson wanted to test, which was a quite understandable request. For this reason I delayed until June 23 (my birthday, too!). On June 23, it was difficult to find the time to do anything code or computer related because of the family. Ok, no problem, let's delay one more day. Well, Sunday I realized I had no environment in which to compile our plugins for Windows. This is a no-go any time we release because literally within half an hour of release we get complaints about the lack of a Windows package. Well, long story short, thanks to VMWare 6 and its VNC server capabilities, I now have a Windows Pidgin Build Environment and I'll be using it to build the plugins whenever we do release.
• Internet Banking
• At work, we performed a migration on Wednesday, June 20. We used to host our internet banking system in our own datacenter/server room. As a way to potentially save money in the long term and also dramatically reduce the liability the bank shoulders for the security of the internet banking site, we outsourced the IBS to the datacenter run by the company that provides our IBS.
  
• The actual site migration was trivial. Everything else, on the other hand, has been a royal pain. We've been on the phone with our conversion "experts" every day over the issues that just don't go away. The daily reports and end-of-day processing is generating tons of errors, flagging customers as overdrafting with their transfers when the customers in fact have more than sufficient funds, and for a time today the application that interfaces with the bank data for new account entry and password resets and whatnot refused to work at all. Our onsite person who enters new accounts into the IBS and does password resets and whatnot is frustrated enough that I wouldn't be surprised if she quit over it.
• Bank conversion and consolidation
• The bank I work for is owned by a holding company that the bank's board of directors formed in the early 80's as a way to buy other banks and run them as separate entities under one corporate umbrella. When the holding company was formed, it bought another bank that had a couple locations of its own. In 1998, a third bank was bought and added to the mix. In 1999, the bank I work for and the bank purchased in the 80's were consolidated into one larger, stronger, and more profitable institution. The third bank went along on its own quite happily. Last year, however, there were some massive losses at the third bank and their board of directors voted to allow my bank to take them over. Now, effective July 1, both banks will be divisions of the same bank in order to maintain their separate identities. Routing-transit numbers will be retained and everything. Processing will still be separate.
• To facilitate what management wants, a contractor has been brought in to develop some conversion tools and some reports that can combine data from both banks, as well as some new replacement programs to work around some limitations of our current core processing system's security model. This contractor is actually very good and very efficient at what he does, which was quite a pleasant surprise. All of the development needed to satisfy management has caused tremendous headaches, and will only get worse as this weekend approaches--this end of month is the end of the quarter, and also a double processing night (the 1st of the month has to be seen as a business date for the vast majority of core processing systems, and it's generally easier to run two processing dates than to use the "combined" or "split" update features present). To top it off, the second processing date, July 1, is the start date for the merger. Fun, fun, fun.

At any rate, business as usual for the working guy--headaches, headaches, and more headaches!

Hopefully I'll be pushing a plugin pack release this week!

Projects for the Banker

Given that I called my blog "The Flaming Banker" (in reference to the fact that I work for a bank and I start more than my fair share of flame wars), one would think I'd make a few more posts leaning toward the "flaming" part of the name, right? Well, apparently I'm incapable of doing too much of that. Every time I have something that I could rant about here, I end up distracted long enough that I'm no longer irritated enough to post it here. I just can't hold a grudge or stay angry for extended periods of time--don't get me wrong, that's almost certainly a good thing.

But enough of that. :) Let's get to the title of this post, shall we? Projects for the banker.

I recently, for some unknown reason, agreed to implement a feature in my listhandler plugin for libpurple. This feature would allow the importing of NotesBuddy exported buddy list files with a .dat extension. I spent a couple hours total on it before giving up on it as a useless, impossible task. My reasons for giving up on this were that I do not use sametime, nor do I have access to a server that provides the sametime protocol. The format was also completely incomprehensible to me.

I also received a patch for listhandler to implement the ability to export an XML list of aliases and then import said list without actually adding buddies to the list. I'm still undecided on this (mainly because I'm lazy and don't want to spend the time to fix the deficiencies I see in the implementation) but will probably rush to squeeze it in before Thursday, in hopes that we'll release the plugin pack to coincide with Pidgin 2.0.2.

The Pidgin FAQ...that's an interesting labor of torture and love. Luke Schierer simply does not have a block of time he can dedicate to sitting down and pouring a ton of documentation into the wiki at developer.pidgin.im. Nor does Stu Tomlinson, original author of the SSL-specific "FAQ." Stu nominated me to transcribe the SSL information to the wiki, which I was crazy (stupid?) enough to do. It took several days, on one of which I lost several hours' work and had to reconstruct it, but I managed to get it done. Following that, I noticed that what Luke had managed to put in the wiki was a bit anemic compared to the old FAQ. As I said, he simply does not have enough time to do all the bajillion projects that have resulted as a side effect of the name change and the migration away from Sourceforge. Given these two facts, I decided to pitch in and help beef up the FAQ on the wiki with more useful info. Amazingly, in just a few short hours (spread across a few days) I managed to migrate over half of the old FAQ to the wiki. I still have more questions I need to move over, and a few I think I need to add, but the most important stuff is there.

The downside to Pidgin having a wiki now is that anyone with an account can edit the wiki. I'm not so sure I like this idea. I was opposed to it from the start, then grew indifferent, and now am starting to come back to the opinion that it's not worth the trouble. As I mentioned, I spent several hours on the FAQ transcription. A couple days after I made my last changes, someone came along and butchered the careful wording that both I and Luke had previously placed into some questions, and added a new "question" that was completely incomprehensible. It took me literally half an hour to figure out what the person was trying to communicate. I have, however, fixed the offending entries.

I'm not going to bother lobbying for more restrictive wiki permissions, as I know it's a losing battle. There are apparently benefits to this approach that I'm not seeing right now. I've also started enough arguments within the Pidgin camp, and don't particularly feel like starting another.

And now let's get to the mother of all projects--Guifications 3. Gary Kramlich created this brainchild before I even became involved with his projects, and it's still in development. While Gary is frustrated with this (and rightfully so, as the rest of us developers have been mostly lazy bums in the process--no offense intended), he and I both realize this is probably for the best in the long run--as Gary has progressed, he's found some major flaws in his initial design that he's able to fix now, while we're still pre-alpha and mostly unusable.

Now, Gary would be quick to discredit my classification of myself as a "lazy bum," as he did last night in an IM conversation when I called myself useless. He does correctly point out that I have done a bit here and there and also taken some of the administration load from him, which helps him because it frees more of his time to work on the hard stuff in Guifications 3. I also try to take on the support role as much as possible when users come to us with issues involving Guifications 2 and the plugin pack.

At any rate, however, Gary decided that he needed to change some API by renaming GfFeedPool to GfFeedManager. He also needed to design a new API component, so he asked me to handle what I could of the Pool -> Manager transition. I spent a couple hours on this, more than Gary would have, I'm sure, but the end result is I did finish the conversion. I also found a few issues that resulted because Gary had split some functionality out of gflib and into gflib-ui, but had forgotten to update #include statements. Because of this work, I built and installed over half of Guifications 3, which roughly corresponds to how many of its modules are even remotely close to hackable, usable, or functional.

After all this discussion of Guifications 3, I'm sure some people are going to wonder what Guifications 3 is and why it's taken well over two years to develop while still not producing a usable "product." Without giving too much away, I'll try to answer that here. Guifications 3 is a modular framework for notifications, similar in purpose to libnotify and Growl, but with a much broader scope. We make heavy use of dbus by default and will support xmlrpc and a variety of other communication methods. And yes, that means that we're expanding our horizons beyond Pidgin. Far beyond. Yes, I know that's horribly vague, but until we've reached "hackable" there's not much point in laying all the cards out.

Also, since my last post I've had the pleasure of talking with Jennifer twice. She seems to be doing better than she was, but seems to be still very deeply hurt over the events that led up to our five-plus-hour conversation. I'm glad to see, though, that she is taking a sensible route on the matter and somewhat distancing herself from the situation. In the end it will make a huge difference for her, as she'll know some different aspects of life she hasn't yet explored. She will end up a much stronger person because of this, and I'm sure I'll find myself respecting her even more than I do already. Indeed, this too is intentionally vague, as I do wish to protect her privacy and avoid causing her any pain myself.

At any rate, I now need to go to bed.

Paying for friendship

By reading the title of this post, I'm sure someone's going to get the wrong idea about this post. The title is actually a joke cracked by a friend of mine in reference to something I'll explain a bit later in this post.

Wednesday night was a good night at work in many ways--I was able to get my work done quite early and fast, and I learned a few things about how NCR MP-RAS handles different terminal types, including AT386, its default term type for /dev/console. (If you haven't gathered by now from reading my posts, I'm a UNIX geek of sorts.)

Seeing as how I had to get up early to go to work Thursday morning, I went home and eventually went to bed. Thursday was an interesting day for me. I flew through an absolute ton of stuff and accomplished more in a single day than I normally do in three. Between Wednesday and Thursday alone it felt like I had worked well over a full work week.

Thursday night, I went home, ate and took a shower, and proceeded to go about my Thursday night routine of playing catchup on all my trac email from Pidgin, a usual inflammatory comment or two in the Guifications IRC channel, etc., when I saw a notification pop up to say that a friend of mine had signed on. I looked at the notification and discovered that it was Jennifer, a friend from New York City who I hadn't had the pleasure of talking to in 224 days (according to Stu Tomlinson's lastseen plugin for Libpurple).

I proceeded to talk to Jennifer and was astonished at how open she was being with me. In my previous conversations with her spanning over the last six years of our lives, Jennifer has never been one to discuss her personal life so openly and freely. It was an amazing thing to finally be let into her world completely and really find out what's been bothering her. We talked for over five hours straight with me attempting to help her through her problems, or at least give her food for thought. I think it's safe to say I gave her plenty of food for thought, but I haven't really helped her much other than being a sounding board. I wish I could have done more for her; it always breaks my heart to see her sad or hurt. She finally decided to head to bed around 1 AM US EDT; I too called it a night at this point.

Friday morning I woke up at 4:30 US EDT to my alarm because I had to go print statements. Dead tired, I drag my sorry rear into work at 5:48 AM US EDT and have a host of problems, including a leaking toner cartridge for an HP LaserJet 5SiMX printer, a bad drum in the same leaking cartridge, statements that needed reprinted because of the bad drum, and a host of internet banking and voice banking problems. Essentially, everything that could go wrong did.

To make matters worse, when I got home I found out that my wireless router (a Linksys WRT54G version 2--one that OpenWRT would run on quite happily) was no longer forwarding packets from the outside to my internal boxes. I started investigating and in the end unplugged the router and plugged it back in to power-cycle it. After that, the WAN interface worked, but the router refused to route packets between the inside and outside worlds. I unplugged the cable modem from the router and attached it to my Dell Inspiron 6000 laptop and everything magically worked. So I unplugged the router again and let it cool off for a while. Once I plugged it back in, the WAN interface stopped working entirely. The switch ports are getting flaky too. The only thing working reliably is the wireless interface. So, for the time being, I'm stuck with only one machine having internet access, since i'm not willing to turn this laptop into a router.

I discussed the router problems with my friend Brandon, who had similar issues a couple weeks ago except in reverse (wired worked but wireless didn't) and his were fixed by a reboot and switching to a wired connection. Then I told him about the problems at work and the conversation with Jennifer and how long it had been since I talked to her, and he comes off with "You're just paying up for that friendship now." We laughed and that became the basis of this post's title. :)

All in all, given that I've been able to talk to Jennifer again, all the trouble is worth it. I've missed Jennifer more than I realized I could, and her friendship is worth more to me than any I've had in quite a while. Definitely worth the trouble. :)

Maybe I'm not such an idiot after all...

I finally got my powerbook back! Yay!

Even nicer is that my boss in on vacation this week, meaning the workplace is more peaceful for me. It's also given me a chance to get caught up on some miscellaneous tasks at work. Once I crash for my four hours of sleep before heading back to work (really, kids, don't get a job where you work part of the week on a late shift and then turn right around and do an early shift the rest of the week--it really sucks!), I'll find myself going to work to play round with CentOS 4 in a virtual machine (VMWare player is a godsend at times, especially when you work with someone who has access to Workstation to create the virtual machines you need for testing purposes).

I know someone will inevitably want to point out that CentOS 5 is released. I'm well aware of this, but I haven't yet had the chance to nitpick CentOS 5 and get a setup script to customize it directly to our needs. Until I can do those two things, it's largely useless for us (no offense intended to anyone involved in the project!).

Now if I could just con my boss into installing rxvt-unicode termcap stuff on the UNIX box and letting me run Linux on my work machine...

Separate, but not equal? No more.

Many Pidgin users who have tried to seek support on IRC know that the inhabitants of #pidgin have historically been quite hostile to Windows users landing there. The standard response was to always send the person to #pidgin-win32. Well, this has all changed. I'll come back to this.

Gary Kramlich, a friend and the founder of the Guifications project, took offense to some comments made in Pidgin's XMPP conference. While in retrospect I'm not sure whether Gary overreacted or not, it prompted Gary to announce that he wanted to take a break from Pidgin development, and that he wasn't sure if it was going to be a permanent step back. This is a matter on which I am as of yet unsure of his decision.

Part of the discussion that triggered Gary's announcement was a reiteration of the desire some members of the development team have to kill off Windows support in Pidgin. Note that this does not mean they want to discontinue Windows support for libpurple--in this case they are preferring that a native client would appear, much as AdiumX did on Apple's Mac OS X platform. I, too, would like to see a native Windows libpurple client happen. This is another issue I'll come back to shortly.

As a result of some of the discussion that ensued after Gary's e-mail stating his desire to take a break, it was proposed by Ethan Blanton, another Pidgin developer and supporter of the removal of Pidgin Windows support, that #pidgin-win32 be closed and all support take place in #pidgin. In many ways this proposal makes a lot of sense. As Ethan rightly pointed out, we often ended up with Windows users in #pidgin, and we would need to redirect them. Some of these users grew quite frustrated as it was often difficult to receive useful responses in the Windows channel in a timely manner, if at all. As others have pointed out, GTK+ has improved vastly on Windows to the point that there are few Windows-specific bugs to worry about. For some time now, the distinction between #pidgin and #pidgin-win32 has been artificial and unnecessary. There were at least two vocal supporters of the closure of #pidgin-win32 who made their position completely clear. I didn't have an opinion one way or the other but was quite shocked that it was actually being considered.

Now #pidgin-win32 redirects to #pidgin, and we can all bask in the elimination of the IRC segregation that once ran so deeply in the Pidgin camp. Now to complete the goals of making Windows support less of an issue, we simply need a native Windows IM client utilizing libpurple and remaining similar enough in look and feel to Pidgin that people will feel comfortable in switching.

I have wanted to have a project to develop a native Windows frontend for libpurple since before the rename and the tree restructure. When Sadrul Habib Chowdhury began his Google Summer of Code project to implement an ncurses-based UI around the then-nonexistant libgaim, one of the goals of the project was to complete the core-UI split and restructure the tree so that libgaim and Gaim itself were completely separate entities. With the completion of this project, the source tree was restructured. Following the name change, we now have Pidgin, Finch, and libpurple, all separated cleanly in the source package. This means that libpurple now officially exists and is possible (and now much easier) to develop against. When Sadrul started his project, I began to formulate the idea in my mind that I really wanted to have a native Windows UI for libpurple to eliminate the remaining deficiencies
with Windows GTK+.

The problem with my desire for said Windows application is that I don't know how to develop any graphical applications for Windows. Because I'm ignorant in this area of development, but want to be involved, about the only role I could serve is Support, Quality Assurance, and sounding board. Consider this a call to arms for capable developers. Contact me via the e-mail address listed here if you're really serious about doing this.

Best of luck to Pidgin in their new IRC support model!

(Updated 2007-05-23 12:26 to fix a typo)

Idiocy strikes everyone from time to time...

It's just that it strikes some of us a bit more frequently than it does others. Take me, for example. I am a first-class idiot. My idiocy in the case I'm posting about is a direct result of me being a generally nice person in real life. Let's run down my stupidity, shall we?

I agreed to work on a computer for a co-worker. She had just decided, after years of being on dial-up internet service, to switch to a wireless internet service provided by her town. The "tech" finally showed up and installed the equipment. Signal was good and everything. Internet is insanely slow. A couple days and an hour long phone call with me later she brought the computer in for me to look at. I (and here's where the stupidity kicks in) let her use my powerbook while I had her computer.

Over last weekend (May 12-13), I brought the computer home and poked and prodded as much as I could. I could find nothing wrong. Even so, I tweaked a few settings here and there, ran the usual Windows Update crap, etc. I returned the computer on Monday (May 14). My powerbook still hasn't been returned.

Oh, and for laughs, let's explore my other instance of stupidity where this woman is concerned. She bought a Dell back in September. She complained endlessly about the keyboard, so I offered (sometime in October or November) to trade her my Microsoft keyboard for her Dell keyboard, assuming she liked the Microsoft. She wanted to try it first, which seemed a reasonable request. Now, several months later, I have neither keyboard.

I'm beginning to think being nice is a personality flaw...

The use of arbitrary status icons in Pidgin

Before I go any further with this post, I want to make a couple things abundantly clear.

1. I have given up on this argument; I am expressing my opinions solely for posterity.
2. I don't care about right or wrong, because in this debate there is no right or wrong, no matter how strongly I feel my own opinions are right.
3. I do not want to start another flame war in the Pidgin camp; I inadvertantly caused the last spat on the mailing list by speaking up in the XMPP chat and wish I had kept my mouth shut.
   

In the text to follow, my recollection of history may be slightly incorrect; the exact history isn't important here. Only the general context matters, which what I present here is intended to illustrate.

IM applications use arbitrary icons for pretty much everything. This started ages ago with whatever IM client happened to be the first to use icons. I got my start on IM back in 1999 with ICQ. I believe I used ICQ 98b at first, then 99a and 99b, but can't recall at the moment. Whatever versions I used, they all shared a common feature--a fixed set of icons that meant something. For example, a green flower (the ICQ logo) meant said contact was online. Several other icons existed that I don't care to do research on to verify. The point is that these icons were chosen arbitrarily for whatever reason.

I next ventured into the world of AIM. When I started, AIM was still at some ridiculously primitive version compared to what we see now. I believe the version was 3.0.something. AIM used no logo on available buddies--they showed up as normal text. Idle buddies were dimmed--grey. Away buddies used a notepad icon. I can only assume the notepad was a reference to the sticky note left on the office door by some when they step out. As an aside, note that my introduction to AIM came before server-side buddy lists were actually used. I don't know if the capability actually existed at that point or not, but it certainly wasn't used.

Next I moved into Yahoo! Messenger. This application used their logo, a bright yellow smiley face (coincidentally only resembling the Wal-Mart smiley face in shape), to indicate available. Idle contacts were again dimmed (greyed). At this time Yahoo had no real sense of what Away truly meant. There were a ton of statuses, probably 10 or so; but while their names indicated that they meant away, they shared their icon indicator with the "busy" status--the yellow logo with a red sign in the lower right corner. You could set your own custom status messages, but the only thing you could do to even come close to visibly showing away status was to set the "busy" flag on the message you typed.

By this time, we're into early 2001. I had just been introduced to Linux via a classmate who ran SuSE 6.4 on a Sony VAIO. I started experimenting at home and finally got online with Linux (at this time I used Linux-Mandrake 7.2--those were interesting times!). I used official linux clients for a while for AIM and Yahoo. I found licq for ICQ. I disliked all of these applications for various reasons.

I had been experimenting with GAIM at the time (yes, in this case that capitalization was correct). Version 0.43 was installed on my machine. I don't recall how, as Mandrake 7.2 shipped with 0.48. I was a clueless newbie at the time and couldn't really figure much out but was eventually able to get online. I then stepped up to GAIM 0.48, then 0.53. From there I continued the upgrade path. All through these versions of GAIM, the available indicator seemed unimportant. What matters in the scope of this post is the away icon--it was the same notepad icon AIM used. It seemed natural, as this was primarily an AIM client.

I happily contiuned along the upgrade path--0.54, 0.55 ... 0.59 ... 0.59.9, 0.60cvs from Sourceforge's nightly CVS tarballs, 0.60 ... 1.2.o, and finally onto CVS HEAD once it became functional. Somewhere along the line there GAIM became Gaim. It was somewhere after I started using CVS HEAD that I started contributing to Gaim. At any rate, Gaim continued to follow the paper == away concept, and had gone to prpl icons to indicate available and dimmed prpl icons to indicate idle.

Now, during this time, I just took for granted that paper meant away because it's what i'd seen for so long. Now that Gaim has become Pidgin and changed its artwork, I find myself displeased with the icons for both Away and Extended Away. I have grown accustomed to the clock == away metaphor established here, even though I disagree with it. Now, this is not to say that I find the paper an adequate away icon, but more on that later. Also changed is the sticky note icon is now a sheet of paper (no complaints there). That icon, however, was moved to represent the Extended Away status. I don't agree with this assessment either.

At minimum, I would prefer to see the icons' positions switched. A clock indicates time, of course. A compelling argument is made in favor of using the clock for away, as most definitions of away do deal with time. The same arguments can be said for extended away. All these arguments are perfectly valid. I can't disprove them or rebut them with anything but my own feelings.

I feel that the clock would be a more adequate representation of the "idle" status, by indicating that it has been some time since the remote user sent a message or touched his/her keyboard or mouse. I also feel that the paper fits neither away nor extended away. I would propose a sign, similar to Adium's away sign, for extended away. I justify this proposal with an argument Sean Egan himself made in favor of the paper--if a shop owner closes shop for the winter, he puts a sign on the door saying "closed till spring" or somesuch.

As for the away icon, I've been thinking about that for quite a while now. Initially I thought a red circle with an X in it might be good, but that's a better representation of "busy" or "do not disturb." A yellow circle with some sort of symbol or something inside might work, but would be hard to distinguish from a white background and impossible to distinguish from a yellow background. In a fit of smart-alleck tendencies, I sarcastically suggested a big red A in the XMPP chat. Dumb idea. Finally I came to a blue icon of some sort. Not necessarily a circle, but not necessarily any specific shape, either. It would of course need to be unique and identifiable. I would do some mockups of this myself, but I royally suck at doing anything with graphics.

In conclusion, I will say I'm dropping this issue from this moment forward. I've vented about it, so it's out of my system. I'll live with whatever icon decisions remain.

I hope that if anyone on the Pidgin development team reads this they are not offended by anything I have said here, particularly Sean himself. I don't intend any of the comments above to be inflammatory, insulting, etc.; instead, I intend them merely to be a final expression of my opinion as my way of accepting the current state of affairs with respect to the icons before moving on to bigger and more important issues.

The true purpose of blogs?

As anyone reading this post may or may not know, I am a huge Stargate fan. As such, I've been slowly getting into the blogs (thank you, Gateworld, for linking them so I could be lazy!) of those who are involved with Stargate. One of those blogs belongs to Kate Hewlett. For those who don't know, she played the sister of Dr. Rodney Mckay, who happens to be portrayed by David Hewlett, Kate's brother.

All this is pointless drivel meant to provide a bit of backstory and beef this post up a bit. The real point I'm trying to make here, alluded to by the title, is that in reading Kate's blog, I discovered a comment attached to the post stating that the commenter had come to the understanding that "blog" was actually short for "bitch log." (Sorry for the language, everyone. I do try to keep my posts clean.) After re-reading my previous posts here, I think I have to agree. I complain/whine/whatever a lot, and that shows in my posts. I promise I'll eventually post something meaningful :)

So, let the true purpose of blogging begin! :)

Pidgin and the status and protocol icons

Ok, so by now everyone knows that Gaim has become Pidgin. Well, the name isn't the only thing that changed. Pidgin has decided to demote the protocol icons to second-class citizens. I love it. Being one who uses IM for communication, I find the protocol information almost completely useless.

Many users have complained about the lack of protocol icons. Ticket #414 is a prime example. There are others that have been opened and subsequently closed as duplicates, including at least one that I personally slammed shut within 45 seconds of its opening. I'll share my personal views on a few issues brought up as arguments to have the protocol icons back:

File transfer, you say? What's that? No, seriously! I don't use file transfer. No one on my buddy list ever sends me files. They use web servers, e-mail, or even sftp. Granted, for the most part I have much more technically inclined friends than most IM users. I will admit that I have occasionally taken the lazy road and attempted to send a file over IM; these attempts are futile as the only people I would send files to use XMPP or Yahoo! Messenger. Pidgin's file transfer support in these areas is somewhat lacking, and that's fine for me. I have a virtual private server from Steadfast Networks that I can host whatever legal content I desire on. I also have access to a dedicated server, also from Steadfast, and can place files I wish to share there as well.

Work vs. Personal. Doesn't apply to me currently but has in the past, so I do have an opinion. Pidgin has supported the notion of buddies and contacts for a very long time. Sean Egan, the lead Pidgin developer, prefers to call contacts "Person"s now. Adium and Trillian call them contacts and metacontacts, respectively. The simple answer to this is to use two contacts (or metacontacts if you prefer) for each person. One of these contacts would be for the personal accounts and the other for the work accounts.

But I want to see it! Wah. I want to get rid of the clock for away, but we don't all get what we want. Suck it up. I was initially against this change myself, but after using Adium on my powerbook and macbook for a while, I had gotten used to the lack of protocol icons. After a couple days I adjusted to it in Pidgin as well and learned to really like it.

Were it not for wanting to avoid being the root cause of trouble, any time someone comes into #pidgin whining about the protocol icons I would point out that each and every user has the freedom to do one of the following: a) suck it up and live with it; b) fork Pidgin and take it back to the old Gaim look; or c) find another IM client--there are many clients available to choose from.

I think this ends my rant on this subject for now. I would like to state for the record that the views and opinions expressed in this post do not necessarily represent the views of Pidgin, Finch, libpurple, Adium, Instant Messaging Freedom Incorporated, their developers, members, and board of directors, or any other software package or entity mentioned herein or related to this issue in any way.