Re: [Gimp-developer] preparing GIMP 2.2
Am 10.09.04, 00:41 +0100 schrieb Alastair M. Robinson: ... A special case will be the TIFF plugin TIFFs can contain embedded profiles for a CMYK colour space; ideally the TIFF plugin itself will use lcms to convert the raw CMYK data to the RGB Working Space. I had this code inside the tiff reader, but stripped it out now, because CinePaints internal color management can handle CMYK natively. Anyway if You like to look into the old tiff code, let me know and I will send it to anyone interessted. kind regards Kai-Uwe Behrmann + imaging developer / panoramas + color management + email :[EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] starts with 0 or 1?
On Sunday 08 August 2004 10:17 pm, Simon Budig wrote: ordinal numbers start at 1 1 is no ordinal number, you most likely mean 1st? Whether you assume 0 or 1 being the 1st natural number is only a matter of convention and convenience (depending on the subject matter). Most people start to count from 1, so it makes sense to use 1 as label for the 1st object, but it is nevertheless arbitrary, as one could for example also have used the labelling a, b, c, ..., with a denoting the 1st object etc. Hence the number 0 in the ancient version of the IFS Compose plugin was a bug and has been corrected for the Version 1.2. One of the advantages of the current style is that the object with label n is the n-th object (I personally have no idea if the order of the objects actually matters in the case of IfsCompose, from what I see: if at all, not much). The previous mapping was not exactly a bug, but less convenient with respect to this. Markus. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] programming classes with gimp
I was thinking it would be cool if their were classes that people did gimp development in, and gained experience that way. Any thoughts?
Re: [Gimp-developer] programming classes with gimp
Hi Steve, Quoting Steve Siverling [EMAIL PROTECTED]: I was thinking it would be cool if their were classes that people did gimp development in, and gained experience that way. Any thoughts? Sure, that would be great. Do you have any specific suggestions about how that would work? Usually things like that happen without our knowledge, but it would be cool to have us in the know. If someone asked for people to give a course for a specific reason, I'm sure that someone around here would be able to help out... Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] upadting the print plug-in [was: preparing GIMP 2.2]
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: Gimp-Print 5.0 isn't going to be in final release at that point, but it should be at beta-2 by then, and we've been putting a lot of bug fixes into our tree. I don't think it's as stable as 4.2 yet, but it's not far shy. We should be completely API-frozen at that point. We need to work out handoff of the plugin, as discussed. Yep, sorry that I forgot to mention the print plug-in yesterday. The only API change we're looking at right now is adding dimension-valued parameters. These are like numerical parameters, except that programs should present them in the appropriate units, such as inches, mm, points, furlongs, or whatnot. The short-term reason for this is to allow precise registration of CD's. We could either make the change and then hand it off, or we could hand it off and you could make the change. Since the only real implication of this is for the UI, and it sounds like you're going to overhaul the UI, perhaps we should hand it off first. GIMP has all this already, why would you want to deal with units in a library such as gimp-print? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi, David Hodson [EMAIL PROTECTED] writes: I think it's about time to start to discuss what features we still want to get into GIMP 2.2. Something that I'd like to see (if it hasn't been done yet) is to make the popup progress dialog dockable. How feasible is that? Well, we don't want to make it dockable, it should be embedded in the associated dialog. Yes, that should definitely be on the list for 2.2. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] upadting the print plug-in [was: preparing GIMP 2.2]
From: Sven Neumann [EMAIL PROTECTED] Date: 09 Aug 2004 11:15:38 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: The only API change we're looking at right now is adding dimension-valued parameters. These are like numerical parameters, except that programs should present them in the appropriate units, such as inches, mm, points, furlongs, or whatnot. The short-term reason for this is to allow precise registration of CD's. We could either make the change and then hand it off, or we could hand it off and you could make the change. Since the only real implication of this is for the UI, and it sounds like you're going to overhaul the UI, perhaps we should hand it off first. GIMP has all this already, why would you want to deal with units in a library such as gimp-print? Two reasons: 1) Gimp-Print covers more than just the GIMP -- there's also the CUPS driver, the Ghostscript IJS driver, and Foomatic, in addition to a few third party apps. 2) The dimension type tells the user interface to treat this parameter specially (display it in units of the user's choice). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] upadting the print plug-in [was: preparing GIMP 2.2]
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: GIMP has all this already, why would you want to deal with units in a library such as gimp-print? Two reasons: 1) Gimp-Print covers more than just the GIMP -- there's also the CUPS driver, the Ghostscript IJS driver, and Foomatic, in addition to a few third party apps. I suggest to leave it up to the application that uses gimp-print then. Any application that uses units in it's user interface will have a framework to deal with units. If you add your own framework to gimp-print you are only making things more complex. 2) The dimension type tells the user interface to treat this parameter specially (display it in units of the user's choice). Any length parameter in GIMP is measured in pixels and if there's resolution information, the user is given the opportunity to use arbitrary units to specify it. The underlying code still sees nothing but pixels. I don't see why the underlying code (in this case gimp-print) would have to know about this. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Sven, Something that I'd like to see (if it hasn't been done yet) is to make the popup progress dialog dockable. How feasible is that? Well, we don't want to make it dockable, it should be embedded in the associated dialog. Yes, that should definitely be on the list for 2.2. What if there's no associated dialog? I have some plugins that call (lots of) Gimp functions non-interactively, with no image display. The result is that the progress dialog is constantly being created and destroyed. Things would be much neater if it was (optionally?) just part of the main toolbox window. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: GIMP 2.0 User Manual -- developer snapshot
Hi all, a new snapshot of the newly written GIMP 2.0 User Manual is available from: ftp://ftp.gimp.org/pub/gimp/help/testing/gimp-help-2-0.4.tar.gz and includes major improvements for the four current available languages, which are: English, French, Swedish and German. This developer snapshot is basically for soliciting new contributors, who will assist us in writing and correcting errors. Check out the project page on the GIMP Wiki at: http://wiki.gimp.org/gimp/GimpDocs The Manual itself is written in XML and Docbook. For new doc-writers, knowledge of XML and Docbook is helpful, but not required. We're also looking for proof readers. A mostly up-to-date CVS version of the manual can be found at: http://docs.gimp.org/ Thanks to all who made this snapshot possible. Happy writing and testing, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] preparing GIMP 2.2
Nathan Carl Summers wrote: I can't honestly think of a good reason to disable color management, but couldn't we just have an option for this monitor's colorspace instead of having two choice to choose from? The first time I tried to use PhotoShop with color management, I was totally bewildered: it was asking me all these questions about color conversions, and I had no idea what they meant or how to answer them. A significant part of my bad attitude toward PhotoShop comes from that experience. I think it is important for new users to be able to make color management *just go away* until they know what it means and are ready to deal with it. Gimp is a hard enough program to learn as it is. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
On Mon, Aug 09, 2004 at 09:29:46AM -0700, William Skaggs wrote: Nathan Carl Summers wrote: I can't honestly think of a good reason to disable color management, but couldn't we just have an option for this monitor's colorspace instead of having two choice to choose from? The first time I tried to use PhotoShop with color management, I was totally bewildered: it was asking me all these questions about color conversions, and I had no idea what they meant or how to answer them. A significant part of my bad attitude toward PhotoShop comes from that experience. I think it is important for new users to be able to make color management *just go away* until they know what it means and are ready to deal with it. Gimp is a hard enough program to learn as it is. and then there are those of us who simply do not believe in it. i actually believe more in Santa Claus than i do in anyones ability to make a monitor match a print. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
I would argue that non interactive plugins (or interactive plugin run in non interactive mode, which I presume to be the same thing), should not bring up any progress bars. -Joseph Sven Neumann wrote: Hi, David Hodson [EMAIL PROTECTED] writes: What if there's no associated dialog? I have some plugins that call (lots of) Gimp functions non-interactively, with no image display. The result is that the progress dialog is constantly being created and destroyed. Things would be much neater if it was (optionally?) just part of the main toolbox window. The progress bar should then be part of the plug-in dialog that calls these functions. I don't think having the progress in the toolbox window is a good idea. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Joseph Heled wrote: I would argue that non interactive plugins (or interactive plugin run in non interactive mode, which I presume to be the same thing), should not bring up any progress bars. You would argue incorrectly, then. Even if a plugin is noninteractive, bad things usually happen if you alter the image it is working on before it is finished. Therefore, you need to know whether the plugin is running, and it is nice to get some sense of how much longer it is going to take. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi, Joseph Heled [EMAIL PROTECTED] writes: I would argue that non interactive plugins (or interactive plugin run in non interactive mode, which I presume to be the same thing), should not bring up any progress bars. No, that would be wrong. Non-interactive means that there's no user interaction, it doesn't mean that there's absolutely no feedback such as a progress bar. Some plug-ins used to behave the way you argue and we have hopefully found and changed them all to do the right thing which is to always indicate progress. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi, one or two things for GIMP 2.2 that I forgot: Script-Fu vs. Tiny-Fu We should come to a conclusion whether and how Tiny-Fu can replace Script-Fu. I'd suggest we make separate packages gimp-script-fu and gimp-tiny-fu and remove Script-Fu from the gimp tree. Python bindings IMO we should move pygimp out of the gimp tree into a gimp-python package. That would make it easier to give it a proper python-like build environment and would make it easier for packagers. Yosh also had some great plans on improving pygimp. Would probably be a good idea to make these improvements independent of the GIMP release cycles. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2 (fwd)
Forwarding to the list in case others are interested relevant to bug report http://bugzilla.gnome.org/show_bug.cgi?id=145145 plan: moving patterns from Toolbox to the current image -- Forwarded message -- Date: Mon, 9 Aug 2004 18:52:24 +0100 (BST) From: Alan Horkan [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED] Subject: Re: [Gimp-developer] preparing GIMP 2.2 Status on my pattern changes, in case you are wondering This list doesn't include tasks that have already been started but I have most of the patterns done. Now most of them also work off the current selection if there is one. Problems. I started this work based on Gimp 1.2.x scripts (I presumed the changes would minor and would likely be rejected so I did what was best for my own purposes at the time) and as a result I have had difficulties forward porting Truchoid. I could probably redo my changes staring againts the 2.0 version but it will be a real pain and this will likely delay me significantly. I have also rewritten Swirly to be between 3-4 orders of magnitude faster. I made it work off the current image too but it adds a new layer containing a square to the current image and I have not sorted out tiling it to the current image yet. I'll try and get more done this week, with any luck I'll get my head around Swirly and only have Truchoid left to do. Either way I'll post most or all of what I have on my site later in the week and file additional bug reports for the ones that are finshed. I have spent a lot of time but I have other work I really should be doing and I am not confident I'll be able to spare enough time to get them all done in time for 2.2 but I'd be very dissapointed to have my work left out. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi, Sven Neumann wrote: No, that would be wrong. Non-interactive means that there's no user interaction, it doesn't mean that there's absolutely no feedback such as a progress bar. Some plug-ins used to behave the way you argue and we have hopefully found and changed them all to do the right thing which is to always indicate progress. How does gimp-console handle plug-ins then? I assume it doesn't bring up progress curses windows... Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi, Sven Neumann wrote: one or two things for GIMP 2.2 that I forgot: Script-Fu vs. Tiny-Fu We should come to a conclusion whether and how Tiny-Fu can replace Script-Fu. I'd suggest we make separate packages gimp-script-fu and gimp-tiny-fu and remove Script-Fu from the gimp tree. I think we could include both in the standard distribution, making tiny-fu the default and having script-fu as a fall-back. Despite all the testing it has had so far, it's inevitable that tiny-fu will have some teething problems when it gains very wide exposure in a stable GIMP. Python bindings IMO we should move pygimp out of the gimp tree into a gimp-python package. That would make it easier to give it a proper python-like build environment and would make it easier for packagers. Yosh also had some great plans on improving pygimp. Would probably be a good idea to make these improvements independent of the GIMP release cycles. Given that this has happened for gimp-perl already, I can see the logic in that. Who is maintaining gimp-python right now, by the way? yosh? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi, David Neary [EMAIL PROTECTED] writes: How does gimp-console handle plug-ins then? I assume it doesn't bring up progress curses windows... The progress API is implemented as part of the GUI vtable of the Gimp object (http://developer.gimp.org/api/2.0/app/app-Gimp-gui.html). gimp-console (or gimp -i) simply doesn't populate this vtable so nothing happens. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Sven Neumann wrote: The progress bar should then be part of the plug-in dialog that calls these functions. OK, of course, should have seen that. Gotcha. (I'm sick today, so my brain isn't working properly.) -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Joseph Heled wrote: I would argue that non interactive plugins (or interactive plugin run in non interactive mode, which I presume to be the same thing), should not bring up any progress bars. In my case, I have a batch processing plugin that sets up a sequence of operations interactively, then performs them on a collection of images. So my plugin UI is available to display the progress from each operation, as long as I can grab the progress callbacks from the gimp functions that I'm calling. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
