Re: glib/gtk compilation subsets (Re: is glib too bloated?)
On 5/14/07, Tim Janik <[EMAIL PROTECTED]> wrote: > we've discussed that during last GUADECs Gtk+ meeting: >http://mail.gnome.org/archives/gtk-devel-list/2006-June/msg00146.html > the main outcome was that the ability to disable some of the non-strict-core > widgets in Gtk+ could be an interesting code size reduction in embedded > contexts. if done properly and if it's possibly interesting to have > for multiple parties, compilation subsets could also be backfolded into > the upstream Gtk+ configure.in/Makefile.am. > so far, no one has really attempted this and submitted a patch though, > and without anyone taking a stab at it, it won't happen. > I actually did an initial investigation of allowing build-time subsets in gtk, and I believe I reported the results on this mailing list sometime last year, but the memory savings were not overly spectacular. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
glib/gtk compilation subsets (Re: is glib too bloated?)
On Wed, 25 Apr 2007, Gabriel Schulhof wrote: > On Tue, 2007-04-24 at 13:28 -0400, Behdad Esfahbod wrote: >>> Don't forget that the more libraries you have, the longer the dynamic >>> linker will work to resolve all the symbols, and consequently the longer >>> it will take for each application to start. >> >> And each shared library consumes at least one page of private >> per-process data memory. > > These are absolutely true. > > So, I'm wondering: How difficult would it be to set up the GLib build > system to give distributors a choice as to whether to compile all bits > (glib, gobject, gthread) into a single .so (e.g. for desktop > applications) or leave it as is or, for that matter, split it further > (though not by default), as Brandon has suggested into more .so files ? the answer to this is very straightforward, someone simply has to invest the necessary energy to find out how difficult it is. without anyone having a real need for that, it definitely won't happen (it hasn't happened yet afaik at least). > And, while we're on this track: How about GTK and GDK ? In some embedded > systems it may very well turn out that GDK is used on its own far too > rarely to warrant having it a separate library. Why not then have a > single library and save a little loading time and a page of memory. we've discussed that during last GUADECs Gtk+ meeting: http://mail.gnome.org/archives/gtk-devel-list/2006-June/msg00146.html the main outcome was that the ability to disable some of the non-strict-core widgets in Gtk+ could be an interesting code size reduction in embedded contexts. if done properly and if it's possibly interesting to have for multiple parties, compilation subsets could also be backfolded into the upstream Gtk+ configure.in/Makefile.am. so far, no one has really attempted this and submitted a patch though, and without anyone taking a stab at it, it won't happen. > Having such a flexible build system could be a boon. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Tue, 2007-05-01 at 12:10 -0500, Hans Petter Jansson wrote: > On Mon, 2007-04-23 at 17:03 +0100, Peter Clifton wrote: > > > I've found myself wanting GObject derived GList. The idea is to have a > > "list of things with some GType", and make the API which modifies that > > list emit "changed", "deleted", "inserted" signals, etc. I coded a > > GObject derived class to do most of this. > > > > One thing missing with GList is type safety of course, but if you want, > > you can add run-time type safety with a class around it. > > That sounds a bit like you want an MVC data model in GLib. For instance, > we could move GtkTreeModel and its associated model parts down. I've > been wanting that for a while now, personally. > /me too that would make libgda, for instance, not have its own model classes, it could use glib's -- Rodrigo Moya <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 17:03 +0100, Peter Clifton wrote: > I've found myself wanting GObject derived GList. The idea is to have a > "list of things with some GType", and make the API which modifies that > list emit "changed", "deleted", "inserted" signals, etc. I coded a > GObject derived class to do most of this. > > One thing missing with GList is type safety of course, but if you want, > you can add run-time type safety with a class around it. That sounds a bit like you want an MVC data model in GLib. For instance, we could move GtkTreeModel and its associated model parts down. I've been wanting that for a while now, personally. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Tue, 2007-04-24 at 13:28 -0400, Behdad Esfahbod wrote: > > Don't forget that the more libraries you have, the longer the dynamic > > linker will work to resolve all the symbols, and consequently the longer > > it will take for each application to start. > > And each shared library consumes at least one page of private > per-process data memory. These are absolutely true. So, I'm wondering: How difficult would it be to set up the GLib build system to give distributors a choice as to whether to compile all bits (glib, gobject, gthread) into a single .so (e.g. for desktop applications) or leave it as is or, for that matter, split it further (though not by default), as Brandon has suggested into more .so files ? And, while we're on this track: How about GTK and GDK ? In some embedded systems it may very well turn out that GDK is used on its own far too rarely to warrant having it a separate library. Why not then have a single library and save a little loading time and a page of memory. Having such a flexible build system could be a boon. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Wed, 2007-04-25 at 02:31 -0400, Gabriel Schulhof wrote: > > In this latter case, having a small, highly optimized library with > only the useful data structures could be more desirable. Why? There is very marginal benefit in reducing the number of symbols in a shared lib, but definite costs in increasing the number of shared libs. Please end that thread. There are 2^n-2 ways to choose a nontrivial subset of n symbols and for any subset there will be someone that want it in a separate lib. It's not going to happen. Any further discussion will be just noise. -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 21:24 +0200, Michael Natterer wrote: > You just said "it's bloated" and did not state any specific > problem you faced. So what exactly is the problem? Personally, I don't really thing GLib is bloated in any way, but there are $0.02 I would like to throw in: Consider a simulation engine: a CLI whose sole purpose in life is to run for a long time, and produce a file in the end, run, perhaps from some GUI front end. Now, if the CLI were to have a --help, then niceties like UTF-8 and gettext would still be appreciated. OTOH, you might design such an engine to be rather terse - if, for instance, the GUI were to create a "job package", to be executed by the user on a cluster, without the user being aware that this CLI is being invoked. In this latter case, having a small, highly optimized library with only the useful data structures could be more desirable. One way to conceptually split up GLib might be this: 1. Application support (portability, string handling, main loop, Unicode, ...) 2. Computational support *shrug* ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On 24.04.2007 18:31, Jake Goulding wrote: > Brandon Casey wrote: >> It's hard for me to think of unicode as >> being low-level when it adds so much overhead to string handling. > > Isn't (a part of) the unicode handling needed for correctly processing > paths under Windows? As I remember it, Windows-native calls take either > ASCII or a slightly modified UTF-16LE (aka UCS-2). In order to be able > to have code that needs to open "strangely" named files on any platform, > at least a modicum of unicode support is needed. Yes, MultiByteToWideChar() see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_17si.asp > Once you have that, > including gettext as a dependency seems straight-forward. > Not really, but having the iconv dependency was decided about six years ago: http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00219.html BTW: compared to the usual bandwidth and computer growth since that time the GLib growth was quite moderate (factor ten vs. factor two) Regards, Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
Le mardi 24 avril 2007 à 12:51 -0500, Brandon Casey a écrit : > On Tue, 24 Apr 2007, Behdad Esfahbod wrote: > > On Tue, 2007-04-24 at 03:26 -0400, Xavier Bestel wrote: > >> Hi Brandon, > >> > >> On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote: > >>> My point is _not_ that these features are not useful, just > >>> that glib would be a better library with a more strict focus and useful > >>> to more developers if some of this functionality were moved to a > >>> separate library. > >> > >> Don't forget that the more libraries you have, the longer the dynamic > >> linker will work to resolve all the symbols, and consequently the longer > >> it will take for each application to start. > > > > And each shared library consumes at least one page of private > > per-process data memory. > > The concern is organizational rather than with absolute minimal memory > consumption or program loading speed. The goal is to have as few separate > libraries as necessary to organize the components according to function > and ease library use. There is already a problem with too many libraries, consuming too much time on startup even on big desktop computers. Efforts to rationalize the number of libraries are underway but apparently not so easy. Just splitting glib for the sake of doing it isn't very wise IMO. Xav PS: could you avoid trimming the Cc: list ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Tue, 2007-04-24 at 11:25 -0500, Brandon Casey wrote: [snip] > The problems I ran into compiling gettext and glib are not problems I > had yesterday. They are older problems that have since been solved. [snip] So there doesn't seem to be any actual problem, so nothing to fix. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Tue, 24 Apr 2007, Behdad Esfahbod wrote: > On Tue, 2007-04-24 at 03:26 -0400, Xavier Bestel wrote: >> Hi Brandon, >> >> On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote: >>> My point is _not_ that these features are not useful, just >>> that glib would be a better library with a more strict focus and useful >>> to more developers if some of this functionality were moved to a >>> separate library. >> >> Don't forget that the more libraries you have, the longer the dynamic >> linker will work to resolve all the symbols, and consequently the longer >> it will take for each application to start. > > And each shared library consumes at least one page of private > per-process data memory. The concern is organizational rather than with absolute minimal memory consumption or program loading speed. The goal is to have as few separate libraries as necessary to organize the components according to function and ease library use. -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Tue, 2007-04-24 at 03:26 -0400, Xavier Bestel wrote: > Hi Brandon, > > On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote: > > My point is _not_ that these features are not useful, just > > that glib would be a better library with a more strict focus and useful > > to more developers if some of this functionality were moved to a > > separate library. > > Don't forget that the more libraries you have, the longer the dynamic > linker will work to resolve all the symbols, and consequently the longer > it will take for each application to start. And each shared library consumes at least one page of private per-process data memory. > Xav -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
Hi, Brandon Casey wrote: > It's hard for me to think of unicode as > being low-level when it adds so much overhead to string handling. I think many just wouldn't agree - yes it adds overhead, but without Unicode, string handling doesn't *work* - so saving the overhead is pretty useless unless your app deals purely in binary data and never displays any human-readable strings. Binary/unknown-encoding text can't be displayed, even on a terminal. How many apps don't display text? Not a whole lot of them. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
Brandon Casey wrote: > It's hard for me to think of unicode as > being low-level when it adds so much overhead to string handling. Isn't (a part of) the unicode handling needed for correctly processing paths under Windows? As I remember it, Windows-native calls take either ASCII or a slightly modified UTF-16LE (aka UCS-2). In order to be able to have code that needs to open "strangely" named files on any platform, at least a modicum of unicode support is needed. Once you have that, including gettext as a dependency seems straight-forward. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Tue, 24 Apr 2007, Murray Cumming wrote: > On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote: >> The problem I had was in compiling glib on IRIX and its dependency >> on gettext. > > Thanks, finally. Details are good. I note that this is about building > from source, not at all about performance. > [snip] > > But, if you mention your gettext build problems in detail, someone might > be able to help you. The problems I ran into compiling gettext and glib are not problems I had yesterday. They are older problems that have since been solved. I appreciate your offer to help, it's just not why I was posting. I guess that's why I didn't lay out a problem from the beginning. My posting was intended to suggest that glib would be a better library if its focus was narrowed. I think some of what has been added, including unicode handling has expanded the scope of glib beyond its stated goal of being a low-level core library. It's hard for me to think of unicode as being low-level when it adds so much overhead to string handling. Please don't interpret this to mean that unicode is not important or worth it. The only suggestion is that glib is not the right place for it. I hope you will consider it, maybe there will be an opportunity to change glib in the future if it's worth it. -brandon >> I had some trouble compiling gettext, but I did not see >> that as the issue, rather glib's dependency on gettext. I'm not sure >> if glib should have any dependencies. With enough effort you can get >> anything to compile on any system. For me it was gettext, for someone >> else maybe iconv, for someone else maybe some other dependency that is >> already installed on my system. >> >> I think the value of glib, to developers not creating a gtk+ program, >> is in the data structures it provides. Good, stable, implementations >> of lists, arrays, hashes, binary trees, etc. I also find the portability >> macros useful. If you are writing a gtk+ program, it doesn't matter >> because you need everything anyway. >> >> So this low-level core library requires gettext, and iconv and all of >> this Unicode manipulation functionality that isn't needed to implement >> a good linked list or g_malloc or a gint32. >> >> I think I'm starting to ramble, so I'll just end with.. >> I think glib has strayed somewhat from being a low-level core library >> with the inclusion of unicode handling for one and possibly other >> features. My point is _not_ that these features are not useful, just >> that glib would be a better library with a more strict focus and useful >> to more developers if some of this functionality were moved to a >> separate library. This would make glib leaner and easier to compile >> (with fewer dependencies), and hence more portable. > > -- > Murray Cumming > [EMAIL PROTECTED] > www.murrayc.com > www.openismus.com > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote: > The problem I had was in compiling glib on IRIX and its dependency > on gettext. Thanks, finally. Details are good. I note that this is about building from source, not at all about performance. I can't imagine that anyone is seriously using IRIX (or other obscure Unixes) for something non-commercial. If it's commercial, I can recommend that you get prebuilt packages from http://www.thewrittenword.com/ They even have gtkmm and applications such as Inkscape in their set. I've done some porting work for them. Building from source is difficult and always will be. People shouldn't have to build from source. I'd expect the glib developers to only really be worried about that kind of thing if package builders have difficulty building from source. But, if you mention your gettext build problems in detail, someone might be able to help you. > I had some trouble compiling gettext, but I did not see > that as the issue, rather glib's dependency on gettext. I'm not sure > if glib should have any dependencies. With enough effort you can get > anything to compile on any system. For me it was gettext, for someone > else maybe iconv, for someone else maybe some other dependency that is > already installed on my system. > > I think the value of glib, to developers not creating a gtk+ program, > is in the data structures it provides. Good, stable, implementations > of lists, arrays, hashes, binary trees, etc. I also find the portability > macros useful. If you are writing a gtk+ program, it doesn't matter > because you need everything anyway. > > So this low-level core library requires gettext, and iconv and all of > this Unicode manipulation functionality that isn't needed to implement > a good linked list or g_malloc or a gint32. > > I think I'm starting to ramble, so I'll just end with.. > I think glib has strayed somewhat from being a low-level core library > with the inclusion of unicode handling for one and possibly other > features. My point is _not_ that these features are not useful, just > that glib would be a better library with a more strict focus and useful > to more developers if some of this functionality were moved to a > separate library. This would make glib leaner and easier to compile > (with fewer dependencies), and hence more portable. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
Hi Brandon, On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote: > My point is _not_ that these features are not useful, just > that glib would be a better library with a more strict focus and useful > to more developers if some of this functionality were moved to a > separate library. Don't forget that the more libraries you have, the longer the dynamic linker will work to resolve all the symbols, and consequently the longer it will take for each application to start. Xav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Emmanuele Bassi wrote: > On Mon, 2007-04-23 at 14:01 -0500, Brandon Casey wrote: >> On Mon, 23 Apr 2007, Murray Cumming wrote: >>> On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: >>> [snip] What do we do? >>> [snip] >>> >>> We wait until someone has an actual need for such a change, or an actual >>> problem. >> >> Uh, I don't get it. Do you imply the problem and need I described are >> not actual? Whoa. That stirred up a hornets nest. I thought Murray's comment was a little sarcastic so I responded with a little sarcasm myself. But he's right, I didn't actually state a problem. It wasn't intentional, I just didn't think my specific case was important. > honestly, I still don't quite understand the problem you have, as you've > been pretty vague about what problems you encountered in porting GLib on > a 'non-linux' platform. The problem I had was in compiling glib on IRIX and its dependency on gettext. I had some trouble compiling gettext, but I did not see that as the issue, rather glib's dependency on gettext. I'm not sure if glib should have any dependencies. With enough effort you can get anything to compile on any system. For me it was gettext, for someone else maybe iconv, for someone else maybe some other dependency that is already installed on my system. I think the value of glib, to developers not creating a gtk+ program, is in the data structures it provides. Good, stable, implementations of lists, arrays, hashes, binary trees, etc. I also find the portability macros useful. If you are writing a gtk+ program, it doesn't matter because you need everything anyway. So this low-level core library requires gettext, and iconv and all of this Unicode manipulation functionality that isn't needed to implement a good linked list or g_malloc or a gint32. I think I'm starting to ramble, so I'll just end with.. I think glib has strayed somewhat from being a low-level core library with the inclusion of unicode handling for one and possibly other features. My point is _not_ that these features are not useful, just that glib would be a better library with a more strict focus and useful to more developers if some of this functionality were moved to a separate library. This would make glib leaner and easier to compile (with fewer dependencies), and hence more portable. -brandon > dependencies? yes, they are an issue, but unfortunately stuff that is > considered "core features" of GLib requires them. GLib maintainers have > been very wary about adding dependencies, so you cannot accuse them to > be "dependencies happy". > > if you want to target a specific system you can remove stuff from GLib > yourself, by adding switches to configure.in; for instance, you can > remove most of the main loop, gmarkup and gkeyfile without really > creating much of an hassle; obviously, the resulting library would be > completely useless on most of the platforms following the GMAE stack, so > I don't think a patch introducing those switches would be applied > upstream. > > ciao, > Emmanuele. > > -- > Emmanuele Bassi, E: [EMAIL PROTECTED] > W: http://www.emmanuelebassi.net > B: http://log.emmanuelebassi.net > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 14:01 -0500, Brandon Casey wrote: > On Mon, 23 Apr 2007, Murray Cumming wrote: > > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > > [snip] > >> What do we do? > > [snip] > > > > We wait until someone has an actual need for such a change, or an actual > > problem. > > Uh, I don't get it. Do you imply the problem and need I described are > not actual? Or are you saying the wait is over since I have described > such? You just said "it's bloated" and did not state any specific problem you faced. So what exactly is the problem? ciao, --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 14:01 -0500, Brandon Casey wrote: > On Mon, 23 Apr 2007, Murray Cumming wrote: > > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > > [snip] > >> What do we do? > > [snip] > > > > We wait until someone has an actual need for such a change, or an actual > > problem. > > Uh, I don't get it. Do you imply the problem and need I described are > not actual? Or are you saying the wait is over since I have described > such? > I've been reading this thread since: http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00077.html Are you somehow implying that you outlined a problem ? That glib is "difficult to compile" on some platforms ? is that what irks you so ? Maybe you could help out by writing a howto or a tutorial for those who prepare platform binaries for thier distributions... Or maybe its more verbosity from the existing build scripts that is needed... Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 14:01 -0500, Brandon Casey wrote: > On Mon, 23 Apr 2007, Murray Cumming wrote: > > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > > [snip] > >> What do we do? > > [snip] > > > > We wait until someone has an actual need for such a change, or an actual > > problem. > > Uh, I don't get it. Do you imply the problem and need I described are > not actual? honestly, I still don't quite understand the problem you have, as you've been pretty vague about what problems you encountered in porting GLib on a 'non-linux' platform. dependencies? yes, they are an issue, but unfortunately stuff that is considered "core features" of GLib requires them. GLib maintainers have been very wary about adding dependencies, so you cannot accuse them to be "dependencies happy". if you want to target a specific system you can remove stuff from GLib yourself, by adding switches to configure.in; for instance, you can remove most of the main loop, gmarkup and gkeyfile without really creating much of an hassle; obviously, the resulting library would be completely useless on most of the platforms following the GMAE stack, so I don't think a patch introducing those switches would be applied upstream. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 15:01 -0400, Brandon Casey wrote: > On Mon, 23 Apr 2007, Murray Cumming wrote: > > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > > [snip] > >> What do we do? > > [snip] > > > > We wait until someone has an actual need for such a change, or an actual > > problem. > > Uh, I don't get it. Do you imply the problem and need I described are > not actual? Or are you saying the wait is over since I have described > such? What exactly is the problem you are trying to solve? "embedded" is not a problem statement. Nor is "to save size". "I need to run a glib-using app in 3mb and it doesn't fit" may be. > -brandon -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Murray Cumming wrote: > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > [snip] >> What do we do? > [snip] > > We wait until someone has an actual need for such a change, or an actual > problem. Uh, I don't get it. Do you imply the problem and need I described are not actual? Or are you saying the wait is over since I have described such? -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: [snip] > What do we do? [snip] We wait until someone has an actual need for such a change, or an actual problem. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: is glib too bloated?
>For the record, I dont think glib is oversized or bloated at >all, I dont think its size is even a concern worth considering >even in embedded world, that being said... FYI Here is part of an "ls -la" off an ARM embedded device. (ARM being the x86 of embedded devices) 190260 Mar 14 2007 libdbus-1.so.3.2.0 193344 Mar 14 2007 libgmp.so.3.4.1 210240 Mar 14 2007 libcroco-0.6.so.3.0.1 227516 Mar 14 2007 libssl.so.0.9.8 241984 Mar 14 2007 libgobject-2.0.so.0.800.6 262660 Mar 14 2007 libcairo.so.2.2.4 275464 Mar 14 2007 libid3-3.8.so.3.0.0 300272 Mar 14 2007 libgcrypt.so.11.2.3 314996 Mar 14 2007 liboil-0.3.so.0.1.0 323176 Mar 14 2007 libsqlite3.so.0.8.6 360500 Mar 14 2007 libparted-1.7.so.1.0.0 370200 Mar 14 2007 libfreetype.so.6.3.8 549928 Mar 14 2007 libglib-2.0.so.0.800.6 623180 Mar 14 2007 libgstreamer-0.10.so.0.8.1 650416 Mar 14 2007 libasound.so.2.0.0 Libgobject is big but not lots of things are bigger. --David Moffatt. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Havoc Pennington wrote: > Michael L Torrie wrote: >> 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. >> > > The real question of course is whether everyone's "use" and "don't use" > lists are similar or not. I'm thinking we should be asking whether the glib functions are similar enough to be included in the same library and whether they fit with the stated scope of glib as a "low-level core library". "use and "don't use" is just going to cause a lot of bickering since the intersection of "use" lists is pretty small. > It's a little bit academic, since splitting up the lib wouldn't be > ABI-compatible, so the bar for it to be worth it is extremely high. > Embedded systems can always split it up themselves in a custom way if > they really care. It's always easy to add new functionality. It's hard deciding where it's _appropriate_ to stop. Since ABI compatibility is _very_ important. What do we do? If we come to an academic agreement that developers would be better served by splitting glib into a base library and a higher level library, how do we accomplish that? And how do we avoid situations like this in the future? -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Havoc Pennington wrote: > Brandon Casey wrote: >> And this has caused the dependency >> requirements of glib to grow, which makes it harder to build (think non >> linux platforms). > > OTOH, having all the portability goo in GLib makes all the *apps* easier to > build once you get GLib done. Most of the stuff in GLib _is_ needed by GTK+ > apps at least ... you can't write nonbroken apps without the Unicode bits, > for example. Oh, I definitely did not suggest getting rid of any of it. At the same time you don't need the Unicode bits to implement linked lists, hash tables, arrays, binary trees, memory slices, etc. -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 11:28 -0400, Tristan Van Berkom wrote: > On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote: > > 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? > > > > Heh, yeah maybe my idea of gobject'ized glib data structs is a little > futile :) not sure just exactly what I'd do with a derivable GList, > I'm sure something random could come of it haha, maybe > GQueues/GAsyncQueues could be extended glists etc - I guess in the end > that sort of thing would just be libfancyobjects :) > > Might be an interesting thing from a bindings point of view... I dunno I've found myself wanting GObject derived GList. The idea is to have a "list of things with some GType", and make the API which modifies that list emit "changed", "deleted", "inserted" signals, etc. I coded a GObject derived class to do most of this. One thing missing with GList is type safety of course, but if you want, you can add run-time type safety with a class around it. Peter Clifton ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Ross Burton wrote: > On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote: >> 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. > > That is the current state: libglib only contains main loop, lists, > strings, hashes and so on. On top of that there is libgmodule, > libgobject, and libgthread. If you don't need objects and threads, you > don't need to use them. But we still need to compile glib with all of the dependency requirements that this additional functionality imposes. Think about why there is a libgmodule, libgobject, and libgthread. Why don't we compile all of that functionality into a single library? Linking would be easier. We group functionality with a similar focus together to make it more modular and easier to re-use; Re-use is encouraged and desirable. -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
Brandon Casey wrote: > And this has caused the dependency > requirements of glib to grow, which makes it harder to build (think non > linux platforms). OTOH, having all the portability goo in GLib makes all the *apps* easier to build once you get GLib done. Most of the stuff in GLib _is_ needed by GTK+ apps at least ... you can't write nonbroken apps without the Unicode bits, for example. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Emmanuele Bassi wrote: > On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote: >> On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote: >>> >>> I am posting to suggest that glib has crossed a threshold >>> of size and functionality and that users would benefit from >>> a splitting of the library into two or more separate libraries. >> >> For the record, I dont think glib is oversized or bloated at >> all, I dont think its size is even a concern worth considering >> even in embedded world, that being said... > > for my experience, you're right: even GTK+ is not "bloated" in that > respect. I've seen my share of compressed filesystem images containing > the whole stack from X up to GStreamer in ~16MB, so everything could be > said about GLib but it being "bloated". There is nothing implemented in GLib that is not useful in some way to the GTK+ stack. So I agree that the functionality is not bloat. I only suggest that the inclusion of some of this functionality in GLib has increased the scope of GLib. It's no secret that GLib-2 is 4 times larger than GLib-1. The absolute number is still fairly small, but the change in size indicates that there is 4 times as much stuff in GLib-2. I suspect that a lot of the increase in size is due to i18n efforts in dealing with strings. And this has caused the dependency requirements of glib to grow, which makes it harder to build (think non linux platforms). I think there are developers out there who would benefit from a narrowing of the scope of glib, so that it only contains "base" data structures and functionality (yeah I know, define "base"). And move the more higher level functionality into another library. -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote: > 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. That is the current state: libglib only contains main loop, lists, strings, hashes and so on. On top of that there is libgmodule, libgobject, and libgthread. If you don't need objects and threads, you don't need to use them. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote: > 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? > Heh, yeah maybe my idea of gobject'ized glib data structs is a little futile :) not sure just exactly what I'd do with a derivable GList, I'm sure something random could come of it haha, maybe GQueues/GAsyncQueues could be extended glists etc - I guess in the end that sort of thing would just be libfancyobjects :) Might be an interesting thing from a bindings point of view... I dunno Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
Michael L Torrie wrote: > 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. > The real question of course is whether everyone's "use" and "don't use" lists are similar or not. It's a little bit academic, since splitting up the lib wouldn't be ABI-compatible, so the bar for it to be worth it is extremely high. Embedded systems can always split it up themselves in a custom way if they really care. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 , > 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 > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote: > On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote: > > > > I am posting to suggest that glib has crossed a threshold > > of size and functionality and that users would benefit from > > a splitting of the library into two or more separate libraries. > > For the record, I dont think glib is oversized or bloated at > all, I dont think its size is even a concern worth considering > even in embedded world, that being said... for my experience, you're right: even GTK+ is not "bloated" in that respect. I've seen my share of compressed filesystem images containing the whole stack from X up to GStreamer in ~16MB, so everything could be said about GLib but it being "bloated". > 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, and how could gobject use those data structures if they are placed above gobject? they would become part of gobject - and *that* would "bloat" GLib (obviously, "bloat" is the whole point of having a separate gobject library is to avoid the runtime type system if you just want to data types. having said that, the only thing that I would like having is a (G)type safe container abstract class - but that can be built upon GList/GSequence and the GType API in less than 100 lines of code probably. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote: > > I am posting to suggest that glib has crossed a threshold > of size and functionality and that users would benefit from > a splitting of the library into two or more separate libraries. For the record, I dont think glib is oversized or bloated at all, I dont think its size is even a concern worth considering even in embedded world, that being said... 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). The biggest advantage to this, and everyone will disagree , 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
Re: is glib too bloated?
On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote: > I am posting to suggest that glib has crossed a threshold > of size and functionality and that users would benefit from > a splitting of the library into two or more separate libraries. > > [...] > > The growth in size and in dependencies is making it difficult > to compile glib on non linux platforms. It is regrettable > that some software projects have to avoid glib because of this, > and then re-invent the wheel when glib has a well tested, stable > and secure version. I think we need some specifics: - What exactly is not portable? - On which non-linux platforms is it failing? - What dependencies are problematic? - Which projects are known to be suffering as a result? While I agree that the GLib maintainers need to be prudent about what goes into GLib, almost all of what's currently in there seems like pretty basic stuff to me. I think the definition of "basic functionality" has expanded over time, though, and C needs more and more help to keep up with functionality that's implicit in other, more modern languages. Also consider the fact that GLib already consists of multiple libraries (GLib, GObject, GThread, and possibly a future GVFS). -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
is glib too bloated?
I am posting to suggest that glib has crossed a threshold of size and functionality and that users would benefit from a splitting of the library into two or more separate libraries. In my opinion, it is exceeding its stated purpose as a "low-level core library"... "provid[ing] data structure handling for C, portability wrappers, and" a few other things that should or should not be included. Has any thought been given to splitting glib into two libraries? The first which would contain all the data structure stuff like linked lists, hash tables, binary trees, arrays, all the gint, gint32, etc, and portability macros. I suggest that this portion of the library retain the glib. The second would be a new library built on top of glib taking over anything not considered "core", such as xml parsers, unicode handling, and anything that depends on them. The core data structures that glib provides are excellent implementations of well known and often used functionality. The same goes for the portability macros. The growth in size and in dependencies is making it difficult to compile glib on non linux platforms. It is regrettable that some software projects have to avoid glib because of this, and then re-invent the wheel when glib has a well tested, stable and secure version. -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
