Re: is glib too bloated?



On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote:
> It might be advantagous if alot of the glib data structures
> were moved somewhere above libgobject in the stack (glibutils ?),
> this way they could have the option of being gobject based,
> opening a whole new world of possible code paths and also allowing
> more generic access to these data structures through the gobject
> api (hash tables and linked lists could possibly be serialized
> by libglade and crammed through a network socket ? for an example of
> a misc wild idea).

I think you mean "below" the gobject stack, don't you?  The data
structure libraries are required by gobject after all, aren't they?

In any case, I think a future split out of the glib data structure api
would be excellent.  I pretty much use thinks like gslist, gstring, and
ghash in *all* my C programs.  I also frequently use the glib logging
facility.  

On the other hand I don't often use gobjects, the event loop,
call-backs, or any other part of glib in many of these little utility
programs.  

It would be nice, though, to only have a small dependency, rather than
the entire glib.

That said, glib isn't that big.

> 
> The biggest advantage to this, and everyone will disagree <here/>, 
> is that it would require breaking api in the platform - which is a 
> thing the platform is in dire need of (how is all the needed
> refactoring going to get done if we cant drop support for all the older
> widgets and older deprecated functionalities ?), in the end this is why
> something like this reorganization of the stack will never happen until
> affirmative action is taken and a dream like gtk+-3.0 is realized.
> 
> /me dreams on just for the sake of dreaming :)
> 
> Cheers,
>                      -Tristan
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]