Re: gtkspell (was Re: Announcing: Project Ridley)
I'm not a Gtk+ developer, but I think one of the criteria for being considered is: doesn't introduce a new library dependency, or maybe it can, if it really makes sense. Gtk+ depending on a spell checking library hardly makes sense, however. On Fri, 26 Aug 2005, Mike Hearn wrote: Yes, it's yet another me too post, this time for gtkspell. Spelling checker support is widely used in many apps, and from my POV is a huge pain because gtkspell is a very common failed dependency for autopackages. We provide tools to make weak linking against this library simple but a few projects for whatever mysterious reasons they have refuse to use them. Being able to guarantee the presence of GtkSpell by depending on GTK+ would be wonderful. Last time I asked about this, Owen indicated he didn't think it belonged in GTK+ but maybe this Project Ridely means a change in policy? thanks -mike Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
Il giorno dom, 21/08/2005 alle 00.50 -0400, Jonathan Blandford ha scritto: Now that GTK+-2.8.0 is out, the GTK+ team would like to announce Project Ridley. GOALS: The primary goal of Project Ridley is to cut down on the number of problem libraries that are part of the GNOME platform. We propose to do this by moving functionality into GTK+, wherever it makes sense. These libraries are generally small, undermaintained, and buggy. They have an unclear purpose (such as libgnome and libgnomeui), are copied-and-pasted around (such as libegg) or would benefit by being in GTK+ (libgnomeprint and libgnomeprintui.) Not well fitting with this disclaimer, but are any interesting widget in GIMP to include in Project Ridley? For instance the small cross-arrow between the vertical and the horizontal scrollbars, used to scroll the image when zoomed in showing a thumbnail, could be useful for other GNOME application related to image (eog, gthumb, f-spot) and document (evince) viewing. Could someone explore and report about GTK+ widgets in GIMP sources useful for other applications? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkspell (was Re: Announcing: Project Ridley)
On 8/27/05, Chipzz [EMAIL PROTECTED] wrote: I'm not a Gtk+ developer, but I think one of the criteria for being considered is: doesn't introduce a new library dependency, or maybe it can, if it really makes sense. Gtk+ depending on a spell checking library hardly makes sense, however. I would envision a solution having two parts here: - some framework in GtkEntry/GtkTextView to support spellchecking - a module which makes use of the framework. The module could use Enchant, GtkSpell or any other spell-checking library - the module could be loaded desktop-wide, by using the gtk-modules setting that was introduced for this purpose a while ago. Maybe thats a totally wrong approach, I haven't thought too long about it. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkspell (was Re: Announcing: Project Ridley)
On 1/19/06, Matthias Clasen [EMAIL PROTECTED] wrote: On 8/27/05, Chipzz [EMAIL PROTECTED] wrote: I'm not a Gtk+ developer, but I think one of the criteria for being considered is: doesn't introduce a new library dependency, or maybe it can, if it really makes sense. Gtk+ depending on a spell checking library hardly makes sense, however. I would envision a solution having two parts here: - some framework in GtkEntry/GtkTextView to support spellchecking - a module which makes use of the framework. The module could use Enchant, GtkSpell or any other spell-checking library - the module could be loaded desktop-wide, by using the gtk-modules setting that was introduced for this purpose a while ago. Enchant has been API/ABI stable for a while now, so I wouldn't mind proposing it for inclusion to the platform at some future point (or better still, free desktop). Chris Hammond's libsexy has a spell checking enabled GtkEntry subclass that depends on Enchant. It dlopen()'s the .so and looks up the functions by name rather than linking against it explicitly. If the module isn't found, spell checking is disabled. This might be something of a compromise solution, since it gives consumers a soft dependency on a spell checking lib rather than a hard dependency. Best, Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkspell (was Re: Announcing: Project Ridley)
Hi folks, GtkSpell lacks some features and I've been aware of the lack for years -- even since the GTK 2 days. I haven't had the time to work on GtkSpell and so finally, rather than stifling it by hanging on too tightly, I found a new maintainer, who has done a great job of making incremental releases (including, from a glance at the ChangeLog, perhaps fixing the tagtable bug that Alex mentioned). But he appears to also be busy. This project is a superficially simple one but also has had enough eyeballs (see Pango bug 97545, which I logged and worked around back in 2002 -- maybe it's since been fixed? again, the GtkSpell ChangeLog indicates otherwise) that it ought to be a great project for someone looking into adding some lower-in-the-stack functionality that would benefit a lot of projects. Or, another way of saying it: contributors welcome. On 8/26/05, Chipzz [EMAIL PROTECTED] wrote: Something that really bothers me about gtkspell too is the lack of an option in the popup to change the language. While by default it uses your desktop language (I think), which is something that makes sense, there are a lot of non-native English speakers running their desktops in English (I, for example, am a native Dutch speaker, but I really hate to run my desktop in Dutch). This is a real annoyance in gaim for example: it labels allmost all of the words as incorrect. On Fri, 26 Aug 2005, Alex Graveley wrote: I'm all for spellchecking in Gtk, but GtkSpell has been nothing but trouble for me in Tomboy. It still doesn't handle multiple textbuffers sharing a tag table (which means that rich copy/paste doesn't work), and has some serious memory leaks (though this may be due in part to pspell). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Matthias Clasen [EMAIL PROTECTED] schrieb: snip Maybe just moving deprecated widgets to a separate library, like libgtk2.0-compat.la, would be a better solution? We'd get well maintained applications to avoid linking to this library, while at the same time keeping it around for those apps that just need it and whose authors are stuburn enough to not want to update. So let those apps depend on GTK+-2.x, like many depend on 1.2 now. Moving widgets to separate library will require some changes in related apps anyway. This gets proposed repeatedly, Unfortunately, it does not offer significant benefits that would justify the costs of doing this. Splitting GTK+ into multiple shared libraries increases the cost of symbol resolution. It does not reduce the memory consumption You're right, as long as we're talking about splitting such silly borders as proposed. We instead should move larger/more complex widgets and dialogs to their own library, or better to their own package. For example I dont see any reason for having something like a printer dialog layout around on my system if no one really uses it. snip significantly, since all the deprecated functions are unlikely to be paged in anyway. It does complicate the build considerably. Build would become much simplier if we had a bunch of smaller libs, divided on clear and useful borders. Well, it could even easier if we had an simple and deterministic buildsystem, but that's another story ... cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Banginwar, Rajesh [EMAIL PROTECTED] schrieb: I am really glad to see the intention of keeping the ABI same even with 3.0 release. I'm not. Binary compatibiliy prevents us from changes in the library structures, ie. which widgets belong into which lib. Normally a new major release introduces many heavy changes - that's why its called 'major'. No one every reall expects binary compatibility, or even full source compatibilty on new major releases. They're in fact different packages with different interfaces, just doing quite the same. If you wanna have binary compatibility, just stay in the 2.x line. Or with other words: if a new release is binary compatible with 2.x, it should also be called an 2.x. As we are going to include GTK 2.4 or 2.6 (based on distro feedback; e.g. Redhat ships with 2.4) in the first release of desktop module of LSB, having ABI compatibility even after platform consolidation is a welcome decision. You probably don't want this with an 3.0 seriously. Major releases are normally *large* changes and it will take time that applications become ported to the new interface. See gtk-1.x vs. gtk-2.x There are still a lot of gtk-1.x applications out there. gtk1 vs. gtk2 are completely different packages. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Rob Adams [EMAIL PROTECTED] schrieb: snip I don't really see much reason ever to break ABI for the forseeable future. There's essentially nothing stopping us from simply leaving deprecated functions in there indefinitely, other than a fairly minor Very *bad* idea. This breaks many applications sooner or later, and someone who's not involved in gtk will become really confused by that. Well, here we see the design of the first place: there is too much functionality in one library, which someday becomes obsolete, while the library at all won't. We have no clear interface borders. as Prof. Wirth already said years over years ago: make it as simple as possible. If we had some more libraries - devided by *functionality*, then if some functionality (ie. some widget) becomes obsolete, we simply dont maintain this lib anylonger. If these libs have their own packages, it gets even easier: there is no question about obsolete stuff - the packages just exist, and if someone wants to work on them, he just does. snip With this in mind, we have to start asking the question of what we think the version numbers for GTK actually mean. That's the point. AFAIK there's a wide consensous in the OSS world that jumps between major numbers break at least binary compatibility, even on source level. So on the other hand binary compatible releases should not do a major release jump. Major jumps should do something fundamentally new. We're not in the commercial world, where people rape version numbering for marketing. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Philippe De Swert [EMAIL PROTECTED] schrieb: snip This is an issue for embedded systems using gtk (like for example GPE). Maybe a --disable-deprecated flag could do the trick? Nice idea. BUT: it as to be absolutely clear what exactly this means. Just calling it obsolete is not enough. So better modelize several things considered obsolete as features, which can be switched by --enable-foo / --disable-foo. Of course the documentation and ./configure help should clearly state which features are obsolete. AND: before adding new features or functionality, think *really carefully* whether the new stuff *must* be in gtk and cannot reside in its own new library. snip (the last thing could also be done with a deprecated macro that warns during compilation as done in the Linux kernel) And if a certain feature is disabled, there should be macros for the disabled functions breaking the build with an appropriate error message (ie. function foo() reqiures obsolete feature foobar, which is currently disabled). So someone who's not an gtk developer can easily see what's happening. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Florian Boor [EMAIL PROTECTED] schrieb: snip I'm working on the GPE project (http://gpe.handhelds.org, a software framework for mobile devices like PDAs) which is using GTK. Moving more features into GTK will make application development easier for us in a software environment of limited resources. I'm a little bit confused that you - as an embedded developer - a in favour of bloating up gtk ... snip The only problem i can imagine is that GTK might become heavily bloated and unusable on devices with limited resources. That's the major problem - not just for embedded devices. And therefore it simply shouln't be done. Separate things belong into separate libraries - evryone who needs a certain functionality is free to import the right libs for that. There's no need to put a whole operating system into one library. snip So please keep in mind that there are other projects than Gnome around using GTK which might run into trouble with the total size and memory usage of GTK and the fact that some things might be to heavy to belong to GTK. You're absolutely right. If gtk wants to become something like Qt, and only interesting for GNOME, just go on. Today, it's still an universal widget toolkit, not limited to GNOME, and I don't see what's bad about it. Gtk is already too fat, and the tendencies are not really good. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Fri, 2005-08-26 at 07:53 +0200, Murray Cumming wrote: But being as part of the official library pack makes them be official, and avoid people using different solutions for the same problem. That's the idea of being in the GNOME Development Platform. I don't see how putting the whole platform in one tarball makes it much more official. That's just an invitation to JDKesque quality problems due to lack of modularity - meaning: - you have to wait to release a bugfix because of a bug in another part of the library that surfaced in the meantime, and - you force people to suffer bugs in another part of the library when releasing a bugfix for one part of the library. Its a fine line, but I can't see how network connections don't fit in as an acceptable low level operation when we have the following in glib: 1) lexical scanner 2) xml subset parser 3) IO Channels Even if not in glib we should be creating an official solution that hooks nicely in to the mainloop rather than neon/curl/soup. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Wed, Sep 14, 2005 at 12:02:46PM -0400, JP Rosevear wrote: Its a fine line, but I can't see how network connections don't fit in as an acceptable low level operation when we have the following in glib: 1) lexical scanner 2) xml subset parser 3) IO Channels Even if not in glib we should be creating an official solution that hooks nicely in to the mainloop rather than neon/curl/soup. While adding network libraries to GLib/GNetwork, I feel that integrated, high-level service discovery and publishing objects, ala GServiceDiscovery and $OBJECTNOTYETWRITTEN are good candidates for the stack. While they are currently dependant on Avahi, the idea is to prevent them from unnessecarily exposing Avahi implementation details so that they could be use opaquely with other mDNS/DNS-SD implementations (eg. Apple's). --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
JP Rosevear writes: Even if not in glib we should be creating an official solution that hooks nicely in to the mainloop rather than neon/curl/soup. There is also linc2 (in ORBit2) and gnet. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Mon, 2005-08-22 at 12:23 -0400, Jonathan Blandford wrote: Rodrigo Moya [EMAIL PROTECTED] writes: what about libsoup/network library? Wouldn't it also make sense to move it to a libgnet in glib? I don't know of any plans for this. I don't think networking makes a whole lot of sense in glib, and these libraries being separate is less harmful than the other libraries. Except that having them separate makes it more likely for an app developer to use the underlying system APIs which makes their app less portable. If we put this in glib, we tell the ISVs to use this API which will make their app more portable. Chris ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
I am entering into the discussion thread without reading any other email than this one, but... as for XML we should not create the wheel again. That leads to libxml2 or expat. In my case, I prefer libxml2. Being part of w3c development maybe helps me choosing it. Well, having work with expat a long time ago when it was slower than libxml2 might help my decision as well. Well, just to help in the discussion :) Alberto Olexiy Avramchenko wrote: What about XML support ? Now we have: - basic XML subset in GLib - libxml2 - expat Moving all XML features to GLib doesn't look good, neither looks good having three separate libraries with the same functionality. Olexiy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
Hello all, I don't really see much reason ever to break ABI for the forseeable future. There's essentially nothing stopping us from simply leaving deprecated functions in there indefinitely, other than a fairly minor memory footprint increase which will never be paged in anyway. This is an issue for embedded systems using gtk (like for example GPE). Maybe a --disable-deprecated flag could do the trick? This will also enable other people developing with gtk to test their code before the ABI gets changed (I would not say broken). (the last thing could also be done with a deprecated macro that warns during compilation as done in the Linux kernel) And it would reduce the memory footprint on disk / flash / you-name-it. Ram is indeed less of a problem. Also looking at the number of functions I see marked as deprecated this is could be more than a minor increase. Regards, Philippe | Philippe De Swert | | Stag developer http://stag.mind.be/ | Emdebian developer: http://www.emdebian.org | | Please do not send me documents in a closed | format.(*.doc,*.xls,*.ppt) | Use the open alternatives. (*.pdf,*.ps,*.html,*.txt) | http://www.gnu.org/philosophy/no-word-attachments.html --- A free anti-spam and anti-virus filter on all Scarlet mailboxes More info on http://www.scarlet.be/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
Jonathan Blandford wrote: The primary goal of Project Ridley is to cut down on the number of problem libraries that are part of the GNOME platform. We propose to do this by moving functionality into GTK+, wherever it makes sense. What about EggRegex? -- Marco Barisione ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Mon, 2005-08-22 at 13:37 +0200, Rodrigo Moya wrote: what about libsoup/network library? Wouldn't it also make sense to move it to a libgnet in glib? I'm also for this, right now we are using multiple networking libraries and we fix the same bugs in multiple places. I think its odd as a platform we have no official way to great an http/network connection (yes libsoup is in the platform for evolution, but for instance gnome-vfs uses neon). -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
JP Rosevear [EMAIL PROTECTED] writes: I'm also for this, right now we are using multiple networking libraries and we fix the same bugs in multiple places. I think its odd as a platform we have no official way to great an http/network connection (yes libsoup is in the platform for evolution, but for instance gnome-vfs uses neon). It sounds great to have a networking library on our platform, but I am pretty confident that it shouldn't be part of glib or GTK+. Project Ridley is primarily about getting widgets back into the widget library, and making that library comprehensive. We can start a larger conversation about what the platform needs, and we're probably overdue for that. Thanks, -Jonathan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Wed, 2005-08-24 at 07:44 -0400, JP Rosevear wrote: On Mon, 2005-08-22 at 13:37 +0200, Rodrigo Moya wrote: what about libsoup/network library? Wouldn't it also make sense to move it to a libgnet in glib? I'm also for this, right now we are using multiple networking libraries and we fix the same bugs in multiple places. I think its odd as a platform we have no official way to great an http/network connection (yes libsoup is in the platform for evolution, but for instance gnome-vfs uses neon). Shouldn't http be in a unified library with other IO? (i.e. we'd want to look at the whole of gnome-vfs functionality perhaps) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
What about XML support ? Now we have: - basic XML subset in GLib - libxml2 - expat Moving all XML features to GLib doesn't look good, neither looks good having three separate libraries with the same functionality. Olexiy ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
Hello all, Jonathan Blandford wrote: The primary goal of Project Ridley is to cut down on the number of problem libraries that are part of the GNOME platform. We propose to do this by moving functionality into GTK+, wherever it makes sense. These libraries are generally small, undermaintained, and buggy. They have an unclear purpose (such as libgnome and libgnomeui), are copied-and-pasted around (such as libegg) or would benefit by being in GTK+ (libgnomeprint and libgnomeprintui.) this sounds like a really good idea and is likely to improve the situation of a large pile of software. I'm working on the GPE project (http://gpe.handhelds.org, a software framework for mobile devices like PDAs) which is using GTK. Moving more features into GTK will make application development easier for us in a software environment of limited resources. The only problem i can imagine is that GTK might become heavily bloated and unusable on devices with limited resources. So please keep in mind that there are other projects than Gnome around using GTK which might run into trouble with the total size and memory usage of GTK and the fact that some things might be to heavy to belong to GTK. To improve the situation for GTK on all kind of small and embedded devices some more build-time configuration options would be a good idea to remove functionality not needed on a particular platform. I'd really like to see more GTK-based software for mobile devices like cellphones and PDAs :-) Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
Am Montag, den 22.08.2005, 13:37 +0200 schrieb Rodrigo Moya: there is no reason to force us to do GNOME 3.0, but since many GNOME libraries will be disappearing with Ridley, we might want to call it 3.0, so that we don't have to maintain the old libraries around. Also, as we deprecate most stuff in libgnome/libgnomeui, we might want to think about the role of those libraries. I would suggest we use them for having high-level desktop oriented things in one place, like, for instance, talking to the panel/window manager/file manager/etc, notifications, services (libgnomeservice), libegg, icon theme. Thus, as we reduce the number of generic libraries by getting them into GTK+, we also reduce the number of specific, high-level libraries, by putting them into libgnome/libgnomeui. Since we'll always need these high-level libraries, instead of killing libgnome* (http://live.gnome.org/LibgnomeMustDie), it might be much better to change its purpose. All those would be enough to justify a GNOME 3.0 :) Does this also mean that we can get rid of deprecated API like GtkTree, GtkCList or GtkFileSelector? -- Christian Neumair [EMAIL PROTECTED] 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: Announcing: Project Ridley
Gustavo J. A. M. Carneiro wrote: On Mon, 2005-08-22 at 16:10 +0200, Christian Neumair wrote: Am Montag, den 22.08.2005, 13:37 +0200 schrieb Rodrigo Moya: there is no reason to force us to do GNOME 3.0, but since many GNOME libraries will be disappearing with Ridley, we might want to call it 3.0, so that we don't have to maintain the old libraries around. Also, as we deprecate most stuff in libgnome/libgnomeui, we might want to think about the role of those libraries. I would suggest we use them for having high-level desktop oriented things in one place, like, for instance, talking to the panel/window manager/file manager/etc, notifications, services (libgnomeservice), libegg, icon theme. Thus, as we reduce the number of generic libraries by getting them into GTK+, we also reduce the number of specific, high-level libraries, by putting them into libgnome/libgnomeui. Since we'll always need these high-level libraries, instead of killing libgnome* (http://live.gnome.org/LibgnomeMustDie), it might be much better to change its purpose. All those would be enough to justify a GNOME 3.0 :) Does this also mean that we can get rid of deprecated API like GtkTree, GtkCList or GtkFileSelector? Maybe just moving deprecated widgets to a separate library, like libgtk2.0-compat.la, would be a better solution? We'd get well maintained applications to avoid linking to this library, while at the same time keeping it around for those apps that just need it and whose authors are stuburn enough to not want to update. So let those apps depend on GTK+-2.x, like many depend on 1.2 now. Moving widgets to separate library will require some changes in related apps anyway. Olexiy ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Mon, 2005-08-22 at 17:43 +0300, Olexiy Avramchenko wrote: Maybe just moving deprecated widgets to a separate library, like libgtk2.0-compat.la, would be a better solution? We'd get well maintained applications to avoid linking to this library, while at the same time keeping it around for those apps that just need it and whose authors are stuburn enough to not want to update. So let those apps depend on GTK+-2.x, like many depend on 1.2 now. Moving widgets to separate library will require some changes in related apps anyway. This gets proposed repeatedly, Unfortunately, it does not offer significant benefits that would justify the costs of doing this. Splitting GTK+ into multiple shared libraries increases the cost of symbol resolution. It does not reduce the memory consumption significantly, since all the deprecated functions are unlikely to be paged in anyway. It does complicate the build considerably. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Sun, 2005-08-21 at 12:31 -0400, Havoc Pennington wrote: Another thing I would be interested as an extension to the above is specialisation (or rather, restriction) of containers to particular GTypes. If for example, we had a call such as GType g_type_specialise(GType type, ...) I think at some point you should accept you're coding in C ;-) if we just reimplement Java/C#/Python poorly, it's not that useful ... Ahem. Going offtopic a bit, but we have an implementation of this in the DBus GLib bindings actually: http://cvs.freedesktop.org/dbus/dbus/glib/dbus-gtype-specialized.h?view=log http://cvs.freedesktop.org/dbus/dbus/glib/dbus-gtype-specialized.c?view=log There was discussion on gtk-devel-list about it, I don't think there were any fundamental objections. I just need to find the time to adddress the concerns raised and create a patch. 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[2]: Announcing: Project Ridley
Gustavo J. A. M. Carneiro wrote: On Mon, 2005-08-22 at 16:10 +0200, Christian Neumair wrote: Am Montag, den 22.08.2005, 13:37 +0200 schrieb Rodrigo Moya: there is no reason to force us to do GNOME 3.0, but since many GNOME libraries will be disappearing with Ridley, we might want to call it 3.0, so that we don't have to maintain the old libraries around. Also, as we deprecate most stuff in libgnome/libgnomeui, we might want to think about the role of those libraries. I would suggest we use them for having high-level desktop oriented things in one place, like, for instance, talking to the panel/window manager/file manager/etc, notifications, services (libgnomeservice), libegg, icon theme. Thus, as we reduce the number of generic libraries by getting them into GTK+, we also reduce the number of specific, high-level libraries, by putting them into libgnome/libgnomeui. Since we'll always need these high-level libraries, instead of killing libgnome* (http://live.gnome.org/LibgnomeMustDie), it might be much better to change its purpose. All those would be enough to justify a GNOME 3.0 :) Does this also mean that we can get rid of deprecated API like GtkTree, GtkCList or GtkFileSelector? Maybe just moving deprecated widgets to a separate library, like libgtk2.0-compat.la, would be a better solution? We'd get well maintained applications to avoid linking to this library, while at the same time keeping it around for those apps that just need it and whose authors are stuburn enough to not want to update. So let those apps depend on GTK+-2.x, like many depend on 1.2 now. Moving widgets to separate library will require some changes in related apps anyway. Olexiy i suppose will be better - to make Ridley Project separated from deprecated libraries (GTK+-2.x,1.2 ...), so old apps will use deprecated libraries, new applications - new libraries. if apps-developer want to porting apps from old libraries to new - he spend some time anyhow. This is a backward compatibility without backward compatibility. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
Jeff Waugh [EMAIL PROTECTED] writes: Probably worth putting some of the ABI/API answers on the ProjectRidley page, just so it's absolutely clear. I would do it, but I don't really want to miscommunicate the goals. :-) Good point. Done. Thanks, -Jonathan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
Seems great goals ! Have some questions: 1) Is GTK+-3.0 scheduled ? Or is it a long long time work which will be released when it's ready. Will be a GTK+-2.10 version ? Or 3.0 is the next version ? 2) If GTK+-3.0 is released, will it lead automatically to gnome-3.0 ? So is it the right moment (not now, but when GTK3 will be released) to do API/ABI breakage in all gnome apps/libs ? 3) Is Ridley a already well defined (and planned) project ? Or is it waiting for comments to add others API modifications ? 4) For example : is what i'm saying in bug 43311 [1] in the spirit/Goals of ridley ? Thanks, Claessens Xavier. 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: Announcing: Project Ridley
Hi Xavier, I can't answer all the questions. Just one, in fact :-) Le dimanche 21 août 2005 à 14:00 +0200, Claessens Xavier a écrit : 2) If GTK+-3.0 is released, will it lead automatically to gnome-3.0 ? So is it the right moment (not now, but when GTK3 will be released) to do API/ABI breakage in all gnome apps/libs ? There's no reason to think that GTK+ 3.0 will immediately lead to GNOME 3.0. And I don't think the most important thing is to break the API/ABI: it's more about deprecating some API in some of the GNOME libraries. We have this wiki page about GNOME 3.0: http://live.gnome.org/ThreePointZero Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Sun, 2005-08-21 at 14:00 +0200, Claessens Xavier wrote: Seems great goals ! Have some questions: 1) Is GTK+-3.0 scheduled ? Or is it a long long time work which will be released when it's ready. Will be a GTK+-2.10 version ? Or 3.0 is the next version ? 2) If GTK+-3.0 is released, will it lead automatically to gnome-3.0 ? So is it the right moment (not now, but when GTK3 will be released) to do API/ABI breakage in all gnome apps/libs ? No, GTK+ 3.0 is no scheduled, and there is no plan to break API or ABI, unless you count deprecating chunks of platform API as breaking API. I'm pretty sure that the tasks listed on the Project Ridley page are enough for two or more major releases. If we do a GTK+ 3.0 after completing Project Ridley, it would be essentially a marketing version jump to emphasize the consolidated platform message. 3) Is Ridley a already well defined (and planned) project ? Or is it waiting for comments to add others API modifications ? The scope of the project as a platform consolidation project is well-defined, and we are less interested in this API would be nice to have comments than in this API from the existing platform library X would make sense in GTK+, and I'm interested in working on that kind of coments. Matthias ___ gtk-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
Oki thanks, its more clear for me now :-) signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Sun, 2005-08-21 at 14:05 +0100, Roger Leigh wrote: One thing I (as an end developer) would like is for libgobject to be merged with libglib That's off the table since it would break ABI ... I currently find the split to make some tasks impossible (for example, I recently wrote a GUnixSignalSource to inject UNIX signals into the mainloop, but without it being a GObject, I couldn't implement it completely). You should have been able to link to libgobject and write it as a GObject though ? Something else I would also like (but can implement separately initially) is a GObject-based container library which implements STL-style container and iterator interfaces. This would allow the current list/hash/vector etc. types to be implemented as GObjects with a standardised iterator interface, allowing the use of generic algorithms etc. It would probably be hopelessly inefficient, since GObject is a bit heavier than a base object in Java or Python ... Another thing I would be interested as an extension to the above is specialisation (or rather, restriction) of containers to particular GTypes. If for example, we had a call such as GType g_type_specialise(GType type, ...) I think at some point you should accept you're coding in C ;-) if we just reimplement Java/C#/Python poorly, it's not that useful ... Havoc ___ gtk-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
