Re: [Gimp-developer] preparing GIMP 2.2
Hi, a while ago I posted a list here with things that should be addressed before we can start doing pre-releases for 2.2. Let's have a look at what we achieved in the meantime. Scale/Resize dialogs We definitely need to redo these. The changes to the File-New dialog and to the internal unit handling make it necessary to make at least some smaller changes to these dialogs. Tigert and Jimmac have done mockups, we should look at these mockups again and see what we can do. This still needs to be done, but it isn't really a pre-requisite for a pre-release. I might have a look at it it weekend. Text tool improvements I will try to finish some of the stuff that has been scheduled for 2.0 already, namely text transformations, perhaps text outline and text boxes. I can't promise that all of these will get done though. Well, looks like this will better be postponed further. There are too many other things that need to be done. Plug-in preview David Odin is almost done with porting all plug-ins to GimpPreviewArea but we might consider to go further and actually get GimpPreview into libgimp*. I have some ideas about this and David seems to have the time and the enthusiam to help with coding. We should definitely try to get at least closer to a full-featured preview for plug-ins. We got quite far with the previews. The API that is in CVS now seems to be OK for 2.2. We just need to add some padding to the structs and we should consider to move the private data into an internal struct using g_type_class_add_private() and g_type_instance_get_private(). Color management This has been discussed quite thoroughly but it still needs to be written down in some sort of specification and then been cut down into tasks. I've been sent some code and we've talked about this further. So there is definitely an interest in implementing this feature. I definitely think we should get this into 2.2 and I am willing to delay the release for it. Let's see if we can get something into CVS during the next week. If that fails, I suggest that we postpone it. Layer positioning/alignment Jimmac made a nice mockup for a dialog that would help with aligning layers. There's also a new plug-in in Bugzilla that deals with the same problem but I don't like it that much. This needs some discussion, shouldn't be too hard to implement then. It's IMO very important though. I still think this would be important but since we got around w/o it for so long, we might as well wait another release cycle. If someone wants to work on it, please speak up. What else is missing? There's the need for a new print plug-in but noone has volunteered yet to look at the new API and the plug-in that the gimp-print developers have prepared for GIMP 2.0. 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 the best we can do here is to ship 2.2 with Script-Fu but try to clean up the scripts so that they run with Tiny-Fu as well. We can then replace Script-Fu with Tiny-Fu in the next development cycle and interested users can already start to use it with GIMP 2.2 by installing it separately. 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. I didn't get any response whatsoever regarding Python. Makes me wonder if pygimp is still being maintained at all. I would really like to see a separate pygimp package. Can we please get this done for 2.2? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
On Friday 01 October 2004 10:46, Sven Neumann wrote: 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. I didn't get any response whatsoever regarding Python. Makes me wonder if pygimp is still being maintained at all. I would really like to see a separate pygimp package. Can we please get this done for 2.2? I've talked to Yosh about this, and he said he intend to do the move - but he seems to be quite busy lately. Jamesh also told he could not pick it alone. I had been using it, but never had seen the code until this week - I am willing to help improve and maintaining it, but I lack the time and expertize needed to maintain a separte package all by myself. Over the next week, I plan at least to clean up the tabs on the remianing python files. The widgtes should be mostly rewidgetziled, since it is currntly using String Entries for almost everything. If it cannot be taken apart for 2.2, that at least could be done. I would agree with the schdules on the other itens. If there is a delay, maybe text-transofrms could get in, but they'd need PDB-entries as well. Another thing IMHO is important, although marked as low priority in bugzilla is exposing the full options for the transform tools in the PDB - BUG 137053 ( http://bugzilla.gnome.org/show_bug.cgi?id=137053 ) That would make whole classes of plug-ins easier to write. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
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] 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] 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
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
[Gimp-developer] preparing GIMP 2.2
Hi, I think it's about time to start to discuss what features we still want to get into GIMP 2.2. We are targetting a feature freeze by the end of the month and a release shortly after, so it's probably about time... I'd like to collect a list of changes what we want to see being done for 2.2. We will need people to pick up these tasks and finish them in the next weeks. I will make a start by listing some of the things that I think would be great to finish for 2.2. Please add your wishes and/or take responsibility for some of these tasks. If you want to go into detail about a task that is listed below, please create a new thread for it so we can use this thread for collecting ideas. Scale/Resize dialogs We definitely need to redo these. The changes to the File-New dialog and to the internal unit handling make it necessary to make at least some smaller changes to these dialogs. Tigert and Jimmac have done mockups, we should look at these mockups again and see what we can do. Text tool improvements I will try to finish some of the stuff that has been scheduled for 2.0 already, namely text transformations, perhaps text outline and text boxes. I can't promise that all of these will get done though. Plug-in preview David Odin is almost done with porting all plug-ins to GimpPreviewArea but we might consider to go further and actually get GimpPreview into libgimp*. I have some ideas about this and David seems to have the time and the enthusiam to help with coding. We should definitely try to get at least closer to a full-featured preview for plug-ins. Color management This has been discussed quite thoroughly but it still needs to be written down in some sort of specification and then been cut down into tasks. Layer positioning/alignment Jimmac made a nice mockup for a dialog that would help with aligning layers. There's also a new plug-in in Bugzilla that deals with the same problem but I don't like it that much. This needs some discussion, shouldn't be too hard to implement then. It's IMO very important though. This list doesn't include tasks that have already been started but need further work (like for example the input controllers) since they aren't really affected by the feature freeze. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi Everyone, Sven Neumann wrote: Color management This has been discussed quite thoroughly but it still needs to be written down in some sort of specification and then been cut down into tasks. Here's a first attempt at a suitable specification: Colour management will bring two major benefits to The GIMP: 1.Accurate display of colours when equipped with a suitable monitor profile. 2.The ability to perform a soft-proof, whereby an image is rendered to simulate how it will look on a particular output device (usually a printing press). Implementation: The hard work is performed by LittleCMS, while the existing proof display filter can provide both of these facilities with a little modification; most of the details remaining to be finalised are interface and infrastructure related. I can provide an outline here of what needs to be done; someone with a more in-depth knowledge of GIMPs internals will have to tell us how much work this will entail: (The following assumes that were going to create some kind of global display filter for colour-matching, rather than (or as well as) the current per-image ones at the very least, such a filter will be needed for colour-correcting the colour-selectors...) * Add a new section in the preferences dialog (or add to the existing Display section) the following options: * Enable/disable colour management (Do we allow this to be enabled/disabled on a per-image basis? The filter will need access to image parasites for that.) * GimpFileEntry for working space profile (ie the source profile provided to lcms) * GimpFileEntry for monitor profile (the destination profile for lcms) * GimpFileEntry for proof profile (the profile of the device to be simulated, e.g. USWebCoatedSWOP. Implementation details: lcms has a built-in sRGB profile, which should be used as a default if the working space or monitor profile entries are left blank. If the proof profile is left blank, then the display filter will use a normal transform instead of a proofing transform. If all three are left blank, then the display filter should be disabled, since it wont have any work to do! * Update the proof display filter to allow straight Working Space - Monitor Profile transforms as well as full proofing transforms. This is a trivial modification, and I have it working here. The filter (at least the global one) needs to be able to fetch the profiles from wherever the prefs dialog stores them. If the display filter becomes able to fetch parasites from the image, then it becomes possible (easy) to disable colour management on a per-image basis, and perform other tricks like overriding the working space for the separate plugins fake composite CMYK images. Thats it as far as displaying accurate colour goes, and even if we get no further than this for 2.2, its a worthwhile start. The next step will be to write a plugin for converting between colour spaces. This is not a difficult task. A couple of questions: * Do we allow the user to convert between arbitrary profiles, or only allow the current working space as a destination? * Where in the menu structure should this live? Finally, the image loading code needs to modified. Any loaders for formats that support embedded ICC profiles should attach it (as binary) to the image as a parasite named icc-profile. The loading code will check for this parasite on the loading of an image, and allow the user to choose between converting to the working space or disabling colour-management for this image. 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 think this covers most of whats needed to make colour management a useful addition to The GIMP. Comments please, both on difficulty of implementation and any technical points that need to be discussed further. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
From: Sven Neumann [EMAIL PROTECTED] Date: 09 Aug 2004 00:10:48 +0200 I think it's about time to start to discuss what features we still want to get into GIMP 2.2. We are targetting a feature freeze by the end of the month and a release shortly after, so it's probably about time... I'd like to collect a list of changes what we want to see being done for 2.2. We will need people to pick up these tasks and finish them in the next weeks. I will make a start by listing some of the things that I think would be great to finish for 2.2. Please add your wishes and/or take responsibility for some of these tasks. If you want to go into detail about a task that is listed below, please create a new thread for it so we can use this thread for collecting ideas. 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. 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. I'll be away this week, so don't expect any replies from me until next Sunday or so. Color management This has been discussed quite thoroughly but it still needs to be written down in some sort of specification and then been cut down into tasks. Please copy [EMAIL PROTECTED] on appropriate discussion on this topic. -- 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] preparing GIMP 2.2
Sven Neumann wrote: 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? -- 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
* Add a new section in the preferences dialog (or add to the existing Display section) the following options: * Enable/disable colour management (Do we allow this to be enabled/disabled on a per-image basis? The filter will need access to image parasites for that.) 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? On second thought, I can think of a reason to disable color management, but I still think that it wouldn't be a bad idea to just make this monitor's colorspace one of the options. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
