Re: Get rid of deprecated widgets
On Wed, 2007-12-05 at 20:26 +0100, Soeren Sandmann wrote: Alexander Larsson [EMAIL PROTECTED] writes: A possibly interesting approach would be to put all the deprecated code in another ELF section and place that section at the end. This will mean that the deprecated stuff will be in one continous place and might make paging in non-deprecated code slightly more efficient and less seeky. I'm not sure you would be able to measure the difference this would make though... That particular optimization may not be very measurable, but having the ability to move arbitrary functions around would make it possible to put the most used functions together at the front of the library, based on a desktop-wide profile. This would very likely be measurable. Someone could try using -freorder-functions which does this, based on a profile. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
Hi, Xavier Bestel schrieb: On mer, 2007-12-05 at 14:09 +0100, Alexander Larsson wrote: The only way to make this backwards compatible is to make libgtk-2.0.so.0 have the deprecated symbols and link to libgtk-no-compat-2.0.so.0 which doesn't. Then normal apps will keep working, and apps that don't need compat widgets will need to link with -lgtk-no-compat-2.0. Each new releases may deprecate some symbols. So what's needed is a symbolic library name per release, and say when you release gtk+2.14, make libgtk-2.0.so ... libgtk-2.12.so all point to the same thing (with all deprecated symbols) which then links to libgtk-2.14.so with only supported symbols. Removing the deprecated stuff is in most cases not an option. But lowering the impact is. WHat kind of impact have they? 1) longer symbol resolving on startup 2) memory usage 3) locatisation 4) ??? 2) can be addressed like i described in http://bugzilla.gnome.org/show_bug.cgi?id=471123 Now it would be great if we could also tell the linker to resolve deprecated entries lazily. That would help with 1). For 3) one could maybe redef _(). Needs to be tried. Stefan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
On Wed, 2007-05-12 at 12:17 +0100, Mikael Hermansson wrote: Hello! Some thoughts For years now there has been widgets that is deprecated in Gtk+ GtkList GtkCList GtkFileSel GtkCTree GtkItemFactory Pidgin still uses GtkItemFactory. Gabriel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
On Dec 6, 2007 3:04 PM, Stefan Kost [EMAIL PROTECTED] wrote: Hi, Xavier Bestel schrieb: On mer, 2007-12-05 at 14:09 +0100, Alexander Larsson wrote: The only way to make this backwards compatible is to make libgtk-2.0.so.0 have the deprecated symbols and link to libgtk-no-compat-2.0.so.0 which doesn't. Then normal apps will keep working, and apps that don't need compat widgets will need to link with -lgtk-no-compat-2.0. Each new releases may deprecate some symbols. So what's needed is a symbolic library name per release, and say when you release gtk+2.14, make libgtk-2.0.so ... libgtk-2.12.so all point to the same thing (with all deprecated symbols) which then links to libgtk-2.14.so with only supported symbols. Removing the deprecated stuff is in most cases not an option. But lowering the impact is. WHat kind of impact have they? I've been watching this topic for a while, and it comes back up every so often, I would actually say something quite to the contrary: Lowering the impact of deprecated widgets and code paths is probably not ever worth the effort (I dont believe the impact is that great, especially if you are not pulling in libgnomeui and friends). OTOH the (quite valid) option of breaking the api could be alot more useful, who cares about the short term gains - a thorough code cleanup and refactoring of gtk+ cannot be done without breaking the api, how can we work on new features/functionality and even code optimization before breaking the api and refactoring ? Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
On Thu, 2007-12-06 at 19:04 +0200, Stefan Kost wrote: Hi, Xavier Bestel schrieb: On mer, 2007-12-05 at 14:09 +0100, Alexander Larsson wrote: The only way to make this backwards compatible is to make libgtk-2.0.so.0 have the deprecated symbols and link to libgtk-no-compat-2.0.so.0 which doesn't. Then normal apps will keep working, and apps that don't need compat widgets will need to link with -lgtk-no-compat-2.0. Each new releases may deprecate some symbols. So what's needed is a symbolic library name per release, and say when you release gtk+2.14, make libgtk-2.0.so ... libgtk-2.12.so all point to the same thing (with all deprecated symbols) which then links to libgtk-2.14.so with only supported symbols. Removing the deprecated stuff is in most cases not an option. But lowering the impact is. WHat kind of impact have they? 1) longer symbol resolving on startup This is unlikely to be affected. There is one hash lookup per shared object in the global namespace on each symbol resolve. The number of symbols in a shared object should not affect things much, as the hash table is just made larger. 2) memory usage If its not used, should be little. It does affect paging behaviour of the other code though, so some code/data rearrangement would probably help a bit. 3) locatisation All of this stuff is old, doesn't change and is already translated, so I don't think its a huge problem. 2) can be addressed like i described in http://bugzilla.gnome.org/show_bug.cgi?id=471123 I added a comment to this, because I don't think the method described will work as well as it can. Now it would be great if we could also tell the linker to resolve deprecated entries lazily. That would help with 1). ELF symbols are always lazily resolved. Unless LD_BIND_NOW is defined (on linux/gnu). One can further reduce the costs of symbol lookups with prelink. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Get rid of deprecated widgets
Hello! Some thoughts For years now there has been widgets that is deprecated in Gtk+ GtkList GtkCList GtkFileSel GtkCTree GtkItemFactory Imho it really is time to kill this or atleast add an option in Makefile/configure to not include them as default. If there still is apps that using this old API(is there any???) they should just copypaste it to theyr project or just migrate to the new widgets. Reason for this: 1. Cleaning up librarys is always good. 2. If developers still using deprecated code they should help fix the new code instead of using deprecated widgets. 3. Symboltable for Gtk+ will be less, means faster startuptime and less memory consumtion. I know probadly not mush but still there is other librarys too thats need to be killed in the future: Bonobo[ui]/libgnome[ui] and so on. 4. Gtk+ team will not get asked questions/bugreports about the old API if new app developers have missed that those widgets is already deprecated. This has probadly been discussed before and some will say this will break ABI/API and it will not happen until Gnome 3.0 But IMHO why wait that long Gnome 3.0 has been discussed for year to and will probadly not hit the streets for years :-) Dont get me wrong I know your people working hard but still we need to get rid deprecated code :-) also true for libgnome/bonobo :-) Imho we should kill those widgets in next release of Gtk+ by add an option in configure --enable-deprecated=yes (if not passed it wwill NOT build those deprecated widgets) ;-) Greets Mikael Hermansson ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
Am Mittwoch, den 05.12.2007, 12:17 +0100 schrieb Mikael Hermansson: Hello! Some thoughts For years now there has been widgets that is deprecated in Gtk+ GtkList GtkCList GtkFileSel GtkCTree GtkItemFactory Imho it really is time to kill this or atleast add an option in Makefile/configure to not include them as default. If there still is apps that using this old API(is there any???) they should just copypaste it to theyr project or just migrate to the new widgets. I am also supporting this idea for a long time: There is no point in deprecating code, if you plan to support it forever. Regarding ABI stability: That old code could be moved into libgtk-compat-2.0.so. So programs that still want to use deprecated widgets: - link against an old version of gtk - for what other reason gtk is using libtool's -version-info switch? - link against libgtk-compat-2.0. Its really pointless to pay of this old stuff everyday, when none of your daily programs uses those old and deprecated symbols. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
On Wed, Dec 05, 2007 at 01:04:36PM +0100, Mathias Hasselmann wrote: Am Mittwoch, den 05.12.2007, 12:17 +0100 schrieb Mikael Hermansson: For years now there has been widgets that is deprecated in Gtk+ GtkList GtkCList GtkFileSel GtkCTree GtkItemFactory Its really pointless to pay of this old stuff everyday, when none of your daily programs uses those old and deprecated symbols. I'm a developer of the Wireshark project, which is a daily program for many people. We still use GtkCList and GtkItemFactory in some places of our GTK2 code (we still fully support linking against GTK1 but that's another story). Steve ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
Alexander Larsson [EMAIL PROTECTED] writes: A possibly interesting approach would be to put all the deprecated code in another ELF section and place that section at the end. This will mean that the deprecated stuff will be in one continous place and might make paging in non-deprecated code slightly more efficient and less seeky. I'm not sure you would be able to measure the difference this would make though... That particular optimization may not be very measurable, but having the ability to move arbitrary functions around would make it possible to put the most used functions together at the front of the library, based on a desktop-wide profile. This would very likely be measurable. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
On 05 Dec 2007 20:26:39 +0100, Soeren Sandmann [EMAIL PROTECTED] wrote: Alexander Larsson [EMAIL PROTECTED] writes: A possibly interesting approach would be to put all the deprecated code in another ELF section and place that section at the end. This will mean that the deprecated stuff will be in one continous place and might make paging in non-deprecated code slightly more efficient and less seeky. I'm not sure you would be able to measure the difference this would make though... That particular optimization may not be very measurable, but having the ability to move arbitrary functions around would make it possible to put the most used functions together at the front of the library, based on a desktop-wide profile. This would very likely be measurable. If the goal is to avoid i/o at startup time, one old idea is to do avoid the _() approach to translating property nicks and blurbs and instead translate them only when they are actually accessed. Currently, gtk20-properties.mo gets paged in at startup to translate all those strings which only gui editors are going to need. Thats 144k. Maybe it is not worth the effort. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
On Wed, 2007-12-05 at 13:04 +0100, Mathias Hasselmann wrote: Am Mittwoch, den 05.12.2007, 12:17 +0100 schrieb Mikael Hermansson: Hello! Some thoughts For years now there has been widgets that is deprecated in Gtk+ GtkList GtkCList GtkFileSel GtkCTree GtkItemFactory Imho it really is time to kill this or atleast add an option in Makefile/configure to not include them as default. If there still is apps that using this old API(is there any???) they should just copypaste it to theyr project or just migrate to the new widgets. I am also supporting this idea for a long time: There is no point in deprecating code, if you plan to support it forever. Regarding ABI stability: That old code could be moved into libgtk-compat-2.0.so. So programs that still want to use deprecated widgets: - link against an old version of gtk - for what other reason gtk is using libtool's -version-info switch? - link against libgtk-compat-2.0. Its really pointless to pay of this old stuff everyday, when none of your daily programs uses those old and deprecated symbols. The only way to make this backwards compatible is to make libgtk-2.0.so.0 have the deprecated symbols and link to libgtk-no-compat-2.0.so.0 which doesn't. Then normal apps will keep working, and apps that don't need compat widgets will need to link with -lgtk-no-compat-2.0. Of course, this would only be ABI compat on platforms with late symbol binding, like ELF. However as long as any library you use needs (or accidentally links to) the compat lib this will pull in an extra library which will slow down all symbol resolves and require an extra private page per process. This is far worse than some unused code on the disk which is not even paged in. A possibly interesting approach would be to put all the deprecated code in another ELF section and place that section at the end. This will mean that the deprecated stuff will be in one continous place and might make paging in non-deprecated code slightly more efficient and less seeky. I'm not sure you would be able to measure the difference this would make though... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
