Gnome Journal

As long as I’m in a blog writing mood I should talk a bit about some stuff I’ve been up to.  I’ve written an article for the Gnome Journal that should be out in issue 15.  I review Hamster which I found to be a pretty solid little project on the whole.  It was somewhat recently accepted as an official Gnome module so if you haven’t checked it out yet you really ought to.

I’m also in the process of writing another article that is going to be an overview of DConf which is lining up to be the venerable GConf’s eventual replacement.   So be sure to check them out along with all the other great articles that should be coming out with the next issue towards the start of June.

The 16th issue is going to be focused on GUADEC so if you are attending please hop on #gnome-journal or gnome-journal-list and volunteer to write an article!

Logging with GLib

I use glib’s logging functions quite a bit while working on Gnome-Mud.   If you don’t recognize them by that name then perhaps g_message, g_warning, etc you’ve heard of: same thing.  These are especially handy for logging entire Telnet sessions with every negotiation and byte transferred easily trackable.  I’m sure there are uber developers out there who can crank out bugfree telnet implementations without breaking a sweat, sadly I am definitely not one of them.

The bad part about using logging like glorified printf’s is that it really spams the console and I personally hate when programs do that so I’ve simply removed my logging messages prior to a release of Gnome-Mud in the past.  This is really quite lame because then I have to go back in and re-add all my logging stuff.  So really, what I wanted was a way to show logging information only on development builds and then an easy way to turn it off without deleting all of it for releases.

The first (and worst) thing that came to my head was simply to wrap every g_message with #ifdef DEBUG…#endif warts but this makes the source looks pretty awful so I threw that idea out quickly and decided to actually use the tools GLib provides for this very task.

GLib lets you set a logging handler that bypasses the default way GLib reports logging info (ie, spamming it to the console).  Once I got my head around what was needed actually implementing a logging handler was pretty simple (the docs are really quite good in this area.)   One of the neat things about creating a custom logging handler is that you can display this information anyway you please.   After a productive day of hacking I now have this up and running:

Debug Logger
Debug Logger

Using colors isn’t always the greatest idea since there’s no gaurentee that any particular GTK+ theme will look good with them but they make it easy for me to quickly parse a bunch of logging.  Using colors is disabled by default just to be safe though.  All the colors that are used are all customizable with gobject parameters so its a fairly self-contained little setup.

I made a simple API that lets you add tabs (or logging domains) pretty easily.  I am somewhat abusing the glib log domain since it’s technically for libraries but I find it handy to be able to seperate logging for various subsystems.  The neat part is that when this is activated (currently via a bunch of autofoo in gnome-mud) all logging is handled by the UI.  When it is inactive it will print g_warnings and g_criticals to the console still but all lower level logging is simply gagged.

All in all pretty good work for a day’s hacking.  I think this is useful enough to merit a release seperate from Gnome-Mud itself for anyone who wants simple drop-in gui based logging.  Tomorrow I’m going to generalize some bits of it (and remove all the autofoo dependant stuff) and add some more api to allow for things I’m not doing in Gnome-Mud’s usage of it.  Documenting it should be quick too so hopefully by Wednesday I’ll get this out there.

If you’d like to see it sooner then that just look at debug-logger.[ch] in the trunk of Gnome-Mud’s SVN repo (svn://svn.gnome.org/svn/gnome-mud/trunk)

Gnome-Mud 0.11.2 in the Wild

Well a scant 11 days have passed since the release of Gnome-Mud 0.11.1 so this is some kind of record for the project.   This release focuses on stability and code quality.  You’ll find  this release of GnomeMud to be very stable and we plugged many memory leaks so it runs leaner than ever as well.  The big fix for this release will be our handling of locale’s and character sets which will now work properly in any combination of user and server locale.

Also, if you found MCCP support to be a bit slow in 0.11.1 we made a key optimization in our decompression routine which speeds it up quite a bit.

Basically this is a solid point release.  It fixes alot of bugs and gets the project set to start looking at 0.12.  If something big comes up we’ll look into rolling out a 0.11.3 release but the plan now is 0.12 ahoy!

To see the full list of changes visit our wiki page and download the new release and check it out!

Why Vala is the Answer to Life, the Universe, and Everything

I have Vala’s number and I can safely report it is 42.  I’m hardly the first person to notice that Vala rocks but in one area in particular it is so fantastic, so groundbreaking, so amazing I am compelled to write about it.

It is no secret that GObject brings many benefits to the table.  It adds a full C ABI compatible object system to C, no mean task.  It has powerful support for signals built into it’s very core and supports much of the OO functionality one is likely to need.  Because of it’s OO nature and compatability there are many powerful library bindings available which is one of the major strengths of the GNOME platform.

No one ever said GObject was fun to use though.

In fact GObject has a pretty rough reputation especially if you aren’t using those aforementioned powerful library bindings which hide all the ugliness.  This, of course, really isn’t GObject’s fault.  It is not an extension to a C compiler, it is not a preprocessor, it is simply a library and so it can’t add any syntax to facilitate all this.

Ever wonder why some GObject based libraries use lots of access methods and not GObject properties?  Properties are a pain!  You need to create all the properties using GParamSpec, then you have to install them during class initilization.  Don’t forget you have to override the base Gobject get/set methods and provide your own methods to actually set and get these things.  Whenever you want to add a new property you have to touch the code in at least 4 places.  And don’t get me started on creating your own signals.  Signals are much the same but if you want your signal to return a value or take more than a single parameter its time to start generating your marshallers (if you ever wondered what glib-genmarshal does, start creating signals and you’ll find out soon!).

None of this is very hard.  It’s just tedious boilerplate.  Vala makes this all go away.

Vala is amazing because it allows people to easily and quickly utilize the full power of GObject and since your Vala code compiles down to GObject/C anyway you keep all of the compatibility that GObject provides.    Ever wonder what lots and lots of properties definitions would look like in GObject?  Well here is a bit of a Vala class I have:

    public bool HasSheet { public get; private set; }
    public bool Visible { public get; public set; }
    public bool Animated { public get; private set; }
    public float Alpha { public get; public set; }
    public float Rotate { public get; public set; }
    public float Scale { public get; public set; }

    <snip>

And here is a snippet of the generated GObject/C (just the installation!)

g_object_class_install_property (G_OBJECT_CLASS (klass), SPRITE_HAS_SHEET,
g_param_spec_boolean ("HasSheet", "HasSheet", "HasSheet", FALSE,
G_PARAM_STATIC_NAME | G_PARAM_STATIC_NICK | G_PARAM_STATIC_BLURB | 
G_PARAM_READABLE | G_PARAM_WRITABLE));
g_object_class_install_property (G_OBJECT_CLASS (klass), SPRITE_VISIBLE,
g_param_spec_boolean ("Visible", "Visible", "Visible", FALSE,
G_PARAM_STATIC_NAME | G_PARAM_STATIC_NICK | G_PARAM_STATIC_BLURB
| G_PARAM_READABLE | G_PARAM_WRITABLE));
g_object_class_install_property (G_OBJECT_CLASS (klass), SPRITE_ANIMATED,
g_param_spec_boolean ("Animated", "Animated", "Animated", FALSE,
G_PARAM_STATIC_NAME | G_PARAM_STATIC_NICK | G_PARAM_STATIC_BLURB
| G_PARAM_READABLE | G_PARAM_WRITABLE));
g_object_class_install_property (G_OBJECT_CLASS (klass), SPRITE_ALPHA,
g_param_spec_float ("Alpha", "Alpha", "Alpha", -G_MAXFLOAT, G_MAXFLOAT, 0.0F,
G_PARAM_STATIC_NAME | G_PARAM_STATIC_NICK | G_PARAM_STATIC_BLURB
| G_PARAM_READABLE | G_PARAM_WRITABLE));

<snip>

Vala provides alot more than simply acting as a shorthand for GObject but for someone like me who has traditionally eschewed the language bindings and developed in GObject/C it is mana from heaven.

Gnome-Mud 0.11.1 Released

We just pushed out the first point release in the 0.11 branch of GnomeMud.  I really recommend all gnome-mud users to update to this point release as soon as possible.  We fixed a bug that completely broke our telnet parsing.  So the good news, it’s fixed and our telnet implementation is rock solid now.

Here’s some of the things you can expect in this release:

  • MCCPv2 support.  MCCP stands for Mud Client Compression Protocol and is used by many muds to lower the bandwidth needed to run a mud.  This will be transparent for endusers but you’ll be able to feel good knowing you’re saving your favorite mud a bit of money.
  • The new iconview-based connection manager.  This replaces the horrid old system with something much more elegant and easy to use.
  • Cleaned up UI.  Our dialogs no longer look so ugly!
  • Lots of bug fixes. You should find gnome-mud works better than ever (with much fewer crashes!)

If you’d like to know more visit our wiki page or download the newest release and check out the NEWS yourself!

Thank you so much!

I’ve been horribly remiss in not posting this earlier and wanted to make sure it had it’s own blog entry.

I am now a member of the GNOME Foundation and it is such an honor to be apart of such a great group of people.  I started contributing to Gnome two years ago and fell in love as it were with the community that surrounds the whole project.  For the warmth, the help, the education, the prodding, and the friendships: thank you all so much.

Very special thanks go to Jordi Mallach and Mart Raudsepp for their belief in me, their sponsership of me, and for supporting my efforts over the years.

I’m more comitted to Gnome than ever before and I’m really looking forward to jumping into deeper pools within the project. See you all out there!

Bees ain’t got nothing on me…

Been busy as all hell since school stated in the Fall.  Working with automata theory right now and I’m really digging it but it’s certainly not a subject I can just blow off and crack the book open a week before the final.    That plus working in the scientific database lab has kept me cooking.

My FOSS work has slowed down somewhat from the fairly feverish pace that I kept up getting Gnome-Mud 0.11 out the door in the summer but it still continues nicely.  I’m working on getting MCCP support working fully in gnome-mud at the moment which involves a fairly comprehensive rewrite of gmud’s network code.  I’m happy though because the protocol has exposed alot of weaknesses in gmud’s telnet handling and once this is set up it’s well on the way of becoming one of the best mud clients out there.

Our users will be happy to hear also that I’ve been working on getting a Mapper up and running in gmud.  It will be an ‘auto’-mapper at some point but there’s not too much ‘auto’ about it at the moment.  This has been great fun and a nice change of pace from dealing with TELNET rfcs.  Also, this has been a good excuse to started playing with GooCanvas more.  After an abortive attempt at rolling my own canvas I have a better sense of the issues involved in creating one and I think the GooCanvas folks are doing a fantastic job at solving them.

I’ve also begun contributing to GnomeShell which is the project attempting to implement the great ideas to come out of the User Interface Hackfest.  Vincent’s report of the results of that meeting have really formed the target that the project is currently shooting for.  If you want to learn more about some of the thinking and design that has currently gone into the project, Owen has written an overview.

It’s a really exciting project that could potentially change the way our users interact with Gnome.  If you have any desire to get into the ‘ground floor’ of a gnome project before it’s all built up then I highly, highly encourage you to check it out and join us on #gnome-shell at irc.gimp.net.

Iconviews are Neat

Well after a big bout of hacking I managed to rip six files out of Gnome-Mud and replace them with two files that do the same job in a more usable and nice manner.  Previously, if you wanted to add a new mud connection to gnome mud it required 2 obtuse dialog boxes and entering in way too many options.  Plus, if you didn’t check a magic check box during the mud setup it wouldn’t show up as an available mud to connect to!

Not only that, the old code barfed into the gnome-mud gconf directory and left all sorts of orphaned keys. Clearly, this had to go.

All that has been replaced with this:

Iconview Prettiness

If you have more than a single character on a mud it will just display that mud twice with the different character names. No more treeview-itis.   The new property editor has been pruned quite a bit as well with all the extraneous settings that didn’t actually do anything removed:

Connection Properties

Lastly, I need an icon chooser.  The one being currently used out there is still gnome-icon-entry but since I spent some time purging gnome-mud of gnomeui and friends I wasn’t eager to add a dependency to them back.  I ended up rolling my own and it is essentially a clone of the older gnome icon chooser:

Icon Chooser

I’m thinking about converting this to a widget and creating a button widget for it and trying to get this into GTK as a replacement for the older gnome library version.

Anyway, now on to redoing our trigger and alias ui!  0.12 ahoy!

Gnome-Mud 0.11 Released!

After a very long hiatus we have just released the brand new 0.11 release of Gnome-Mud!  This represents a great deal of work over the older 0.10.x branches.  It is essentially a complete rewrite of the application from the ground up.  What this release does is change Gnome-Mud into a nice looking, well behaving, and modern Gnome application.

Hello, Beautiful

Not only that but there’s an absolute ton of new features added including support for the Mud Sound Protocol (which allows for sound effects and music to be played on muds that support it), SOCKS proxy support (versions 4 and 5), per connection input history, and a completely rewritten netcode layer that provides RFC compliant Telnet support. For a full feature list check out our wiki page.

Mart Raudsepp also contributed a really nice input widget for Gnome-Mud.  It’s a standard GtkTextView but it appears to be an entrybox until enough text is entered that it needs a new line to display it all.  At that point the input widget will automatically adjust it’s size so it can display all of the input.  Right now the height limit is set to 5 and if there are more lines than that a scroll bar will appear.  Its really neat and intuitive and works even when text is pasted into it or when the user cycles through the input history.

Input Widget

This is an important release. It gives us a great foundation on which to start building even more features into the client as we push for 1.0.  There are sadly a few regressions: Keybindings, Python plugins, and Variables didn’t make it in this rewrite.  However they are all in store for the 0.12 release!

Demoscene

This just goes to show you how much computing power is readily available around us that we don’t really notice.

The whole demo is highly impressive.  I haven’t yet taken a look at their code but keeping in mind this is coming from a total storage space of 8k in ROM I’m pretty damn sure that it’s fine.  There is several really neat tricks they use in the hardware design.  Not only are they bitbanging the vga signal but they use an internal shift register in the AVR to output 8 bit commands using a single cpu instruction (!!!).