Re: About GTK+ 3.0 and deprecated things
The 1.x - 2.0 change was painful for everyone who had an app that needed porting, however I find it pretty irrelevant in comparison to 2.x - 3.0. Well, if no libgtk-compat is planned, it will be about as painful for users of the deprecated and removed widgets/functions. Isn't it a little bit exaggerated? The GTK+ team wants to remove official support for deprecated things; the larger part of it (from probably a lot of application porting perspectives, and apparently yours) is probably GtkCList and GtkCTree: they were marked deprecated more than 6 years, when GTK+ 2.0 was released (and GtkItemFactory is deprecated in GTK+ 2.4, released more than 4 years ago). If I use wikipedia to get a definition for deprecation, I can read: the term deprecation is applied to software features that are superseded and should be avoided. Although deprecated features remain in the current version, their use may raise warning messages recommending alternate practices, and deprecation may indicate that the feature will be removed in the future. I sympathize with the actual problems you're having with your application still using GtkCTree etc all over the place, and I do understand that it's pretty frustrating to have to do useless work of porting (though, GtkTreeView is much more powerful and has a better and more robust look so your app will look better and work on it in the future will then be easier). But really, I think that the GTK+ team, who writes a great library for us application developers, should be able to move forward; and moving forward also means that after a reasonable amount of time, deprecated stuff is removed - and, really, do you really think that more than 6 years cannot be considered a reasonable amount of time? -- Guillaume Cottenceau - http://zarb.org/~gc/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Morten Welinder wrote: It is just not cool to use Gtk. I think that pretty much hits it on the nail. Some people want a cool project to work on. By all means, go ahead! Fork gtk+ to something new, cool, fancy. But leave existing gtk+ bugzilla and svn module alone. In the end it comes down to which goal is deemed most important: Keep ISVs and spare-time-investors happy or motivate a new generation of hackers to pick up, the coolness that could be, Gtk. Do you really think saying Fuck you! to your application developers every 3-4 years is going to attract an enthusiastic crowd? Yes I do and yes I am an application developer. Surely it is more logical to break _few_ things 3-4 years than _many_ things every 6-10 years? Consider the huge development burden (which never comes at an appropriate time let's face it) once in 6-10 years compared to a smaller one which is easier to schedule every 3-4 years. Plus, let's not forget, we are not saying we will definitely break API/ABI every 3-4 years, we are saying we _may_. It is not guaranteed, it is just a way to try and see some sort of acceptance by the community that they are happy to see it break so often (if it needs to at all). -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
A GTK+ fork is long overdue. Was: About GTK+ 3.0 and deprecated things
First, I am not a GTK+ contributor and so it isn't my intention to try to force my will upon people that actually do great work on it. But since I may be looking into using GTK+ for a new scientific simulation application I though I'd pitch in. I had actually written a fairly lengthy piece on why I was against a 'Deprecation 3.0' when I realised that it really doesn't matter. What matters is that the two prevalent agendas of 'new, fun and exciting' and 'stable and productive' are actually quite mutually exclusive when it comes to a toolkit library such as GTK+. Thus this discussion could actually go on forever with no agreement whatsoever. ISVs that care about 'stable and productive' are going to be upset about moving to a new GTK+ with no new features. Keeping cruft on the other hand, and forcing API/ABI stability on the other hand, is going to make it much harder to attract people to help with the fun and exciting bit and it is going to upset people that want to create new things requiring API changes. Since it is almost impossible to please both camps with one path, the longer the community argues and drags its feet, the bigger the chance of a fork is, and the later this fork happens, the more resentment it is going to cause. There is no need for bad vibes, there is room for both luddites and freaks. So, why not start a friendly fork right now, it is well overdue. I suggest people that want to create exciting stuff just do it without further politics and discussion. Just create a new GTK+ 'next generation' branch and knock yourself out, you can even call it '3.x', if the understanding is that the next stable GTK+ will be 4.x. Let this be a blessed fork, with the understanding that exciting stuff is carried out in the fork. This doesn't even mean they will end up being completely separate. There is every chance some people may be working on both branches, i.e the 2.x one for their dayjob and the development one for fun. Some people may even start porting their apps straight away because they want cool and fun new features. Finally, when the new branch is interesting enough, start working towards getting this blessed as the new and official GTK+ (3.0, 4.0, whatever). If the API changes are too big for people to swallow, a libgtk-legacy to help porting sounds like a good idea. In the end, the only thing that matters is code (and love). -- Gaute Lindkvist ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Hi, Because the ABI is incompatible. Apps will need to be recompiled against the new version. Also, it is not API compatible with latest GTK+ without the flags. Cheers, Micke 17 jul 2008 kl. 05.03 skrev Paul Davis: On Thu, 2008-07-17 at 04:11 +0200, Sven Herzberg wrote: Paul, just in case this wasn't made clear enough already; the GTK+ team want to deploy a GTK+3 that will be API-compatible to the latest GTK +2 including all deprecation flags that are there (disable deprecated, multihead safe, single header include, etc.). if its API compatible, why a change in major version numbers? ___ 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: About GTK+ 3.0 and deprecated things
On Thu, Jul 17, 2008 at 6:51 AM, Kalle Vahlman [EMAIL PROTECTED] wrote: I wish people would stop fighting against the code cleanup release, unless they really want to switch to an alternative widget library. GTK+ isn't seeing the love it needs, and the strict API/ABI policy of GTK+ 2.x mixed with leaky public interfaces is seen (by the people doing the work) as one of the biggest problems why that is. If you prevent fixing that with all this stop-energy, it's not going to take long for new applications start choosing something less dead as their widget set of choice. So please let the code be revived _now_ when there's a chance it's not going to be just undead after the operation and direct the energy to implementing the canvas, css theming and animations and whatever. The good news is that you don't need to wait for 3.x, you can start the work already! The new API and its policy is already known and in SVN if I'm not mistaken, so go and hack away! The problem is this code cleanup release breaks everyone's applications for no reason. No one has shown a case where the current situation makes a fix impossible and no one has proven any interesting new features (other than whole new widgets, which we can do now) can be added to 'gtk+ 3.0' without breaking API/ABI. We're going to get terrible backlash from a 3.0 that has zero new features and I suspect any of the promised shiny bits will end up having to wait until 4.0 anyway. In the end all we get is the ability to drop some old widgets no one spends time on anyway. -- Travis Watkins http://www.realistanew.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Am Donnerstag, den 17.07.2008, 06:59 -0500 schrieb Travis Watkins: On Thu, Jul 17, 2008 at 6:51 AM, Kalle Vahlman [EMAIL PROTECTED] wrote: The problem is this code cleanup release breaks everyone's applications for no reason. This is wrong for 2 reasons: 1. It does only breaks apps that don't compile with disable-deprecated or enable-broken; that's far from everyone's 2. There are reasons, they have been mentioned quite a few times (code cleanup, more possibilities for refactoring, etc.) No one has shown a case where the current situation makes a fix impossible and no one has proven any interesting new features (other than whole new widgets, which we can do now) can be added to 'gtk+ 3.0' without breaking API/ABI. We're going to get terrible backlash from a 3.0 that has zero new features and I suspect any of the promised shiny bits will end up having to wait until 4.0 anyway. Wring, just read Kris' email, he's mentioning very concrete development ideas that are not possible without breaking the current API, but that would be possible if we had properly sealed from the beginning. In the end all we get is the ability to drop some old widgets no one spends time on anyway. Isn't that a good thing, too? Dropping unmaintained stuff so others won't use it and might be disappointed because of the bad state of it? Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Thu, Jul 17, 2008 at 3:59 PM, Morten Welinder [EMAIL PROTECTED] wrote: It is just not cool to use Gtk. I think that pretty much hits it on the nail. Some people want a cool project to work on. By all means, go ahead! Fork gtk+ to something new, cool, fancy. But leave existing gtk+ bugzilla and svn module alone. This is exactly what they are doing, that's why they call it GTK+ 3.0, or 2.99.0, or whatever. You are free to keep using and maintaining the 2.x series for as long as you need. Now, if you'd like *others* to spend *their* time doing what *you* would like them to do, well, that's different. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Thu, 2008-07-17 at 16:02 +0100, Xan wrote: This is exactly what they are doing, that's why they call it GTK+ 3.0, or 2.99.0, or whatever. You are free to keep using and maintaining the 2.x series for as long as you need. Now, if you'd like *others* to spend *their* time doing what *you* would like them to do, well, that's different. i think the problem is midway between these two. Developers using GTK+ would like developers of GTK+ to do the new, good stuff that one or other or both groups are fired up about. but they'd like it done in a way that doesn't negatively affect them. so the developers of GTK+ have said we can't do that without dealing the public/private issues in the current API, and so we have G_SEAL. this provides a transitioning bridge from things-that-should-never- have-been-public-but-were to the new world of only-public-things-are actually-public. this is fair enough. i think the problem is one of perception. its not obvious to most developers using GTK+ how the public/private stuff really impacts work on the things they'd like to see addressed in GTK+. to many of us, its not clear why its necessary to move to 3.0 to get substantive stuff done. its not that we know we're right, its that we just don't get the justification. a few more specific examples would probably help to clear the air of this question. kris gave us one slightly hand-wavy one. can anybody offer some more? as far as deprecated stuff goes, i have to confess that i am in total agreement with its (pre-announced) removal. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libgtk3deprecated (Re: About GTK+ 3.0 and deprecated things)
On Thu, 17 Jul 2008, Sven Herzberg wrote: Hi, Am Donnerstag, den 17.07.2008, 20:18 +0200 schrieb Tim Janik: On Thu, 17 Jul 2008, Martin Meyer wrote: 2) Is it entirely possible from a gtk perspective to have all that code detached from gtk-core and placed in a different library? Are there any deprecated things that this would *not* work for? Maybe we can detach as many as possible and leave the rest in place for now. Complete deprecated widgets should be fairly easy to separarte, single deprecated functions that some components may have can be hard to impossible to move when the implementation requires access to internals. But this could be worked around with a strange compile setup, right? With something like this: ~/sources/gtk+ ~/sources/gtk-deprecated and gcc -I$(top_srcdir)/../gtk+/gtk to access potential gtkwidgetpriv.h, right? Would mean recompile with every source change to gtk+ but if some (many?) people depend on this, I think they can easily distribute the burden of maintaining a parallel version. There is no point in having libgtk3deprecated access gtk+ internals and not go through public interfaces only. If we did that, we'd simply preserve the maintenance burden on Gtk+ internal definitions. We really want to get rid of a bunch of stuff, be free to refactor structures and internal methods to implement new things cleanly. If libgtk3deprecated kept acessing and relying on internals it'd either constantly break or hinder us on doing reorganisations. Also, this'd tie release cycles and maintenance resources of libgtk3deprecated closely to Gtk+ again. The main point in seperating deprecated code is to load off the core team though, so application developers or distributors that still have an interest in deprecated components can take over its maintenance as long as that's necessary. A closing word on the library name, since this'd be an ABI break, such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should probably advertise that it ships deprecated Gtk+ stuff. So the best name is probably libgtk3deprecated for this (there could possibly be a libgtk4deprecated as well at some point). Well, so GTK+ 4.0 could be accompanied by these two: libgtk3deprecated-4.0.so libgtk4deprecated-3.0.so Right? I'd guess that if deprecated 2.x components that landed in libgtk3deprecated are still required when a libgtk4deprecated is released, they could possibly need some porting and simply be included as real parts of libgtk4deprecated. This is highly speculative though and can be considered when we have the Gtk+-4.0 discussion. We're not quite there yet ;) Regards, Sven --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
About GTK+ 3.0 and deprecated things
Hello, I've read the PDF at http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf I am wondering what the options will be for users of the GTK lib, that still use deprecated widgets? In the project I work for, we do have a lot of them: [claws-mail/src]$ grep -r GtkItemFactory *|wc -l 163 [claws-mail/src]$ grep -r GtkTooltips *|wc -l 61 [claws-mail/src]$ grep -r GtkCTree *|wc -l 670 [claws-mail/src]$ grep -r GtkCList *|wc -l 198 They're used all over the place and in very central places of the code. Rewriting them to use newer, non-deprecated widgets would require a scary number of man-hours of un-fun work, introduce new bugs, and would take all of our (we're three core developers) energy to re-do work we've already done. We went through this when migrating from GTK+ 1 to GTK+ 2 already. We don't want to do it again. What do you plan on doing for users of your toolkit who don't have time to rewrite things every four years? -- Colin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Am Mittwoch, den 16.07.2008, 09:16 +0200 schrieb Colin Leroy: What do you plan on doing for users of your toolkit who don't have time to rewrite things every four years? One obvious option would be to stay with GTK2 forever, and to take over bug fixing for it. Another **rough** idea I always had in mind is moving all that deprecated code into some libgtk-compat library: Obviously this approach would not work for structure fields, but it should be trivial for entirely deprecated classes. This approach also should be support deprecated functions. Obviously those deprecated functions would suffer from the fact, that they cannot access internal data structures anymore. So for functions that cannot be easily be ported maybe just some stub yielding linker warnings would be created in that compat library. Filling that stub would be the task of people willing to use that deprecated function (instead of porting their code). Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: 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: About GTK+ 3.0 and deprecated things
On Wed, 2008-07-16 at 09:16 +0200, Colin Leroy wrote: Hello, I've read the PDF at http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf I am wondering what the options will be for users of the GTK lib, that still use deprecated widgets? In the project I work for, we do have a lot of them: [claws-mail/src]$ grep -r GtkItemFactory *|wc -l 163 [claws-mail/src]$ grep -r GtkTooltips *|wc -l 61 [claws-mail/src]$ grep -r GtkCTree *|wc -l 670 [claws-mail/src]$ grep -r GtkCList *|wc -l 198 snip We went through this when migrating from GTK+ 1 to GTK+ 2 already. We don't want to do it again. IMO, if you're still using GtkCTree and GtkCList, which were deprecated when GTK+ 2.0 was released 6 years ago, you're asking for trouble. The tooltips should be easy to port, the tree and list widgets less so, which is why it should have started quite some time ago... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote: Hi, IMO, if you're still using GtkCTree and GtkCList, which were deprecated when GTK+ 2.0 was released 6 years ago, you're asking for trouble. Well, they do work for us. When GTK+ 2.0 was released six years ago, we were already too busy with the rest of the rewriting code-that-worked to do it. Two years and nine days, exactly, between the first commit to the GTK2 branch and the first GTK2 release after 497 commits. And we never came to replace the GtkCtrees because a) they work and b) we didn't have the time/motivation. The tooltips should be easy to port, the tree and list widgets less so, which is why it should have started quite some time ago... and the GtkItemFactory are huge to port too. And probably there is more; I've just looked at the first batch of compilation errors using GTK_DISABLE_DEPRECATED. As Mathias said, a libgtk-legacy (or -compat or whatever) seems a good idea and (in my application developer's opinion) least that can be done for the users of the GTK+ lib. There are 2017 applications on http://gnomefiles.org/ ; how many of these projects have the available manpower to rewrite their code? How many of these are projects are run by enthusiasts on their free time ? -- Colin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Colin Leroy skrev: On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote: Hi, Hi, IMO, if you're still using GtkCTree and GtkCList, which were deprecated when GTK+ 2.0 was released 6 years ago, you're asking for trouble. Well, they do work for us. When GTK+ 2.0 was released six years ago, we were already too busy with the rest of the rewriting code-that-worked to do it. Two years and nine days, exactly, between the first commit to the GTK2 branch and the first GTK2 release after 497 commits. And we never came to replace the GtkCtrees because a) they work and b) we didn't have the time/motivation. The tooltips should be easy to port, the tree and list widgets less so, which is why it should have started quite some time ago... and the GtkItemFactory are huge to port too. And probably there is more; I've just looked at the first batch of compilation errors using GTK_DISABLE_DEPRECATED. As Mathias said, a libgtk-legacy (or -compat or whatever) seems a good idea and (in my application developer's opinion) least that can be done for the users of the GTK+ lib. Having a libgtk-compat library sounds like a good idea. We discussed it during Guadec a year or two ago but the discussion was then about whether it would be possible to move the deprecated calls into a separate library without breaking ABI which from my understanding it isn't on Linux. It sure would lessen the burden for applications still using deprecated widgets (which is the hard part of the ABI break). Cheers, Mikael -- Mikael Hallendal Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 16 Jul 2008 12:18:24 +0200, Mikael Hallendal wrote: Hi, It sure would lessen the burden for applications still using deprecated widgets (which is the hard part of the ABI break). Well, the hardest part in my opinion, for free software at least, is the API break :-) There's something unclear from the State of the union slides I've read (I wasn't at GUADEC...); What will happen to GTK+2 when GTK+3 is out ? If it's continuing its life as a bugfix-only branch, the problem from my (app developer's) point of view is not as important... -- Colin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 2008-07-16 at 11:20 +0200, Colin Leroy wrote: On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote: Hi, IMO, if you're still using GtkCTree and GtkCList, which were deprecated when GTK+ 2.0 was released 6 years ago, you're asking for trouble. Well, they do work for us. When GTK+ 2.0 was released six years ago, we were already too busy with the rest of the rewriting code-that-worked to do it. Two years and nine days, exactly, between the first commit to the GTK2 branch and the first GTK2 release after 497 commits. And we never came to replace the GtkCtrees because a) they work and b) we didn't have the time/motivation. Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile... (e.g., I remember doing that for gftp, not a trivial app.) Porting to GtkCList and GtkCTree was was the main thing that took significant work. So, I'm not really sure what you were doing for 497 commits... - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 16 Jul 2008 09:25:43 -0400, Owen Taylor wrote: Hi, Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile... (e.g., I remember doing that for gftp, not a trivial app.) Probably not trivial, but 30k LOCs is much less than Claws ;) Porting to GtkCList and GtkCTree was was the main thing that took significant work. So, I'm not really sure what you were doing for 497 commits... We had work on: switch to GtkTextView, font selection, charset-related things, GtkCombo(Box(Entry)), pixmap stuff, file selector, accelerators, changed signal handlers... These 500 commits were not only porting work, there were also syncs with the gtk1 branch and bugfixes; still it took us 2 years to be confident enough to release our first GTK2 version. Anyway, I didn't come here to complain about the past, but rather to try and avoid repeating it :) -- Colin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile... (e.g., I remember doing that for gftp, not a trivial app.) That sounds like a serious case of selective memory. Or maybe gftp has the ui from hello, world. Here's a partial list of suffering that we went through. Let's see... * All widgets has to be reworked and audited. There was new reference handling and double destroy calls added to the trouble. * All glade files needed to be redone, or at the very least subjected to heavy post-translation surgery with Emacs and Perl. * All code needed to be audited for UTF-8. * All font handling had to be reworked. Drawing changed too. * Whenever something crashed, leaked, or otherwise simply did not work, we had to audit not only our own code, but glib, pango, and gtk+ too. There were piles and piles of bugs in the new code. * We had to struggle with sluggishness of the resulting gtk2 application. The above is just what I can remember off the bat and is *before* changing to use the new widgets of gtk2, some of which were only partial replacements of what they deprecated: the tree view, for example, was touted as right for all kinds of tables, but it has become clear that it cannot handle large ones. Gnumeric has about 34k lines dedicated to dialogs, not including code that implements the actions of those dialogs. Add to that 20k lines of widgets and another 20k lines of further gui code. That excludes code for graphs. You just do not audit that in a weekend or two. You want us to go through some variant of that every 3-4 years? That's insane! What, exactly, is it that is hard about maintaining 2.x that will not be hard for 3.x? I have seen nothing but unsubstantiated assertions about this. What I have observed is that sub-systems like GtkPrint get dumped in and abandoned right away. With bayesian mind that tells me that the maintenance situation will not be better for 3.x What really bothers me is that people go out of their way to break working code. Looking at svn logs tells me that the effort of keeping the old widgets and methods around is minimal. It's not just the old gtkclist -- the recently deprecated gtktooltips shows the same thing. The second unsubstantiated assertion is that the deprecated widgets cause a lot of maintenance work beyond the self-inflicted pain of deprecation. The data does not support that assertion. I would like to see all this gtk3 talk pushed 3-4 years out into the future. There are lots of things that need to be fixed and introducing new, buggy code elsewhere is not going to fix it. If that means the world will have to wait for animated, semi-transparent widgets, then that would be fine. No real work will get done of behalf of those features anyway. Morten Welinder PS: For whatever it's worth, GnuCash also took years to go gtk2. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Hi, Am Mittwoch, den 16.07.2008, 18:08 -0400 schrieb Paul Davis: On Wed, 2008-07-16 at 16:51 -0400, Morten Welinder wrote: i totally agree with those who are arguing against the current notion of what GTK3 should be. i haven't seen any evidence that any of the problems that our developers face with GTK are going to be easier to address after the proposals for 3.0 are complete, with the possible exception of themeing. it is suggested that once G_SEAL etc. is complete, it will become easier to fix the problems. i've mentioned our problems before ... once again, none of the people working on GTK have ever said to me oh, once 3.0 is done that will be much easier to fix. the closest might be kris' refusal to look at the treeview DnD situation in 2.X because he has a completely new implementation of the entire widget (family) waiting in the wings. does this need G_SEAL to make it work? Paul, just in case this wasn't made clear enough already; the GTK+ team want to deploy a GTK+3 that will be API-compatible to the latest GTK+2 including all deprecation flags that are there (disable deprecated, multihead safe, single header include, etc.). There are these simple things you can do to get your app easily 3.0 compatible: 1. make sure your application compiles with these flags 2. if you use deprecated/considered-broken widgets/classes, copy them into your project and change the namespace from gtk to your project's namespace. After that, everything should be fine. Plus I heard rumors about some refactoring tools being developed so we (app developers) can easily get our code compatible for 3.0. The reference counting pains and the GtkArgs removal etc. were a REAL pain (compared to the points above), also adding lots of new code. But with GTK+3, there are no evil changes like this queued. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, Jul 16, 2008 at 4:51 PM, Morten Welinder [EMAIL PROTECTED] wrote: [ lots of whining cut out] You want us to go through some variant of that every 3-4 years? That's insane! GTK2 is not going away any time soon. Enterprise distributions will have to keep it alive in maintenance mode for a long time to come (RHEL 5 is still shipping gtk 1.2). What, exactly, is it that is hard about maintaining 2.x that will not be hard for 3.x? I have seen nothing but unsubstantiated assertions about this. What I have observed is that sub-systems like GtkPrint get dumped in and abandoned right away. With bayesian mind that tells me that the maintenance situation will not be better for 3.x Nothing that is hard about maintaining 2.x will not be hard for 3.x. The argument that the proponents of the current 3.x agenda make is that the current state of the code makes it increasingly impossible to add new features. Regarding your GtkPrint comment, I have to point out that moving increasing amounts of the platform into GTK+ does not magically grow the GTK+ maintainership at the same rate. You could improve the situation by sending a patch every once in a while...you do seem to have enough time to do statistical analysis on the GTK+ svn logs, after all :-) Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Thu, 2008-07-17 at 04:11 +0200, Sven Herzberg wrote: Paul, just in case this wasn't made clear enough already; the GTK+ team want to deploy a GTK+3 that will be API-compatible to the latest GTK+2 including all deprecation flags that are there (disable deprecated, multihead safe, single header include, etc.). if its API compatible, why a change in major version numbers? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
On Wed, 2008-07-16 at 23:03 -0400, Paul Davis wrote: if its API compatible, why a change in major version numbers? As I understand it, because: a) they're removing all the deprecated stuff, and b) the API sill start changing after 3.0 in ways that won't be compatible with 3.0 All good. AfC Sydney 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
