I've been considering adding a dependency on glib.
[Before I get into a technical discussion, I should note that most of the
technologies further currently works with (sawfish, oroborus, gnome)
depend on glib anyway, so it won't be much of a dependency.]
There are three levels of integration with glib:
- I need a linked list type (for a variety of things) and probably a
hash type (for the configuration file). This is a good use for glib.
I could also use glib's GScanner to write the parser.
- The next level would be using GMainLoop. I could then remove all of
my event-timing-related code and instead use glib's timeout code.
This would be very nice, because I will no longer need to worry about
bugs in my event code, and I could start monitoring file descriptors
(which will soon become useful when I write daemons that work with
- The final level of integration with glib would be to use the CVS
version of glib, with its "GObject" system. This would enforce a
level of object-orientedness over everything.
Now that I type it all out like that, it seems clear to me that I should
just do level 2.
Part of the reason I created this mailing list is so I could just type
all my ideas out... and so one day, in the future, when someone wonders
"why does this program suck?" they can go check the archives to see my
Another advantage with glib is that I'm very comfortable with it. I'm a
GTK/Gnome developer mostly, so all of this xlib/Evas stuff is new. (It
isn't difficult, it's just that I wouldn't need to learn anything to use
Anyway, when I move to glib, it'll cause consequent changes in all of
the plugins. Yay for huge changes again! But maybe this'll be the last
Not likely. :P
-- Evan Martin - firstname.lastname@example.org http://www.speakeasy.org/~martine
_______________________________________________ Further-devel mailing list Furtheremail@example.com http://lists.sourceforge.net/lists/listinfo/further-devel
This archive was generated by hypermail 2.1.2 : Sun Nov 11 2001 - 14:16:15 PST