Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Simon Budig <[EMAIL PROTECTED]> writes: > Ok, I think we had a lot of arguments now. Could we try to agree on the > following: > > 1) Currently Gimp CVS depends on Gtk+ CVS, because the improvements > made in Gtk+ CVS (over 1.3.6) are very important for the lead > developers. > > 2) When the first release of GTK+ with the fixed api appears > (aka 1.3.7) Gimp CVS will depend on the earliest possible > GTK+-Tarball. > > 3) When a bug in all GTK+-tarballs *massively* disturbs the GIMP > developers and this bug is fixed in CVS we could make an exception > to rule No. 2. However, this should be discussed on the Mailinglist. Yes, please. I don't understand why the discussion about depending on the CVS HEAD version of GTK+ came up in the first place. Of course we will try our best to be compatible with a GTK+ developers release. Noone will have to recompile his GTK+ each day just to take part in Gimp development. I wonder what made Kelly think this would be the case. It's probably bad experience with GTK+ ports back in the old days. GTK+ development as it happens now is a very strictly organized process and I'd say we can take the risk to trust Owen & Co. I do believe that after the port is finished (very soon now) it will be much easier to work with the GIMP code. Large parts of the core will not even be dependant on GTK+ and the clean separation between different parts of the core will make it easier for one developer to concentrate on hacking on just one of those parts. This alone should make it way easier for developers with limited time to participate. Salut, Sven PS: I would like to mention that we all have to work for a living and noone of us can spend 120 hours a week on GIMP development. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, "Adam D. Moss" <[EMAIL PROTECTED]> writes: > Michael Natterer wrote: > > > > Nick Lamb <[EMAIL PROTECTED]> writes: > > > NB I am not blind and I don't write code in Hebrew > > > > I respect your extraordinary tolerance regarding this, so please > > respect that the people actually working on a project tend to make the > > decisions. > > Uh, that's pretty harsh if I read it right. Nick is a seasoned > and consistant GIMP contributor. right, but the statement he made was unacceptable. I'm in no way a friend of political correctness, but I didn't believe my eyes when I read this sentence. Mitch probably overreacted here, but be assured that I wouldn't have found nicer words. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
"Adam D. Moss" <[EMAIL PROTECTED]> writes: > Michael Natterer wrote: > > > > Nick Lamb <[EMAIL PROTECTED]> writes: > > > NB I am not blind and I don't write code in Hebrew > > > > I respect your extraordinary tolerance regarding this, so please > > respect that the people actually working on a project tend to make the > > decisions. > > Uh, that's pretty harsh if I read it right. Nick is a seasoned > and consistant GIMP contributor. Yes, this was an overreaction and *slightly* too personal. My apologies for that. The statement about neither being blind nor coding in hebrew was just too beyond a serious discussion and hit me in a bad mood :) ciao, --Mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Kelly Martin ([EMAIL PROTECTED]) wrote: > On Fri, 27 Jul 2001 22:18:32 +0200, Lourens Veen <[EMAIL PROTECTED]> said: > >I may be misunderstanding, I'm not a project expert, but if the Gtk > >API is frozen, the only difference between the CVS HEAD branch and > >the latest developer release is bugfixes right? > > No, because the HEAD branch could contain preliminary attempts at > bugfixes that don't actually fix the bug or which introduce new bugs. > I expect things like that to appear (and subsequently disappear) from > time to time on the development head. In my experience, a bugfix will > appear on the head branch once the developer who found the bugfix has > verified that the code compiles with the fix and appears to fix the > bug, but before the bugfix has been thoroughly tested by other > developers. Ok, I think we had a lot of arguments now. Could we try to agree on the following: 1) Currently Gimp CVS depends on Gtk+ CVS, because the improvements made in Gtk+ CVS (over 1.3.6) are very important for the lead developers. 2) When the first release of GTK+ with the fixed api appears (aka 1.3.7) Gimp CVS will depend on the earliest possible GTK+-Tarball. 3) When a bug in all GTK+-tarballs *massively* disturbs the GIMP developers and this bug is fixed in CVS we could make an exception to rule No. 2. However, this should be discussed on the Mailinglist. Personally I think it would have been nice, when the port to the new api had been happened after the release of GTK+ 1.3.7. However, I don't think, reverting the port now is necessary. Maybe we could ask the GTK+-Team for the 1.3.7 - release? I am a little bit astonished that this has not yet happened. And please stop getting personal. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Fri, 27 Jul 2001 22:18:32 +0200, Lourens Veen <[EMAIL PROTECTED]> said: >I may be misunderstanding, I'm not a project expert, but if the Gtk >API is frozen, the only difference between the CVS HEAD branch and >the latest developer release is bugfixes right? No, because the HEAD branch could contain preliminary attempts at bugfixes that don't actually fix the bug or which introduce new bugs. I expect things like that to appear (and subsequently disappear) from time to time on the development head. In my experience, a bugfix will appear on the head branch once the developer who found the bugfix has verified that the code compiles with the fix and appears to fix the bug, but before the bugfix has been thoroughly tested by other developers. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Fri, 27 Jul 2001 22:18:32 +0200, Lourens Veen <[EMAIL PROTECTED]> said: >I may be misunderstanding, I'm not a project expert, but if the Gtk >API is frozen, the only difference between the CVS HEAD branch and >the latest developer release is bugfixes right? So then there should >be actually less bugs in the CVS HEAD. The only risk you are running >is of it not being compilable, well, as we saw today, that might >happen with a release as well ;). "99 bugs in the code, in the code. 99 bugs in the code. Fix one bug, compile again. 100 bugs in the code, in the code." Bugs get introduced during debugging quite frequently. Sometimes they things get worse before they get better. >In the end it's a matter of trusting the Gtk developers, or rather >the CVS maintainers. Do we trust them not to break things too often, >and if the compile is broken, fix it quickly. It's not a matter of trust. It's a matter of recognizing that the development branch is under development and may break at any time. Rather than trusting the GTK developers not to break the head branch of their development code, we should simply abstain from demanding that promise from them in the first place. I don't want them going "Well, we can fix this bug the right way or the wrong way, but the right way will probably break something those GIMP people are doing and the wrong way won't. And we promised not to break their stuff." I want them to be able to do the right thing and not have to worry about whether that inconveniences us for a few hours, days, or weeks. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Kelly Martin wrote: > > Think "plugin authors". These people are going to want to start > working on porting their plugins to 2.0 well in advance of 2.0's > release but are not likely to want to cope with being GTK debuggers on > top of being GIMP debuggers. > > Kelly I may be misunderstanding, I'm not a project expert, but if the Gtk API is frozen, the only difference between the CVS HEAD branch and the latest developer release is bugfixes right? So then there should be actually less bugs in the CVS HEAD. The only risk you are running is of it not being compilable, well, as we saw today, that might happen with a release as well ;). In the end it's a matter of trusting the Gtk developers, or rather the CVS maintainers. Do we trust them not to break things too often, and if the compile is broken, fix it quickly. I have no experience with the Gtk CVS, so I can't say anything about it. Maybe we should ask them? Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
>I think we need to ask ourselves why users would want to try the >latest developer releases of Gimp. If they want to have the latest >because of having the latest, I don't think they'll mind getting CVS >HEAD branches and weeding out possible compile problems. Think "plugin authors". These people are going to want to start working on porting their plugins to 2.0 well in advance of 2.0's release but are not likely to want to cope with being GTK debuggers on top of being GIMP debuggers. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Michael Natterer wrote: > > Nick Lamb <[EMAIL PROTECTED]> writes: > > NB I am not blind and I don't write code in Hebrew > > I respect your extraordinary tolerance regarding this, so please > respect that the people actually working on a project tend to make the > decisions. Uh, that's pretty harsh if I read it right. Nick is a seasoned and consistant GIMP contributor. --Adam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Alright, this is turning into a flamewar and that's the least productive of all. Let me try to wrap up this discussion: The question: Will the gimp-1.3 developer releases depend on Gtk-1.3 HEAD CVS, or do we make certain every gimp-1.3.x release compiles with gtk-1.3.y? Arguments for depending on HEAD: - The Gtk-1.3 API is frozen, so using the latest won't break anything, it will only be better code - These releases are for developers only, normal users don't need to have anything to do with CVS. - Gtk will be tested well prior to release, avoiding the possible need of major changes after release of Gtk-2.0. Arguments against depending on HEAD, and just using the latest Gtk-1.3.y release to work with: - Gtk HEAD may not always compile, making it difficult for users to try out the development releases in the gimp-1.3 branch - If there are major advantages of CVS HEAD over the latest development release they will probably do a new release anyway, and besides, this is unlikely as Gtk-2.0 is late in its development cycle already. I might have missed one or two arguments, apologies in advance if that's the case. I think we need to ask ourselves why users would want to try the latest developer releases of Gimp. If they want to have the latest because of having the latest, I don't think they'll mind getting CVS HEAD branches and weeding out possible compile problems. But I think for gimp-1.1 there was a different reason. Gimp-1.1 had a whole lot of features that weren't in gimp-1.0. In fact, to me (as a user) Gimp-1.1 was a good graphics program, while Gimp-1.0 was hopelessly limited. So my question is, will Gimp-1.3/2.0, in the early stages of development, add much functionality? It seems to me it won't be an advantage, as for now it's basically the functionality of gimp-1.2 with a whole new implementation. But if there are no functional advantages the average user will be happy to keep using 1.2 for a while (I know I will at least). So in that case, it doesn't really matter, as long as the developers are happy. Once gimp-1.3 actually starts being a useable graphics package with more features than gimp-1.2 I think we need to worry about users being able to compile things easily, and I do believe simply depending on a fixed Gtk-version (which will then probably be at 2.0.x anyway) is a part of that. As for pango and atk, if I understand correctly they are simply part of Gtk-2.0, or at least standard companions to it. In that case why not use them? I'm sure there are gimp-users in Israel who'd like a Hebrew translation, and if that work is done already by the pango developers, why not make use of it? With Gtk-2.0, people will have it anyway. The same goes for atk. Please, try hitting the ball and not your opponent. It's not a nice thing to do, and given that your opponent is on your own team, pretty stupid as well. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On 27 Jul 2001 21:30:01 +0200, Michael Natterer <[EMAIL PROTECTED]> said: >Nick Lamb <[EMAIL PROTECTED]> writes: >>NB I am not blind and I don't write code in Hebrew >I respect your extraordinary tolerance regarding this, so please >respect that the people actually working on a project tend to make >the decisions. Please respect the fact that people who used to work on a project may once again choose work on it, and may have something of value to contribute notwithstanding their current degree of participation. On the issue of using GIMP to debug GTK: not all of the people who might work on the GIMP have an infinite amount of time to dedicate to this project. If you have four hours a week to spend on GIMP development and it takes you two of those hours to get your GTK up to whatever revision is presently being used, you've just spent half your time on what amounts to unproductive activity as far as GIMP is concerned. I don't do GIMP development right now because I have to work for a living and don't have 120 hours a week to spend on hacking code for free. And given the attitude just expressed, it would appear that there are better uses for my limited spare time than working on the GIMP. Thanks for making this clear for me. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Nick Lamb <[EMAIL PROTECTED]> writes: > NB I am not blind and I don't write code in Hebrew I respect your extraordinary tolerance regarding this, so please respect that the people actually working on a project tend to make the decisions. regards, --Mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Fri, Jul 27, 2001 at 09:54:41AM -0700, Seth Burgess wrote: > As an occasional developer, I ran into a problem trying to get CVS pango > working - errors on link with the qt libraries. Anyone else expereienced > these? Not at my machine now, or I'd include the errors. > > I didn't see any obvious switches in the configure. I'm a bit annoyed > that qt is keeping me from compiling gtk... There is a configure switch: use the --with-qt=no flag. There used to be a bug whereby the configure process would detect that you had a version of libqt installed, but not check that it was a recent enough version. I thought Owen (Taylor) had looked at this, but maybe it's still there (I use the above flag, so I'm not really noticing this change). Cheers, Malcolm -- Kleptomania: take something for it. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Seth Burgess <[EMAIL PROTECTED]> writes: > As an occasional developer, I ran into a problem trying to get CVS pango > working - errors on link with the qt libraries. Anyone else expereienced > these? Not at my machine now, or I'd include the errors. > > I didn't see any obvious switches in the configure. I'm a bit annoyed that qt > is keeping me from compiling gtk... QT is only used to compile a viewer test application. I'd suggest you pass '--with-qt=no' to configure. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
As an occasional developer, I ran into a problem trying to get CVS pango working - errors on link with the qt libraries. Anyone else expereienced these? Not at my machine now, or I'd include the errors. I didn't see any obvious switches in the configure. I'm a bit annoyed that qt is keeping me from compiling gtk... Seth --- Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Fri, Jul 27, 2001 at 02:12:05AM +0100, Nick Lamb wrote: > > On Thu, Jul 26, 2001 at 01:27:59AM -0400, Malcolm Tredinnick wrote: > > > For CVS gimp, it is definitely not a problem to require the current > > > bleeding edge GTK. > > > > Malcolm did you ask me first? If you didn't, how did you come to the > > conclusion that it wouldn't be a problem for me (a developer, even if > > not one who's able to dedicate many hours to Gimp right now) to > > install and tend a GTK+ HEAD tree just to keep my Gimp builds green? > > Get a grip! I'm not the one making the decision; what I posted was an > opinion. > > That said, if you want to do development and gimp chooses to track > gtk+'s main branch, then there is a once off effort to get the gtk setup > working and port your stuff. Then it's minor updating and rebuilding. > For many months now I, personally, have not had problems keeping a gtk+ > CVS installation running for my development work. They are in API freeze > (more or less) now, so things are only going to get better. > > > How will this make things better for me? > > Apparently you've decided it won't. Deal with it. > > >NB I am not blind and I don't write code in Hebrew > > So pango is not included specifically for you. You are lucky. However, > the i18n team will make use of pango to get decent display and widget > layout. I admit that a visually impaired version of the Gimp would be, > well, interesting, but a version allowing alternate input methods would > be useful (e.g. somebody who cannot use their hands). Incorporating > these toolkits means that _other_ people can come along and make your > plugins work well for everybody. > > Malcolm > > -- > How many of you believe in telekinesis? Raise my hand... > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Fri, Jul 27, 2001 at 02:12:05AM +0100, Nick Lamb wrote: > On Thu, Jul 26, 2001 at 01:27:59AM -0400, Malcolm Tredinnick wrote: > > For CVS gimp, it is definitely not a problem to require the current > > bleeding edge GTK. > > Malcolm did you ask me first? If you didn't, how did you come to the > conclusion that it wouldn't be a problem for me (a developer, even if > not one who's able to dedicate many hours to Gimp right now) to > install and tend a GTK+ HEAD tree just to keep my Gimp builds green? Get a grip! I'm not the one making the decision; what I posted was an opinion. That said, if you want to do development and gimp chooses to track gtk+'s main branch, then there is a once off effort to get the gtk setup working and port your stuff. Then it's minor updating and rebuilding. For many months now I, personally, have not had problems keeping a gtk+ CVS installation running for my development work. They are in API freeze (more or less) now, so things are only going to get better. > How will this make things better for me? Apparently you've decided it won't. Deal with it. >NB I am not blind and I don't write code in Hebrew So pango is not included specifically for you. You are lucky. However, the i18n team will make use of pango to get decent display and widget layout. I admit that a visually impaired version of the Gimp would be, well, interesting, but a version allowing alternate input methods would be useful (e.g. somebody who cannot use their hands). Incorporating these toolkits means that _other_ people can come along and make your plugins work well for everybody. Malcolm -- How many of you believe in telekinesis? Raise my hand... ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Thu, Jul 26, 2001 at 01:27:59AM -0400, Malcolm Tredinnick wrote: > For CVS gimp, it is definitely not a problem to require the current > bleeding edge GTK. Malcolm did you ask me first? If you didn't, how did you come to the conclusion that it wouldn't be a problem for me (a developer, even if not one who's able to dedicate many hours to Gimp right now) to install and tend a GTK+ HEAD tree just to keep my Gimp builds green? How will this make things better for me? NB I am not blind and I don't write code in Hebrew Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 05:57:50PM +0100, Adam D. Moss wrote: > Michael Natterer wrote: > > after some hours of torturing it with perl and some manual hacking, > > i got gimp running on current CVS glib/gtk+. > ... > > (applying it means that if you want to hack or simply use gimp 1.3, > > you will need glib, pango, atk and gtk+ HEAD from CVS too). > > I few questions: > > * What are pango and atk, and why do we suddenly require them (if > indeed we do)? Pango is the text layout foundation for gtk (to abuse terminology slightly). It provides a uniform way to do things like multi-lingual layouts (coupling left-to-right and right-to-left text using different character sets on the same line). This may not seem like such a huge win for gimp, but it is a necessary requirement for Gtk 2.0 now. The atk package is the accessibility toolkit and provides ways for non-visual and non-keyboard/mouse interaction with gtk-based application. This is one of the concrete results of Sun's input into the Gnome community. They both advocated the need for such an elephant and produced the code. > * Are there compelling advantages to using CVS-GTK which outweigh > the cons of forcing developers and users to upgrade? Is GTK 1.3 > not backwardly compatible with the GTK 1.2 API? My concern is > that with such a casual-user oriented application as GIMP we > can easily lose users by the wayside with each additional > stipulation. Gtk 1.3 is the development branch, so it can't be relied upon for release verisons of other software. It will eventually metamorph into Gtk 2.0, which will be the stable branch. It has never been a secret that this will not be backwards compatible with Gtk 1.2. If you look in the gtk source code, there is a file called Porting-2.0.txt (or something like that) that explains the changes needed to go from 1.2 -> 1.3/2.0 to make an application simply run. This does not cover the new gee-whiz features that have been added to the 1.3 branch -- it is simply a porting guide. The required changes are reasonably mechanical and not overly difficult (based on my experience of porting about four apps so far). For CVS gimp, it is definitely not a problem to require the current bleeding edge GTK. Casual users should not be using this if they are not interested in tracking dependencies. When Gtk-2.0 is released, it will be rapidly shipped with all the distributions and requiring/requesting users to upgrade should not be an issue. Until that time, it would be crazy for 1.2 versions of the Gimp to depend on this version of gtk, since it is still only in slightly-frozen API stages and many bug fixes, etc are still occurring. > * For those of us with pieces of the tree's core which diverge > somewhat from the trunk, how much of a no-brainer is converting > our code to GTK 1.3-isms? Read the porting document i mention above. It's not that difficult -- truly just search and replace in most cases. Cheers, Malcolm -- Quantum mechanics: the dreams stuff is made of. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Thu, Jul 26, 2001 at 12:01:35PM +0200, Michael Natterer <[EMAIL PROTECTED]> wrote: > Porting GIMP to Gtk2 will need a substantial amount of time and hacking > and if we'd start it _after_ GTK 2.0 is final, we will need another 12-24 > months until it's stable. In addition, gimp is a very nontrivial application. Porting gimp before gtk-2.0 makes it possible to correct problems in gtk+, if there are any. afetr 2.0 is released it's more difficult. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 11:18:58PM -0500, Kelly Martin <[EMAIL PROTECTED]> wrote: > sufficiently large y. We bumped y as it became necessary. The HEAD > revision was only occasionally required, and usually only for a short > time until GTK+ released a new unstable version. so what? nobody requires the head revision all the time. please calm down! if you think about then you'd see that "requiring the head revision" as you interpret it makes no sense. > I don't know what "every project" you've worked on. Probably because I didn't mention any. Why should I? Am I required to work on a project before I can tell which libraries they use? > This is a completely INSANE model for any project of any size that wants > to actually get anything done. It works fine, thank you. Do you have any _reasons_ to object, apart from not personally liking that model? > (Of course, project leadership in most open-source projects is almost > completely nonexistent You really escape me here. Project leadership is quite strong in most open-source projects IMHO. Gimp is the exception, and worked exceptionally well so far. To the contrary, many projects with strong leadership (glibc, gnome, even gcc althoguh I am not that sure about strong leadership ;) had a lot of problems. Look at all the BSD projects. > reason why GIMP development has to be that way. It wasn't in 1.0, at > least. I wasn't as involved in 1.2.) I don't think the pre-1.0 "development model" (if you could call it a model) is a goal to go for, actually. > > if the head revision isn't compilable nobody can wotk with it. > > Which is precisely why GIMP developers should not rely on it. GIMP > developers are developing GIMP, not GTK+. GTK+ is gimp's toolkit, and breaking ties even more than already is the case is a bad thing for both projects. > If an individual developer WANTS to work with the head revision, > that's fine, but development should not REQUIRE it, why? > should be wary of introducing dependencies on features not yet > stabilized. why do you think they aren't? why do you not trust mitch? > You should require the OLDEST version that suffices, not > the newest. but that might well be the current head revision. your logic is this: we could write gimp using motif and it is stable. let's not move to gtk. progress can only be made by using newer gtk and esp. glib versions. what yo you expect from developers: develop a second glib because glib itself is not released yet, or just plain WAIT until it comes out so they cna finally make progress? > usage of GTK+.) Application authors should NEVER assume that their > users like to live on the cutting edge. Are you remotely aware of the fact that we are talking about development versions here? Obviously not. EVERY free software project progresses by using other people's work. Otherwise linux would still require gcc-2.5.2, gimp would sitll require motif and Xfree would still have no 3d. > Most users do not. Most users use unstable alpha versions of gimp? Hello? > upgrade the Linux systems that I'm paid to maintain when something > breaks, and we should not force users to upgrade a nonbroken library > unless the upgrade provides essential (or at least strongly desirable) > functionality. Hello? Development version? > >totally unreasonable to expect non-compilability on a regular > >base. How often couldn't you compile gimp-1.1.2x? > > I broke 0.99.x and 1.1.x on several occasions. Too bad. Nobody would veer had found out if there weren't some savy users out there who, indeed, like to be on the cutting edge and used unstable development versions of gimp. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
"Adam D. Moss" <[EMAIL PROTECTED]> writes: > We had an adequately generic GUI and most users couldn't > give a whit about the internal object model, but I can > see an attraction to hackers. Well I find GIMP 1.2's UI not at all generic. The whole GIMP is a huge pile of global variables and dialogs which are not generic views but are hardcoded each-for-each, requiring making the same error-prone changes to many files at the same time if something has to change. > > > >* For those of us with pieces of the tree's core which diverge > > > >somewhat from the trunk, how much of a no-brainer is converting our > > > >code to GTK 1.3-isms? > > > > The changes made for 2.0 migration are much less of a structural change > > than what happens in two weeks of usual HEAD-reorganizing. Not a single > > file was moved and almost only the object stuff was touched. > > It was an honest and straightforward question, not a > rhetorical one; what is involved? Are the changes largely > syntactic, or deeper? Ok, I simply got it wrong. Porting to GLib2 is totally straightforward. If there are no selfmade objects or widgets involved, it's almost 100% source compatible, so code will compile smoothly (except for a few warnings because glib/gtk+ return much more const string now). Porting code which only uses the object model can be done step-by-step as there are compatibility wrappers around the new GLib object ans signal stuff. It's mostly: gtk_signal_connect()-> g_signal_connect() gtk_signal_connect_object() -> g_signal_connect_swapped() gtk_signal_connect_while_alive()-> g_signal_connect_object(..., 0) gtk_signal_connect_object_while_alive() -> g_signal_connect_object (..., G_CONNECT_SWAPPED) This is the olny change in Gtk user code that actually needs thinking because g_signal_connect_object() does NOT correspond to gtk_signal_connect_object() Everything else is mostly like s/gtk_object_ref/g_object_ref/, s/GTK_SIGNAL_FUNC/G_CALLBACK/ Objects and Widgets however need manual hacking, not just sed/perl voodoo. After porting some of them, it takes about 10 minutes each. > > What's a "no-brainer" BTW ? > > Something that does not require brain. =) Hehe, true. Most of this stuff is slave work :-) > > After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's > > bleeding edge version? This is unstable development. > > No, I *really* don't see the logic there at all. That's > bleeding for bleeding's sake. GTK took a life of its own > millenia ago and their destinies are no longer entwined. You're right, this is not an argument. I said this _after_ explaining things. Porting GIMP to Gtk2 will need a substantial amount of time and hacking and if we'd start it _after_ GTK 2.0 is final, we will need another 12-24 months until it's stable. IMHO porting it now was 100% right at this point of time, otherwise the goal of releasing GIMP 1.4 by the end of this year cannon be reached. > But the deed is done. :) Yes. ciao, --Mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Thu, 26 Jul 2001 05:13:09 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> said: >because that's what they do, what gimp does, what every other project >does. Gimp 1.1.x, as I recall, was set up to work with any GTK 1.1.y for sufficiently large y. We bumped y as it became necessary. The HEAD revision was only occasionally required, and usually only for a short time until GTK+ released a new unstable version. I don't know what "every project" you've worked on. This is a completely INSANE model for any project of any size that wants to actually get anything done. (Of course, project leadership in most open-source projects is almost completely nonexistent, but that is no reason why GIMP development has to be that way. It wasn't in 1.0, at least. I wasn't as involved in 1.2.) > if the head revision isn't compilable nobody can wotk with it. Which is precisely why GIMP developers should not rely on it. GIMP developers are developing GIMP, not GTK+. If an individual developer WANTS to work with the head revision, that's fine, but development should not REQUIRE it, and developers should be wary of introducing dependencies on features not yet stabilized. You should require the OLDEST version that suffices, not the newest. (This is a general rule of using libraries, not one specific to GIMP's usage of GTK+.) Application authors should NEVER assume that their users like to live on the cutting edge. Most users do not. I only upgrade the Linux systems that I'm paid to maintain when something breaks, and we should not force users to upgrade a nonbroken library unless the upgrade provides essential (or at least strongly desirable) functionality. >As sven has said, they made an API freeze recently. That means they >are already pretty late in the development phase. I think it's >totally unreasonable to expect non-compilability on a regular >base. How often couldn't you compile gimp-1.1.2x? I broke 0.99.x and 1.1.x on several occasions. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 04:40:41PM -0500, Kelly Martin <[EMAIL PROTECTED]> wrote: > Why should we expect the GTK+ developers to keep their HEAD revision > compilable at every moment? because that's what they do, what gimp does, what every other project does. if the head revision isn't compilable nobody can wotk with it. > That is a completely unreasonable It's completely reasonable ;) > expectation in the first place. If I were a GTK+ developer I would be > asking that you NOT do what you're proposing because it creates I am not proposing anything. > in the GIMP (which it probably is not), I would strongly urge picking > a relatively stable snapshot of GTK+ current development (possibly, > but not necessarily HEAD today) and use that. We might have to adjust > later to any changes GTK+ makes to its HEAD after that snapshot, but > at least we won't have to adjust to them willy-nilly as they make As sven has said, they made an API freeze recently. That means they are already pretty late in the development phase. I think it's totally unreasonable to expect non-compilability on a regular base. How often couldn't you compile gimp-1.1.2x? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Kelly Martin <[EMAIL PROTECTED]> writes: > Why can't we just use 1.3.6? That's a frozen release that should be > reasonably close to the eventual 2.0.0 release. who said, we couldn't do this? I do know that the current CVS HEAD works and has some smaller improvements but that could of course have changed since I last checked (yesterday). You are probably right that we should suggest using a release instead of CVS HEAD. > There is simply NO good reason to be dependent on the CVS HEAD, no > matter how stable the GTK developers think it might be. I think we do not really depend on it and 1.3.6 should work fine. At the moment our configure script wants 1.3.7 which has not yet been released. We can simply change this but I hope that anyway 1.3.7 will be out soon. There is a reason why we waited until the API freeze and a few weeks longer before we even considered starting the port. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On 26 Jul 2001 00:17:03 +0200, Sven Neumann <[EMAIL PROTECTED]> said: >you are obviously not well informed about the current state of >GTK+-2.0. No, I don't _care_ about the current state of the development of an unreleased package. We should not be using unreleased code. Why can't we just use 1.3.6? That's a frozen release that should be reasonably close to the eventual 2.0.0 release. Why should we introduce this sort of instability to GIMP development when we don't have a good reason to? When 1.3.7 comes out, we can advance to that. There is simply NO good reason to be dependent on the CVS HEAD, no matter how stable the GTK developers think it might be. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Kelly Martin wrote: > [snip] > If GTK stable release (1.2) is not acceptable for further development > in the GIMP (which it probably is not), I would strongly urge picking > a relatively stable snapshot of GTK+ current development (possibly, > but not necessarily HEAD today) and use that. We might have to adjust > later to any changes GTK+ makes to its HEAD after that snapshot, but > at least we won't have to adjust to them willy-nilly as they make > them. > > Kelly Sorry for jumping into this discussion in the middle, but I happen to have an opinion on this :). What about all the bugs in the chosen snapshot? I mean they get ironed out during the GTK+ development, but the Gimp developers are stuck with them during development. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Kelly Martin <[EMAIL PROTECTED]> writes: > Why should we expect the GTK+ developers to keep their HEAD revision > compilable at every moment? That is a completely unreasonable > expectation in the first place. If I were a GTK+ developer I would be > asking that you NOT do what you're proposing because it creates > pressure on them to keep their HEAD "workable" at all times instead of > doing what they need to do in order to further their own development. you are obviously not well informed about the current state of GTK+-2.0. The announcement of the latest releases (1.3.6 is the latest, 1.3.7 should be out pretty soon) had the following note: This release is meant for: * Those interested in the development of GTK+. * People planning to port to the upcoming GTK+-2.0 version of GTK+. Note: the API is mostly frozen at this point. Major API changes beyond the remaining open '2.0 API freeze' bugs in bugzilla are unlikely to occur before GTK+-2.0 is released. Now this is about five weeks ago and the API has been frozen in the meantime. The 1.3.7 release should give everyone a working and reasonably stable version to work with. As said, we use it every day for months now and I can only vaguely remember the one or two days when GLib, Pango, ATK and GTK+ from CVS HEAD didn't built out of the box. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, 25 Jul 2001 22:59:11 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> said: >It's more of a social problem: do we *trust* the gtk development >model to be stable most of the time? I did trust the gimp developers >that they want working code as well, and it worked fine. If gtk+ is >as chaotic as you think it is, it is evry bad and gimp shouldn't use >the HEAD revision. Why should we expect the GTK+ developers to keep their HEAD revision compilable at every moment? That is a completely unreasonable expectation in the first place. If I were a GTK+ developer I would be asking that you NOT do what you're proposing because it creates pressure on them to keep their HEAD "workable" at all times instead of doing what they need to do in order to further their own development. If GTK stable release (1.2) is not acceptable for further development in the GIMP (which it probably is not), I would strongly urge picking a relatively stable snapshot of GTK+ current development (possibly, but not necessarily HEAD today) and use that. We might have to adjust later to any changes GTK+ makes to its HEAD after that snapshot, but at least we won't have to adjust to them willy-nilly as they make them. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Nick Lamb <[EMAIL PROTECTED]> writes: > * Can you 100% guarantee that Gtk+ HEAD builds and runs? > If not, every time it's red we stall work on Gimp. That's no good. we are using it for production work every day. We are doing this for more than half a year now and it has indeed been a problem with the early versions of GLib-2.0 and GTK+-2.0. > * Can you 100% guarantee that APIs are frozen? How about ABIs? > If not we have to screen out errors caused by mis-matched versions on > a daily basis just as some projects did during 1.1.x. It is painful. The API has been frozen about 3 weeks ago. The port turned out to be much easier than expected and I'm very happy that we can finally start to implement new stuff that is only possible with GTK+-2.0 and friends. I'm looking forward to start hacking a decent Text Tool using Pango for example. For those that questioned the availability of ports for GTK+-2.0, check this screenshot of GIMP on DirectFB: http://www.directfb.org/screenshots/gimp.png AFAIK the Win32 port is in an even better shape. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 03:43:51PM -0500, Kelly Martin <[EMAIL PROTECTED]> wrote: > If you have to use a "development" version at least pick a fixed point > in development and use that. Otherwise you're coding to not one, but > two moving targets: your own code PLUS the moving code in the library > you depend on. Or, in this case, five. > > If your goal is to make development as chaotic and difficult as > possible, you are on the right track. I am sorry, but what you describe is reality for most plug-in authors. Did plug-in developers develop for gtk-1.0 and gimp-1.0 a year ago? It's more of a social problem: do we *trust* the gtk development model to be stable most of the time? I did trust the gimp developers that they want working code as well, and it worked fine. If gtk+ is as chaotic as you think it is, it is evry bad and gimp shouldn't use the HEAD revision. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, 25 Jul 2001 21:41:03 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> said: >There is cvs, so knowledge about "HEAD doesn't work, try last week's >version" will spread soon through developer circles. This qualifies as one of the worst excuses I've heard yet. If you have to use a "development" version at least pick a fixed point in development and use that. Otherwise you're coding to not one, but two moving targets: your own code PLUS the moving code in the library you depend on. Or, in this case, five. If your goal is to make development as chaotic and difficult as possible, you are on the right track. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On 25 Jul 2001 20:12:28 +0200, Michael Natterer <[EMAIL PROTECTED]> said: >IMHO the pro's outweigh the con's by far, as it's simply not possible >without grand hacks to write an internal object model and a nice >generic GUI with Gtk 1.2. If this is the real reason, then I can understand the desire, but I would really rather not see reliance on unreleased versions of _any_ library without a compelling reason. >After all, isn't is just natural for GIMP HEAD to use the GIMP >Toolkit's bleeding edge version? This is unstable development. For example, this is a great of example of a reason which is NOT compelling, or even rational. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
At 20:12 25.07.01 +0200, Michael Natterer wrote: > [..., removed everything I totally agree with] > >And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a >stable version (which will be in not too distant future). > >IMHO the pro's outweigh the con's by far, as it's simply not >possible without grand hacks to write an internal object model >and a nice generic GUI with Gtk 1.2. > One great advantage will obviously be, that Gtk+2.0 will get some serious testing with it's main application. >Kelly Martin <[EMAIL PROTECTED]> writes: > >> I would add: >> >> * are there Windows versions of pango and atk? Yepp. Two backends for Pango (FreeType2 and Native). The Native one actively maintained, but somewhat slow. The other one I have never compiled/used. >> * do we reasonably expect Windows ports of the HEAD versions of all of >> these libraries before 1.4 is released? > IMHO the state of the Gtk+2.0 is in a much more promising shape than the probably dead branch 'gtk-1-3-win32-production' >This is a misunderstanding: _only_ GLib/Gtk 2.0 exist for windows, the >current hack to compile GIMP for windows with a Gtk 1.3 snapshot which >is almost a year old is the reason for all those windows bugreports. > Without knowing 'all those windows bugreports' I seriously doubt that all those bugreports are caused by the early Gtk-1.3 version used. There are simply much less active developers working on the win32 version of Gimp(TK). >Pango and ATK of course compile under windows and the folks porting GIMP >to windows will love to use a sane version of Gtk. > How did you know this :-) ? >After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's >bleeding edge version? This is unstable development. > If I would have anything to say I would say: Go for it! Regards, Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 07:43:12PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > * Can you 100% guarantee that Gtk+ HEAD builds and runs? > If not, every time it's red we stall work on Gimp. That's no good. There is cvs, so knowledge about "HEAD doesn't work, try last week's version" will spread soon through developer circles. I think that the work of porting now is less than the work of porting after a release IF the head version really is as stable as Michael says. I take his word for that ;) > * Can you 100% guarantee that APIs are frozen? Of couse not, not even with gtk-1.2. > How about ABIs? Get broken all the time. Sidenote: To make confusion worse, neither gimp nor gtk (nor glib AFAICS) use proper version numbers. Instead of encoding the ABI version (as is common standard with ELF) they all just encode their "public" version number, which is useless with respect to ABI changes. > If not we have to screen out errors caused by mis-matched versions on > a daily basis just as some projects did during 1.1.x. It is painful. Hmmm... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
And finally... I had to address this: Michael Natterer wrote: > This is unstable development. This is a fairy tale that developers like to spread to keep the unwary users' expectations down. The reality is that labelling the trunk an 'unstable' tree is not a license to actively go about doing work /in-situ/ on the trunk which is known to most definitely have a destabilising effect. That's what CVS branches are for. In a concurrent- development environment it is simply not quite polite to work out very core issues on the trunk where every other developer (or brave user) is held hostage, patches crossed behind their backs, while things get banged into shape. I'm not specifically pointing at the GTK 2.0 changes as an example of this, but wish to warn against 'unstable'-labelled versions being a self-fulfilling prophesy when they turn into a chaotic free-for-all which developers hope will all come out in the wash in a real hurry near the end of the 'unstable' cycle. --Adam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 08:12:28PM +0200, Michael Natterer wrote: > And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a > stable version (which will be in not too distant future). Yes, these sound like excellent reasons to port Gimp to Gtk+ 2.0 as soon as possible after the Gtk+ team release the first stable version. But for some reason people want to do it... tomorrow? next week? So, now I have some more questions * Can you 100% guarantee that Gtk+ HEAD builds and runs? If not, every time it's red we stall work on Gimp. That's no good. * Can you 100% guarantee that APIs are frozen? How about ABIs? If not we have to screen out errors caused by mis-matched versions on a daily basis just as some projects did during 1.1.x. It is painful. I appreciate that Gtk+ hackers would love a big project like Gimp to be running on 2.0 from day zero, but I am no longer interested in Gtk+ development, I'm a user and I don't have time to fight with it during the few moments I can spare to fix Gimp bugs. Of course my views don't count for much, but you asked for them :) Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Michael Natterer wrote: > And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a > stable version (which will be in not too distant future). I assumed nothing less. > IMHO the pro's outweigh the con's by far, as it's simply not > possible without grand hacks to write an internal object model > and a nice generic GUI with Gtk 1.2. We had an adequately generic GUI and most users couldn't give a whit about the internal object model, but I can see an attraction to hackers. > > >* For those of us with pieces of the tree's core which diverge > > >somewhat from the trunk, how much of a no-brainer is converting our > > >code to GTK 1.3-isms? > > The changes made for 2.0 migration are much less of a structural change > than what happens in two weeks of usual HEAD-reorganizing. Not a single > file was moved and almost only the object stuff was touched. It was an honest and straightforward question, not a rhetorical one; what is involved? Are the changes largely syntactic, or deeper? > What's a "no-brainer" BTW ? Something that does not require brain. =) > After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's > bleeding edge version? This is unstable development. No, I *really* don't see the logic there at all. That's bleeding for bleeding's sake. GTK took a life of its own millenia ago and their destinies are no longer entwined. But the deed is done. :) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, answering both mails in one... Kelly Martin <[EMAIL PROTECTED]> writes: > On Wed, 25 Jul 2001 17:57:50 +0100, "Adam D. Moss" <[EMAIL PROTECTED]> said: > > >* What are pango and atk, and why do we suddenly require them (if > >indeed we do)? Pango is the font layout and rendering system used by gtk+. It allows for fancy stuff like bidirectional text and makes an end to the X font mess. ATK is the accessibility toolkit which allows e.g. voice control of programs. Both are required by gtk+ HEAD and everything compiles 100% smoothly most of the time. > >* Are there compelling advantages to using CVS-GTK which outweigh the > >cons of forcing developers and users to upgrade? Is GTK 1.3 not > >backwardly compatible with the GTK 1.2 API? My concern is that with > >such a casual-user oriented application as GIMP we can easily lose > >users by the wayside with each additional stipulation. There are lots of advantages with Glib/Gtk 2.0. One of them is the clean core/ui separation they provide because the object system has been moved to GLib. We get sane Xinput support and support for new platforms (because GDK is frontend/backend separated now). We get a much improved object system, better looking widgets, better user preferences for widgets classes. We can strip tons and tons of evil hacks because we also get rid of lots of gtk 1.2 brokenness. And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a stable version (which will be in not too distant future). IMHO the pro's outweigh the con's by far, as it's simply not possible without grand hacks to write an internal object model and a nice generic GUI with Gtk 1.2. The biggest pro of GLib 2.0's object system is it's great degree of dynamism which will bring us e.g. pluggable tools almost for free. Also, it will simply not be possible to include a Gtk+ header from app/core/, which is great for enforcing core/ui separation. > >* For those of us with pieces of the tree's core which diverge > >somewhat from the trunk, how much of a no-brainer is converting our > >code to GTK 1.3-isms? The changes made for 2.0 migration are much less of a structural change than what happens in two weeks of usual HEAD-reorganizing. Not a single file was moved and almost only the object stuff was touched. Gtk 2.0 is _very_ source compatible compared to Gtk 1.2 except for the object system (which is much more consistent and powerful than before) What's a "no-brainer" BTW ? > I would add: > > * are there Windows versions of pango and atk? > * do we reasonably expect Windows ports of the HEAD versions of all of > these libraries before 1.4 is released? This is a misunderstanding: _only_ GLib/Gtk 2.0 exist for windows, the current hack to compile GIMP for windows with a Gtk 1.3 snapshot which is almost a year old is the reason for all those windows bugreports. Pango and ATK of course compile under windows and the folks porting GIMP to windows will love to use a sane version of Gtk. After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's bleeding edge version? This is unstable development. ciao, --Mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, 25 Jul 2001 17:57:50 +0100, "Adam D. Moss" <[EMAIL PROTECTED]> said: >* What are pango and atk, and why do we suddenly require them (if >indeed we do)? >* Are there compelling advantages to using CVS-GTK which outweigh the >cons of forcing developers and users to upgrade? Is GTK 1.3 not >backwardly compatible with the GTK 1.2 API? My concern is that with >such a casual-user oriented application as GIMP we can easily lose >users by the wayside with each additional stipulation. >* For those of us with pieces of the tree's core which diverge >somewhat from the trunk, how much of a no-brainer is converting our >code to GTK 1.3-isms? I would add: * are there Windows versions of pango and atk? * do we reasonably expect Windows ports of the HEAD versions of all of these libraries before 1.4 is released? Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
"Adam D. Moss" wrote: > Is GTK 1.3 (or GTK 1.9, or 2.0, or whatever the GTK HEAD is!) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Michael Natterer wrote: > after some hours of torturing it with perl and some manual hacking, > i got gimp running on current CVS glib/gtk+. ... > (applying it means that if you want to hack or simply use gimp 1.3, > you will need glib, pango, atk and gtk+ HEAD from CVS too). I few questions: * What are pango and atk, and why do we suddenly require them (if indeed we do)? * Are there compelling advantages to using CVS-GTK which outweigh the cons of forcing developers and users to upgrade? Is GTK 1.3 not backwardly compatible with the GTK 1.2 API? My concern is that with such a casual-user oriented application as GIMP we can easily lose users by the wayside with each additional stipulation. * For those of us with pieces of the tree's core which diverge somewhat from the trunk, how much of a no-brainer is converting our code to GTK 1.3-isms? Ta, --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 "But one of the funny things with very pretty girls is that ... men think they won't have a chance with them, so they don't ask them out. I do ask. And... quite often, they come out with me. Probably out of curiosity, or something." -- Sir Clive Sinclair ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] glib/gtk+ 2.0 port
Hi all, after some hours of torturing it with perl and some manual hacking, i got gimp running on current CVS glib/gtk+. the patch changes tons of files, mostly object-related stuff in libgimpwidgets/, app/core/ and app/widgets/, and excludes some plug-ins from the build (the plug-ins are trivial to fix). does anyone have objections (like "stop, i want to commit my blah change first!") against committing the patch now? (applying it means that if you want to hack or simply use gimp 1.3, you will need glib, pango, atk and gtk+ HEAD from CVS too). please scream now, i'll apply it within the next few days... ciao, --Mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer