Older blog entries for ebassi (starting at number 7)

Using advogato (and my log), since I'm not on the Planet (yet).

I've just read Daniel's post, and since shame is a powerful drive, here's my non-requested answer.

I'm one guy - quite possibly, the only one - that switched from a full-fledged XML parser like libxml2 to GMarkup. Believe you me: I would have rather stayed within the blissfulness of DOM, within the ease of development of a complex and powerful parser, within the safety of one of the best XML parser around the F/OSS world.

I would have used libxml2 (and in fact, I did begin using it) - because of the work that DV (and every other developer involved) put into libxml2; I state that again: it's a wonderful library, and it's great to have it, and for it I'll have to buy Daniel enough beer to knock him unconscious until Gnome 2.14. :-)

That said, I switched to GMarkup because libxml2 is also a heavy dependency for Gtk+. It's a 1M+ library, and a dependency some devices can't afford to have on the chain - I think specifically of embedded devices.

Supporting a platform standard like the storage for recent files and bookmarks only on desktop boxes, because they can afford to have libxml2 pre-installed is not an option.

I remember discussing on the XDG list with Daniel and others about the desktop-bookmark spec; the spec started as a GMarkup format, and then I was convinced to use XBEL. It was a good idea - and once properly standardised, it could lead to data sharing between various environments; a goal that the previous recent-files spec missed badly.

Having GMarkup to parse a valid XBEL stream, even with every limitation it has (UTF-8 only, a bit shaky XML:NS support, etc.), has been possible (even thinkable) just because I had beside my open Gedit window another window with a XBEL parser written using libxml2, reminding me how a full-fledged XML parser should work.

So, thanks Daniel for libxml2 - your great work has been and it's still really appreciated and useful. Sadly, there are requirements, in this world, and many times they collide with what we would like.

Using advogato (and my log), since I'm not on the Planet (yet).

I've just read Daniel's post, and since shame is a powerful drive, here's my non-requested answer.

I'm one guy - quite possibly, the only one - that switched from a full-fledged XML parser like libxml2 to GMarkup. Believe you me: I would have rather stayed within the blissfulness of DOM, within the ease of development of a complex and powerful parser, within the safety of one of the best XML parser around the F/OSS world.

I would have used libxml2 (and in fact, I did begin using it) - because of the work that DV (and every other developer involved) put into libxml2; I state that again: it's a wonderful library, and it's great to have it, and for it I'll have to buy Daniel enough beer to knock him unconscious until Gnome 2.14. :-)

That said, I switched to GMarkup because libxml2 is also a heavy dependency for Gtk+. It's a 1M+ library, and a dependency some devices can't afford to have on the chain - I think specifically of embedded devices.

Supporting a platform standard like the storage for recent files and bookmarks only on desktop boxes, because they can afford to have libxml2 pre-installed is not an option.

I remember discussing on the XDG list with Daniel and others about the desktop-bookmark spec; the spec started as a GMarkup format, and then I was convinced to use XBEL. It was a good idea - and once properly standardised, it could lead to data sharing between various environments; a goal that the previous recent-files spec missed badly.

Having GMarkup to parse a valid XBEL stream, even with every limitation it has (UTF-8 only, a bit shaky XML:NS support, etc.), has been possible (even thinkable) just because I had beside my open Gedit window another window with a XBEL parser written using libxml2, reminding me how a full-fledged XML parser should work.

So, thanks Daniel for libxml2 - your great work has been and it's still really appreciated and useful. Sadly, there are requirements, in this world, and many times they collide with what we would like.

I've moved my log on my personal web site, here:

Context Switch

(I know, it's been some time - it's that just now I remembered having an account on advogato)

21 Apr 2004 (updated 21 Apr 2004 at 23:43 UTC) »

* geek: I've taken the test reported by teknofile: 56.80473%. I guess it helped that I'm a trekker and a sci-fi reader/fan. ;-)

21 Apr 2004 (updated 21 Apr 2004 at 23:26 UTC) »

* libgtodo: In a couple of hours, I've done a decent job in subclassing GtkListStore into the GTodoListStore class. Still missing some methods, but the constructor works, and the model is usable with a GtkTreeView widget (here's a screenshot of the test app). I plan to wrap everything up tomorrow, and ask QBall to design the GTodoListView widget.

* study: boring class on computer programming. I've already done this when taking the computer engineering course (I switched to a pure CS course when I fluked three times in a row the electronics and the theory of automation classes; it's not that I don't like engineering: it's engineering that does not like me).

* life: starting may 1st, my parents are going to Rome for three days. This means: free house for approx. 72 hours. Woo-hoo!

* libgtodo: Yet another week begins, and yet another week of work on libgtodo. I've completed the basics of the GTodoClient object: it can append/remove items (and categories), and each modification is dumped onto the XML tree in memory. I began working on a sub-class of GtkListStore, called GTodoListStore, which will interface a GTodoClient object with a liststore, and later I'll design a GTodoListView widget, subclassing GtkTreeView.

Thus, a simple viewer, would consist of these calls:

client = gtodo_client_new (some_uri);

store = gtodo_list_store_new (client);

g_object_unref (client); /* store holds a reference */

view = gtodo_list_view_new_with_model (store);

gtk_widget_show (view);

In parallel, this week I'll begin writing a Perl binding to libgtodo. Subclassing a widget in Perl is quite fast, so I could design a prototype and then port it to C. Discussions about a platform language always revolve around Java/C# (with brief appearances of Python, from time to time), but they always forget that gtk2-perl and gnome2-perl bindings are one of the most advanced bindings available on GNOME D&DP. With the upcoming of Perl6 and Parrot, I'd say to give Perl a chance.

This week I've been working on libgtodo, by QBall (of gnomesupport fame). I converted it to GObject and broke everything I could think of: ABI, API, XML file format... But then, if you have to break something, better break it right. The API is much more straightforward, now, and better, I think. Now, libgtodo behaves like GConf: a client, which monitors an XML file, and keeps track of the task list. I plan to wrap this library with a Perl (and, later, a Python) binding. This is part of a grand master plan of creating a series of libraries for handling common operations for a PIM, such as a contact list, a daily/montly/yearly schedule and task lists. Right now, the only PIM for GNOME is Evolution; and as much as I appreciate the efforts for making it the best groupware around, a simple, lightweight, PIM is what GNOME is lacking right now, in my opinion.

* Still working on the perl translation of the gtk tutorial (with a hand from James Curbo), and I've hit the first culprit: should I remove the ItemFactory/Combo/FileSelection stuff, deprecated by GTK 2.4, or should I simple put a "Warning: This Stuff is Deprecated" on it?

* I've installed GNOME 2.6 from Debian experimental repository (great job, guys), and I'm testing the various gtk2-perl stuff under this new release. BTW: Gnome2::GConf hit the scene with the first stable release (1.000). Apart from brown-paper-bag releases, this one should be the one that goes into the GNOME Platform Bindings official release.

* First Post (using gnome-blog applet).

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!