Hi everybody !
Another holy language war... :-)
>
> It's certainly a mess, and what you invariably end up with when you write
> OO programs without language support.
>
> I guess my reason for suggesting it was that although it's OOP stuffed into
> a C-shaped box it is stable, debugged, and understood by people other than
> Tuomo!
Well, it wasn't so stable, debugged and documented (and, hence,
understandable)
some time ago. But then people began using it, submit patches, documented it -
and all of a sudden, gobject became quite a viable choice for some tasks...
>
> > All the g* libraries have gone way beyond that line a long time ago and
> > Ion isn't too far either.
>
> Yes. Which is why admitting defeat and moving to gtk might be a good idea.
> Many of the problems that Tuomo and others are solving in ion have already
> been solved in other more mature pieces of software. For example:
>
> * module support has been in glib for ages. It already supports loads of
> different platforms -- no more CF_UNDERSCORED_MODULE_SYMBOLS hacks.
> * ion's static linking is just like ltdl's preload mechanism.
> * unicode support has been in glib for ages.
> * anti-aliased font support in gdk for ages.
>
> I'm sure Qt does this as well, I just happen to have done a couple of
> projects using gtk and so am more familiar with it.
>
> My point is all these things are:
> available now
> debugged
> platform independent
> are free and begging to be used
Glib is certainly cool bit of code, but it almost requires you to use it
everywhere in the code, and don't mix, otherwise you have a headache in the
morning (after nightly debugging session)....
>
> By building on these libraries (Qt offers all of the above as well) rather
> than reinventing the wheel Tuomo and others can concentrate on making Ion
> great rather than chasing minutae. It's 2003 for crying out loud! Surely we
> don't STILL have to create our own linked list and string libraries?!
You think so ? Sometimes (mostly in small/medium projects) it's just wrong.
Generic linked lists aren't very performance-wise in some conditions/ with
usage patterns, so to get things faster you have to implement something
better/different...
>
> As of version 2.2.0 gtk provides support for window manager-level
> applications (look in the docs at http://www.gtk.org/).
When was Gtk+2.2 released ? Two months ago ?
>
> I'm sure people will counter with "dependencies are bad". Well, maybe. Ion
> already depends on X, Xext, Xinerama, Xft, iconv, and utf8. Surely it's
> better to have a single dependency on gtk/Qt?
Moving the troubles few steps further... My distro's Qt, f.e., depends on
libGL, and loads it _every_time_ qt app is started... On P300MMX it's a huge
performance hit on startup... I've, of course, rebuilt qt without opengl
support, but ...
>
> > Fortunately I don't have to choose. And what's the point in using a
> > WIMP-toolkit with an anti-WIMP-is-the-only-way-and-everyone-should-
> > conform-to-it WM anyway? In my opinion all programs should be written in
> > as presentation-agnostic way as possible.
>
> There's nothing in these toolkits that says you must create WIMP interfaces
> with them. Just use the drawing layer (gdk), a few widgets (GtkEntry rather
> than ion's wedln), and you're all set. gkrellm is an example app that uses
> gtk but has its own style of window.
Style is only one (small) portion of WM. I think better solution would be to
move all the drawing code into separate module, with simple interface, and
let people create themes...
>
> Regards,
>
> Tom
With all the best, yarick at relex dot ru
