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] ANNOUNCE: GIMP 1.2.2
Hi, [EMAIL PROTECTED] writes: > > Please excuse this inconvenience and let's hope the new tarballs > > work for you. > > Really bad idea. This means that there are two versions of 1.2.2 > floating around; one which build and one that doesn't. I'd REALLY > suggest to update the version number I considered this, but decided not to do it since it will build on most systems out there. 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 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] ANNOUNCE: GIMP 1.2.2
On 27 Jul, Sven Neumann wrote: > Please excuse this inconvenience and let's hope the new tarballs > work for you. Really bad idea. This means that there are two versions of 1.2.2 floating around; one which build and one that doesn't. I'd REALLY suggest to update the version number Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.2.2
Hi, there has been a problem with the 1.2.2 tarballs that made the build fail for people that don't have msgfmt (part of gettext) installed. I have built new tarballs that should fix this problem. Unfortunately some mirrors already have the old tarballs and it will take some time for them to catch up. The new fixed tarballs are: 9846904 Jul 27 07:05 gimp-1.2.2.tar.bz2 13520420 Jul 27 07:05 gimp-1.2.2.tar.gz Please excuse this inconvenience and let's hope the new tarballs work for you. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.2.2
Hi, Austin Donnelly <[EMAIL PROTECTED]> writes: > Oops. It doesn't build out of the box. D'oh!!! > && rm -f $file && PATH=../src:$PATH -o $file lt.po > /bin/sh: -o: command not found > make[2]: *** [lt.gmo] Error 127 > make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-plug-ins' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2' > make: *** [all-recursive-am] Error 2 > > > It looks like something involved in making po files isn't present on > my system and the makefiles or configure etc isn't coping. arghh, we did test this thing on a couple of systems without any problems. It looks as if for some reason or another lt.gmo files are missing from the tarball. No idea what went wrong on make dist here. I'll put up a new tarball fixing this problem. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.2.2
On , 27 Jul 2001, Sven Neumann wrote: > ftp://ftp.gimp.org/pub/gimp/v1.2/v1.2.2/ > > This release fixes a large bunch of bugs, adds a couple of > new translations and features a complete rewrite of the > help pages. Oops. It doesn't build out of the box. D'oh!!! [...] creating libcolorsel_water.la (cd .libs && rm -f libcolorsel_water.la && ln -s ../libcolorsel_water.la libcolorsel_water.la) make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/modules' Making all in po make[2]: Entering directory `/local/scratch/and1000/gimp/gimp-1.2.2/po' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/po' Making all in po-libgimp make[2]: Entering directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-libgimp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-libgimp' Making all in po-plug-ins make[2]: Entering directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-plug-ins' file=./`echo lt | sed 's,.*/,,'`.gmo \ && rm -f $file && PATH=../src:$PATH -o $file lt.po /bin/sh: -o: command not found make[2]: *** [lt.gmo] Error 127 make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-plug-ins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2' make: *** [all-recursive-am] Error 2 It looks like something involved in making po files isn't present on my system and the makefiles or configure etc isn't coping. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: GIMP 1.2.2
Hi, GIMP 1.2.2 is finally out and still a hadjaha release. ftp://ftp.gimp.org/pub/gimp/v1.2/v1.2.2/ This release fixes a large bunch of bugs, adds a couple of new translations and features a complete rewrite of the help pages. Happy GIMPing Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer