Older blog entries for Jimbob (starting at number 4)

Soo, nearly 2 years later, I'm updating my diary again.


libgtcpsocket is a GObject-based networking wrapper intended for use in GTK+/GNOME applications which need an easy-to-code-against connection wrapper that ties into the mainloop/signal system nicely. It's currently in GNOME CVS, in the "libgtcpsocket" module, and is nearing feature-complete-beta status, proxy support is the only major feature left to finish.

libgircclient is a subclass of libgtcpsocket for IRC client connections. Currently unusable, waiting on libgtcpsocket to be stabilized. In GNOME CVS, in the "libgircclient" module.

GnomeChat is Yet Another IRC Client, using GNOME 2.0, libgtcpsocket, & libgircclient. The major design goal of GC is to provide an IRC client that anyone could use to easily handle common IRC tasks, such as channel oping, sending/recieving files, and communicating with other users. The UI is about half complete, the other half is waiting on libgircclient. In GNOME CVS, in the "gnomechat" module.


Not my problem anymore, I'm busy with interesting software projects. Go seth! :-)
If you mistype "strong" as "string" without thinking and create a few screenshot mockups months back, does that mean you are qualified as a Journeyer? Somehow I doubt it, but that's what I'm certed at... Go figure.

UI Hit Squad
Sigh. Well, I haven't posted any updates because for all practical purposes the Hit Squad is dead. This is partially my fault for jumping in when I had no clue about project management, so pity the poor fool. I haven't decided what exactly to do about this ex-limbo status given Eazel's expressed desire to work on UI as well. I know they have the talent and drive to basically take over from the GNOME UI Improvement Project after Nautilus is out the door, so I think I'll concentrate on learning programming so I can help implement what they come up with.

Well, I'm currently hacking together a patch for X-Chat 1.5.x's GNOME version that contains major UI reworkings. So far I've gotten through the server list, reworked the menus, and am starting to change the main window's UI. Thank goodness C and GNOME/GTK+ isn't that difficult (except strings, which I have grown to seriously hate in the last few weeks -- although I'm sure that's at least somewhat related to the fact I had no idea what I was doing going into it (On a semi-related note, I really wonder what the heck people who programmed strings in DOS back in the bad old days were on -- using an OS where a segfault == a reboot is a pain when you are learning strings, believe me [I don't know if Windows is as clueless on this, but somehow I have a hard time believing it isn't]). Hopefully I will have enough of a clue when I am finished to start making real contributions for a change.

I go back to college later this week, so my IRC usage may drop in favor of forced torture (C++ course *and* a COBOL course in the same semester <<shudder>>). On the plus side though, I will get cheap 1mbps DSL, so I can regain some of my stature as a LPB in various online games. That's about all from the personal front.

I've started modifying my GTK+ XMMS Skin to match my "XenoFace" (Interface) GTK+ theme (which is the hack of Xenophilia-0.4 that showed up in Carbamide's Nautilus screenshots from May or so).

Well, seeing as this is what the diary junkies *really* want to see, I suppose I have to throw in some detail or event that isn't computer-related just to let the hardcore IRCers among us know that the world isn't actually a computer generated simulation of the real world, composed of channel bots and the like.

Got back from the oral surgeon a good report (the holes in my jaw where I used to have two teeth are not infected and I can go back to eating junk food regularly). Not much else to report.


I've decided to take the Salon article as an admonition for me to start keeping this diary up to date, rather than posting one diary entry every five months... :-)


The "Gnome System Administrator" application will not be coded by me. Helix is working on a scaled down version of it, and I trust them more than I trust myself re: coding.


I agree 100% with what I've heard of Miguel's comments on coding (although I think a transcript of his keynote will have to be put up somewhere There is waaay to much code duplication. Slashdot's ignorance not withstanding, it's just plain dumb for every app to load into memory it's own dialogs, stock buttons, printing support, etc.
    From a coding point of view, you're making you're own job tougher by doing this. From an efficiency point of view, you're making the system's job harder by making it load a different version of "Common Feature X" for each app.
    What's more, the aguments for not depending on lots of libraries is foolish. Unless you're doing something dumb, like linking to an unreleased library under heavy development, the APIs are not likely to change that much between revisions, and if they do, the earlier revision will still work (you can have more than one version of a library around, remember).
    "Saving the user some download time" is also lacking in veracity. If you put links up to the deps that need to be downloaded on the same page as your app download link is on, and toss some instructions on the page as well, where's the huge loss. These people are on the Internet all the time, and they still can surf while they're downloading (Modems are both not 14.4 and not single-tasking).
    Then there is the argument that libraries take too much disk space... Can anyone guess what the majority of my disk space is taken up by? MP3s. 30% of my system is MP3 files. One five minute song in 160kbps MP3 format takes up more space than all the .so files in gnome-libs and gdk-pixbuf. I would bet a serious amount of cash that a great majority of the people so concerned about their disk space can spare a few measily megs for what most GNOME apps need on top of GTK+... (And if you aren't using GTK+, you're using something nearly the same size.)

However, the most serious reason for using libraries (at least from my point of view and taking into account the assumption that your app is GUI-based :-)) is that they allow for a consistent user interface far more easily and with much more structure than the implement-it-yourself method does. And seriously now, what is the point of releasing a GUI app to the world if you don't care about the interface looking good and fitting in with the rest of the system.

Ok, this is the first entry for me, so I'll attempt to bring everyone up to speed on whatever I can.

First off, I would like to appologize for not posting a UI Summary yet. The reason I haven't done this is because we haven't finished anything yet, and the entire thing would be a bunch of links to Eazel, Inc. resources and articles. I would like to get at least two news items before posting a new summary, so that's that.

Somewhat related to the first item, I did send out Proposal #2 (Improving The GNOME-Core Interface) to the other members of the Hit Squad. All that's left is for them to vote on it, me to HTML-ize it, mix it with the redesign screenshots I've already done, and announce it to the world (at which time, I will post the URL).

And as a little teaser to get you all flipping out (:-)), I'm planning on learning GNOME/GTK+ programming so I can code a GNOME System Administrator application. The basic idea is that I steal the Control Center 2.0 code (the next gen codebase), change a few labels, and write some sample capplets. And what do these capplets do? Simple. Configure system services! That's right, a gnomecc-style interface for setting up Runlevels, httpd, nfs, exim, samba, etc. And since it uses capplets, service authors can (read: should) write their own capplets which handle the intricasies of their service. A Roxen capplet could ship with Roxen, an Apache capplet with Apache, etc. This way nobody has to keep track of every config file format under creation, just the few that the sample capplets I'll provide handle (I plan on doing capplets for the current OSS Linux versions of all the major services: NFS, Apache, Samba, Exim, and a Runlevel editor). So after this is finished, pester your favorite vendor to write a capplet for their setup.

If you are already working on such an app, please contact me immediately so I don't waste my time, thanks ;-)

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!