Re: [Gimp-developer] Third big serious meeting from GIMPcon
Raphaël Quinet [EMAIL PROTECTED] writes: Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). both debian unstable, mandrake and redhat provides gtk+2.x for quite a long time. The current GIMP requires GTK+ 2.2.0 and recommends 2.2.2 (this will be required by the next version). Unfortunately, many users of the distributions mentioned above are still using GTK+ 2.0.x, not 2.2.x. Besides, the majority of the users are not using the latest version of their distribution. - current debian unstable = 2.2.2 (2.2.2-3) - current mandrake cooker = 2.2.2 (2.2.2-6mdk) - current rh rawhide = 2.2.2 (gtk2-2.2.2-2.1) mdk9.2 is scheduled to be released on septembed, i do not remebed exact date for rh but it's supposed to be at the same time. debian is expected to be releasd on december. so this issue may not be a real one. you're left to few classes of users: - those who use only distro packages: they will wait until a binary package is availlable - those who know how ot build programs: they're supposed to know how to build dependancies and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version. this is a valid point for: - users of very old distributions - non developer users (that is most end users) - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy) This is not only about users of very old distributions. The world is not only Linux and Windows, and the Linux world is not only made of binary distributions. agreed. Assuming that a system has at least some basic tools such as make and a compiler, building GIMP 1.3.x adds 27 dependencies (or 32 if you are a developer who also needs libtool, autoconf, etc.) Compare this with GIMP 1.2.x, which had only 11 dependencies (or 14 for developers.) factoring features around all tools is nice even if it's bring more dependancies. sure it's Even if we could create the binary packages, I don't think that we should distribute them from the GIMP web site. This means that we would get support questions for these binaries. We already get some distribution-specific bug reports from time to time, but we can usually divert them to a more appropriate place. Supporting the binaries is not something that most developers would enjoy doing. So it is better if someone else can take care of building and distributing binaries for us. This can be a Linux distributor or some individual who puts the binaries on his web site (like it is currently done for the Windows version). so since, most oses are in one of the following states: - already provides gimp-1.3.x somewhere (debian unstable, mandrake contribs) - is ready for gimp-1.3.x regarding dependancies (redhat) - some site provide prebuild binaires (windows) and since other oses are either small regarding number of users or their users are expected to know how to build something (eg: those who already build gimp on solaris like you) are able to deal with a few more dependancies that are anyway needed for other programs, i think this issue can then be closed and this feature be not provided by gimp.org. We would be glad to link to these sites from the GIMP web site, but it is better to avoid hosting any binaries on www.gimp.org. though, this web site could then figure some url to get binaries for most people (either distros packages or tarballs from third parties) [maybe it exists already, i didn't check it out] As far as I am concerned (I spend several hours per week on Bugzilla), I don't think that answering Bugzilla by mail would really save time. For every third or fourth bug to which I respond, I do a Bugzilla query to find related bugs. Since I use the web interface for queries, I don't think that I would save much time by using e-mail for the other bugs. well, ones can use its bugzilla mail box for such queries :-) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Hi, On Sun, 2003-08-24 at 14:23, Thierry Vignaud wrote: and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. We did that for a while. It not only became difficult to maintain but at some point it became apparent that gtk+-2.0 just had too many bugs that could not be worked around. The current code still has some ifdefs that enable workarounds for bugs in gtk+ before version 2.2.2. We do this in order to avoid a dependency on 2.2.2 but at some point before gimp-2.0, we will have to drop these workarounds and depend on gtk+-2.2.2 or newer. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Sven Neumann [EMAIL PROTECTED] writes: and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. We did that for a while. It not only became difficult to maintain but at some point it became apparent that gtk+-2.0 just had too many bugs that could not be worked around. The current code still has some ifdefs that enable workarounds for bugs in gtk+ before version 2.2.2. We do this in order to avoid a dependency on 2.2.2 but at some point before gimp-2.0, we will have to drop these workarounds and depend on gtk+-2.2.2 or newer. sure, when woraounding old bugs became too much development time consuming, it's better to just bump the requires. what's more, the odds are high that all distributors that will ship gimp-2.0 will ship gtk+-2.2.x too ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Hi, On Sun, 2003-08-24 at 16:00, Thierry Vignaud wrote: what's more, the odds are high that all distributors that will ship gimp-2.0 will ship gtk+-2.2.x too Not only are the odds high, they don't have any other chance. On the other hand, by the time that gimp-2.0 will be ready, we will most likely see gtk+-2.4 being released. But I'd rather avoid a dependency on that version of possible. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Thierry Vignaud wrote: Raphaël Quinet [EMAIL PROTECTED] writes: The current GIMP requires GTK+ 2.2.0 and recommends 2.2.2 (this will be required by the next version). Unfortunately, many users of the distributions mentioned above are still using GTK+ 2.0.x, not 2.2.x. Besides, the majority of the users are not using the latest version of their distribution. - current debian unstable = 2.2.2 (2.2.2-3) - current mandrake cooker = 2.2.2 (2.2.2-6mdk) - current rh rawhide = 2.2.2 (gtk2-2.2.2-2.1) mdk9.2 is scheduled to be released on septembed, i do not remebed exact date for rh but it's supposed to be at the same time. debian is expected to be releasd on december. so this issue may not be a real one. It's real in so far as most linux users aren't using RedHat 9.x, Debian unstable or Mandrake 9.x - I am using Debian testing here, for example, to which I moved relatively recently from RedHat 6.2, which is still the distro available in work, where we have a binary package dependency (a database product) that isn't available in the version we use for later distros. On that work machine, building a 1.2 GIMP from scratch can be done in a day (that is, from glib up, through libjpeg, libpng and friends). Building a 1.3 CVS GIMP takes considerably longer than that. you're left to few classes of users: - those who use only distro packages: they will wait until a binary package is availlable One of the reasons that we haven't had as much testing as we'd like yet on 1.3. - those who know how ot build programs: they're supposed to know how to build dependancies and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. This is an immense simplification. There are people who want to use the new GIMP, but have had problems building some part of it. You're forgetting that the target audience of the GIMP is a user interested in graphics, not a developer. this is a valid point for: - users of very old distributions Even recent distros - GNOME 2 has only been around for a little over a year. - non developer users (that is most end users) And most people we're interested in. - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy) Setting up a build environment in windows is something of a nightmare. Windows users are also our biggest user base, I reckon. And they also find lots of bugs in the GIMP because it's used in ways that Linux doesn't even think of doing. Assuming that a system has at least some basic tools such as make and a compiler, building GIMP 1.3.x adds 27 dependencies (or 32 if you are a developer who also needs libtool, autoconf, etc.) Compare this with GIMP 1.2.x, which had only 11 dependencies (or 14 for developers.) factoring features around all tools is nice even if it's bring more dependancies. Sure - it's The Unix Way to use smaller packages to do specific jobs. The point is that each smaller package which isn't already available on the system raises the barrier for entry for GIMP building. and since other oses are either small regarding number of users or their users are expected to know how to build something (eg: those who already build gimp on solaris like you) are able to deal with a few more dependancies that are anyway needed for other programs, i think this issue can then be closed and this feature be not provided by gimp.org. I'm not sure I follow the reasoning... The point is that to get more people using, testing, contributing to and developping for the newer version of the GIMP, freely available binary packages lower the barrier. Of course we don't want to build the packages, but if volunteers do packages for a given distro, we should have one place where we link to the externally maintained binaries. It would be pretty simple to do, and would, I think, prove a great benefit to people eager to see what we've been up to for the last 3 years. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Getting Involved section on new site
Hey all, It seems like there is a lot of questions about how we should structure the Getting Involved section and I would like to make a few things clear here and also prupose a little structure. - We should use the existing file that contains the changelog updates and such things. - The image. I like it though it takes a lot of place on the site. Do the developers want it there or do you think that it might be a little to much? - IMHO I would remove the Important URLs parts and move this to Links well the once that is not in the Links section at least. - Important GIMP Development URLs is important and I would like this to stay where it is. OK here goes a little structure: - Getting Involved |-- How can I help? |-- How Tos(If we have any?) |-- What is going on '-- Links (OS specific help pages) This might be small but still it would not be much to change if we build it like this for now. This can change later also depending what the developers want the site to contain. What do the developers want the site section to look like and is there anything that I have missed above? I would like to have some discussions about this because it is important to make this section understandable and useful for new people who wants to help with GIMP. So please add comments. Best regards, -- Niklas Mattisson [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
