Re: [Gegl-developer] Re: [Gimp-developer] GEGL development/gimp integration
Hi Sven, Selon Sven Neumann [EMAIL PROTECTED]: Hal V. Engel [EMAIL PROTECTED] writes: it appeared to me that this approach had been rejected, or at least discredited, at that time. At the very least there were sound reasons put forward that called this approach into question and the only arguments on the other side were that it made programming the color management stuff a little easier. But I am also aware that there were many involved in the earlier thread on this subject that did not seem to think there was an issue with this approach. I don't think we rejected this part. IIRC we said that it should be optional and that we want to allow people to disable color management entirely. Anyway, whatever we decide to do is just a matter of user interface and doesn't affect the GEGL operators involved. The short summary of the entire discussion is something like this: We should allow a colour profile to be associated with an image if possible, and only apply it (that is, change the colorspace of an image) if explicitly requested. There will be issues with things which aren't colorspace dependent (like the color picker) as well as copying and pasting between images, which will cause problems, but for the moment the damage caused by these would be less than applying color profiles on load. However, we should have a default working colourspace, and the user should be able to convert to that colourspace on load. This should be configurable. There should also be an option to disable colour management altogether - in which case, we work in the default colourspace, don't do any conversion at all, and simply load and save the colour profile as a parasite attached to the image. My understanding was that the solution which Alastair Robinson was working on was to have a plug-in to apply a color profile, but also to have the idea of a (per-image) working colourspace, and a configurable (global) display colour profile and default working colourspace. That is, every image loaded which doesn't have an attached profile will be assumed to be in that default colourspace. If it has an attached profile, the user will be offered the choice of (1) applying the profile to get to the default colorspace, (2) working in the embedded profile's colorspace or (3) disabling color management for the image, in which case we work in the default colorspace, but don't apply the profile. Again, this is a synthesis of my understanding of that discussion, the archives are the best reference for what was said, though. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Hi, Sven Neumann wrote: Putting the tarballs somewhere close to the GIMP tarball on the FTP server is of course reasonable. But unless I completely misunderstood you earlier, you proposed to include gegl as a virtual CVS module and to include it in the GIMP tarball. That's what we've been discussing here. It was an idea. The original idea I had was exactly what you said. Given that was so problematic, I modified the idea. Perhaps I should have signposted the change :) 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
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Hi, Sven Neumann wrote: What is wrong about depending on GEGL and have people download and compile it separately? GTK+ used to live in the GIMP source tree for historical reasons only. I strongly doubt anyone would have wanted to move it into the GIMP source tree if it was started as a separate project. Why would you want to do this with GEGL now? What's wrong with having gegl sources to download with the latest release on the FTP server, the same way we used to have libaa, libmpg, libpng and all the other stuff we needed? Up until 1.2.x, we used to have gtk+ and glib sources with gimp sources. What was wrong with that? Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Manish Singh wrote: On Mon, Dec 22, 2003 at 06:15:17PM +0100, David Neary wrote: The point is that as it is, gegl is not a standalone project. But it *is* a standalone project. That's been the intent from the beginning. I don't see how incubation helps it in any way. There are people who have indicated wanting to use it for other projects besides GIMP already. OK - fair enough. It's a standalone project. But we're going to use it, and need it, and from what I recall, calvin was looking for more GIMP input into what it should do. How do you propose we get that kind of communication happenning? GTK+ was distributed as part of GIMP until people found out that hey, this is a useful general purpose toolkit. We already know that with GEGL. There weren't any notable positive benefits with keeping GTK+ as part of the GIMP tree. Except that until people noticed that it was a useful general purpose toolkit, it kept getting worked on, with a particular application in mind... I think that being part of the GIMP was enormously beneficial to gtk+. There isn't any point. The problem with dependencies most people have is not downloading and installing tarballs, but rather the mess that is Freetype library incompatibilites and by extension any of the things that directly depend on it. GEGL doesn't depend on any external library GIMP doesn't already need. I'm afraid I didn't follow the logic of this... how is this a counter-argument to having gegl and gimp downloads in the same directory? Note, I'm no longer advocating shipping gegl as part of the GIMP sources - although I see no reason not to do that personally, I can see that most people are against it and don't consider it the thing to do (that said, only 3 people have replied with a preference). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
On Tue, Dec 23, 2003 at 09:35:09AM +0100, Dave Neary wrote: Manish Singh wrote: On Mon, Dec 22, 2003 at 06:15:17PM +0100, David Neary wrote: The point is that as it is, gegl is not a standalone project. But it *is* a standalone project. That's been the intent from the beginning. I don't see how incubation helps it in any way. There are people who have indicated wanting to use it for other projects besides GIMP already. OK - fair enough. It's a standalone project. But we're going to use it, and need it, and from what I recall, calvin was looking for more GIMP input into what it should do. How do you propose we get that kind of communication happenning? Not sure. Something to think about more post-2.0. GTK+ was distributed as part of GIMP until people found out that hey, this is a useful general purpose toolkit. We already know that with GEGL. There weren't any notable positive benefits with keeping GTK+ as part of the GIMP tree. Except that until people noticed that it was a useful general purpose toolkit, it kept getting worked on, with a particular application in mind... I think that being part of the GIMP was enormously beneficial to gtk+. The beneficial part was having GIMP use GTK+. Period. Having it part of the actual source tree didn't really contribute to that benefit much at all, since it would've gotten worked on regardless. In fact, it was a minor hindrance, since GIMP specific stuff like GtkGamma got stuck in the general purpose library, and now the GTK+ folk have to maintain it when it doesn't actually belong. There isn't any point. The problem with dependencies most people have is not downloading and installing tarballs, but rather the mess that is Freetype library incompatibilites and by extension any of the things that directly depend on it. GEGL doesn't depend on any external library GIMP doesn't already need. I'm afraid I didn't follow the logic of this... how is this a counter-argument to having gegl and gimp downloads in the same directory? Note, I'm no longer advocating shipping gegl as part of the GIMP sources - although I see no reason not to do that personally, I can see that most people are against it and don't consider it the thing to do (that said, only 3 people have replied with a preference). You didn't propose having gegl and gimp downloads in the same directory till today. So I don't follow the logic. ;) I don't really mind symlinking the gegl sources into the gimp ftp dir, but that's a fairly minor thing. Most people follow webpage links rather than poking through an ftp site these days, and the download webpage should of course link to gegl. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
On Tue, Dec 23, 2003 at 09:27:17AM +0100, Dave Neary wrote: Hi, Sven Neumann wrote: What is wrong about depending on GEGL and have people download and compile it separately? GTK+ used to live in the GIMP source tree for historical reasons only. I strongly doubt anyone would have wanted to move it into the GIMP source tree if it was started as a separate project. Why would you want to do this with GEGL now? What's wrong with having gegl sources to download with the latest release on the FTP server, the same way we used to have libaa, libmpg, libpng and all the other stuff we needed? Up until 1.2.x, we used to have gtk+ and glib sources with gimp sources. What was wrong with that? Actually, as far as I can recall, the gtk+ and gimp sources were not in the same directory since before 1.0.0. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Manish Singh wrote: On Tue, Dec 23, 2003 at 09:35:09AM +0100, Dave Neary wrote: OK - fair enough. It's a standalone project. But we're going to use it, and need it, and from what I recall, calvin was looking for more GIMP input into what it should do. How do you propose we get that kind of communication happenning? Not sure. Something to think about more post-2.0. We could think about it now, and do something about it post 2.0 :) That's all I am doing is throwing ideas around. The beneficial part was having GIMP use GTK+. Period. Having it part of the actual source tree didn't really contribute to that benefit much at all, since it would've gotten worked on regardless. So having the GIMP use gegl will be beneficial to gegl :) In any case, that is not the goal of the 2.2 release. I still believe that always stable, always releasable, with a 6 week freeze on functionality and a release for GUADEC are the technical goals of the 2.1.x series. If we start using tiny bits of gegl, then that's great. I'm afraid I didn't follow the logic of this... how is this a counter-argument to having gegl and gimp downloads in the same directory? You didn't propose having gegl and gimp downloads in the same directory till today. So I don't follow the logic. ;) The post you replied to immediately before this one talked about having the tarballs together. I posted that yesterday. I don't really mind symlinking the gegl sources into the gimp ftp dir, but that's a fairly minor thing. Most people follow webpage links rather than poking through an ftp site these days, and the download webpage should of course link to gegl. I agree. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Hi, Dave Neary [EMAIL PROTECTED] writes: What is wrong about depending on GEGL and have people download and compile it separately? GTK+ used to live in the GIMP source tree for historical reasons only. I strongly doubt anyone would have wanted to move it into the GIMP source tree if it was started as a separate project. Why would you want to do this with GEGL now? What's wrong with having gegl sources to download with the latest release on the FTP server, the same way we used to have libaa, libmpg, libpng and all the other stuff we needed? Up until 1.2.x, we used to have gtk+ and glib sources with gimp sources. What was wrong with that? Putting the tarballs somewhere close to the GIMP tarball on the FTP server is of course reasonable. But unless I completely misunderstood you earlier, you proposed to include gegl as a virtual CVS module and to include it in the GIMP tarball. That's what we've been discussing here. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Hi, Sven Neumann wrote: Because I believe that it will hurt the project to become part of the GIMP tarballs. It will be much more helpful if we help to create standalone GEGL releases early. This will raise interest in GEGL and it will make packages appear for all distributions. Since neither of us are currently involved in gegl development, I was hoping that we might get some opinions from the people who are. But given that the conversation has started as a sort of argument, I'm not sure whether anyone else will get involved now. I hope so. Moving it into the GIMP tarball is like moving GTK+ back into the GIMP tree just because we need some functionality out of the HEAD branch. Not at all. GTK+ lived in the GIMP source tree until it was capable of being a standalone project. Afterwards, its main developers were gimp developers. Unfortunately, several of them followed the path which GTK+ has become to go on to be core GNOME developers and no longer work on the GIMP. The point is that as it is, gegl is not a standalone project. It doesn't seem to me like it is mature enough that if the GIMP went under (say a few more people quit), gegl would not go on to be a standalone graphics library in the way that gtk+ went on to be a standalone toolkit. During the incubation of the project, it needs attention from us in the same way as gtk+ got attention pre-1.0. Looked at this way, leaving gegl standalone is more like developing gtk+ as a standalone project, and saying that we would use it when it were ready, while continuing to develop the 0.99 series with motif. GEGL is a separate project and it is IMO very important that it doesn't become too GIMP-centric. Having it included in the GIMP tarball will make it appear as part of The GIMP which it isn't supposed to be. What you suggest basically has only disadvantages. Let alone the fact that it will be a nightmare to maintain. I'm not suggesting maintenance. I'm suggesting including milestone releases of gegl in our sources. Or storing them with our release tarballs. Either is good. Basically, releasing them together. Early. Before we use the functionality. So that they get built, and people are aware that gegl is real software, not a mission statement from 3 years ago. I'd like to see this done hand-in-hand with a configure check for gegl, so that we actually do get people downloading and building it. And gegl is, at this moment, a gimp utility library. It may not stay that way. I would expect that cinepaint might like to migrate their core to gegl at some stage, if it becomes the killer graphics motor it aspires to be. Perhaps some mini-gimps, or specialised graphing applications, will use it. But being associated with the GIMP is not a disadvantage for a toolkit or utility library. Look at gtk+ and gimp-print. 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
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Hi, What is wrong about depending on GEGL and have people download and compile it separately? GTK+ used to live in the GIMP source tree for historical reasons only. I strongly doubt anyone would have wanted to move it into the GIMP source tree if it was started as a separate project. Why would you want to do this with GEGL now? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
On Mon, Dec 22, 2003 at 06:15:17PM +0100, David Neary wrote: Not at all. GTK+ lived in the GIMP source tree until it was capable of being a standalone project. Afterwards, its main developers were gimp developers. Unfortunately, several of them followed the path which GTK+ has become to go on to be core GNOME developers and no longer work on the GIMP. The point is that as it is, gegl is not a standalone project. It doesn't seem to me like it is mature enough that if the GIMP went under (say a few more people quit), gegl would not go on to be a standalone graphics library in the way that gtk+ went on to be a standalone toolkit. During the incubation of the project, it needs attention from us in the same way as gtk+ got attention pre-1.0. But it *is* a standalone project. That's been the intent from the beginning. I don't see how incubation helps it in any way. There are people who have indicated wanting to use it for other projects besides GIMP already. GTK+ was distributed as part of GIMP until people found out that hey, this is a useful general purpose toolkit. We already know that with GEGL. There weren't any notable positive benefits with keeping GTK+ as part of the GIMP tree. GEGL is a separate project and it is IMO very important that it doesn't become too GIMP-centric. Having it included in the GIMP tarball will make it appear as part of The GIMP which it isn't supposed to be. What you suggest basically has only disadvantages. Let alone the fact that it will be a nightmare to maintain. I'm not suggesting maintenance. I'm suggesting including milestone releases of gegl in our sources. Or storing them with our release tarballs. Either is good. Basically, releasing them together. Early. Before we use the functionality. So that they get built, and people are aware that gegl is real software, not a mission statement from 3 years ago. I'd like to see this done hand-in-hand with a configure check for gegl, so that we actually do get people downloading and building it. There isn't any point. The problem with dependencies most people have is not downloading and installing tarballs, but rather the mess that is Freetype library incompatibilites and by extension any of the things that directly depend on it. GEGL doesn't depend on any external library GIMP doesn't already need. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
