Re: [Gimp-developer] metadata and JPEG - plans and current status
On Wed, 23 Jul 2008 11:20:41 +0200, Roman Joost [EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 04:50:41PM +0200, Raphaël Quinet wrote: [...] Currently, the metadata tree is only available inside the metadata editor, which is implemented as a plug-in. This results in several round-trips via the PDB whenever something must be updated. [...] In my unexperienced point of view, it looks like this should be clarified first, before I try to improve the current metadata editor. IMHO your last point seems to be the way to go, all other attempts like the first one seems to be totally inefficient and error-prune. Yes, this is also my point of view. The best way to go is to have the metadata tree available in the core with some PDB calls allowing plug-ins to get/set data, and also have a libgimp-metadata library that can be used by the file plug-ins for performing tasks such as converting between Exif and XMP. The editor itself could still be a plug-in, but the lower-level parts of metadata handling would be included in the library and another part of it would be in the GIMP core. To recap, the three scenarios are: 1) metadata editor/viewer + metadata format converter + storage are all done by a plug-in (current situation); 2) metadata editor/viewer + metadata format converter done by a plug-in, but storage handled in GIMP core; 3) metadata editor/viewer done by a plug-in, metadata format conversions in a GIMP metadata library, and storage handled in GIMP core. In the longer term, we can also think about a scenario 4 in which parts of the metadata viewer/editor could be handled by the core, but that is not for the short term anyway. Although I think that it makes a lot of sense to have the metadata tree inside the core as in scenario 3, Sven seems to disagree so I would like to have his opinion before deciding how to proceed. So contrary to what I originally planned, I think that the code for converting to/from Exif should be based on that library. This will also make our code smaller and easier to maintain. My current plan was to provide a read-only view of the currently stored metadata inkl. a button to update the view. This included the conversion from Exif to XMP. Currently from my point of view - correct me if I'm wrong - the conversation will be called from the imagefile plugin (e.g. jpeg-load), after the Exif data is attached as a parasite. The metadata exif-decode procedure will convert the Exif data to XMP than, to be able to display it as XMP data in the metadata browser. I think that you got it right. :-) In scenario 1 above, when a file is loaded the Exif block should be converted to XMP immediately (or more precisely, it should be converted to a metadata tree, which happens to be serialized as XMP) and then the metadata parasite is attached to the image. Later, when the user starts the metadata editor or viewer, the parasite is retrieved from the image and decoded into a metadata tree that can be displayed to the user. Note that in scenarios 2 and 3, it would not be necessary to convert the metadata tree into XMP and store it in a parasite, because that tree would be managed by the core. The metadata viewer would only have to retrieve the relevant elements for display or editing. In fact, in scenarios 2 and 3 the metadata viewer/editor would not have to care about the XMP syntax: it would only need to know the name and data type of the things that it wants to display. Now after the pros and cons about handling metadata is clarified by your mail, how different do we set our priorities to move forward for this editor and the metadata management? I think we should setup a roadmap first, setup tasks afterwards and start implementing them. Well, the thing that could change the plans significantly is a decision about whether or not we integrate the metadata tree inside the core. And I would like to get Sven's comments about that. If we start with scenario 2 (for example), then it should not be too hard to switch to scenario 3 later. However, if we start with 1, then it is not easy to migrate to 2 or 3 later. Most of the new code would have to be rewritten differently. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] metadata and JPEG - plans and current status
Since Roman has offered to improve the metadata handling in GIMP, Sven asked me to document what my plans were for the metadata editor and the JPEG plug-in. Well, these plans are best summarized in the mail that I sent last year: http://lists.xcf.berkeley.edu/lists/gimp-developer/2007-November/018992.html http://article.gmane.org/gmane.comp.video.gimp.devel/12503/ Basically, every single line of that message is still relevant today. So I will not quote the whole message again, but I encourage those who are interested in metadata to read it entirely. This follow-up message may also be interesting, regarding which Exif tags should be updated automatically by GIMP and why GIMP should never ask the user if an image should be rotated automatically or not: http://lists.xcf.berkeley.edu/lists/gimp-developer/2007-November/019100.html http://article.gmane.org/gmane.comp.video.gimp.devel/12610/ That's about it for the plans. You should stop reading now if you are not interested in the details. :-) -- scary details below this line -- Maybe a few points from the first message (2.6 roadmap) should be clarified a bit. In that message, I wrote: + migrate some parts of the metadata core to a library that can be used by the main app. as well as some plug-ins Currently, the metadata is stored in an XMP packet inside a GIMP parasite attached to the image. While XMP is a good format for storage in files, it is not ideal for manipulation (updates and queries). It would be better it the metadata tree could remain in memory while the image is open, instead of being converted to/from XMP all the time. Also, by having this tree attached to the image and accessible directly by the core for updates and queries, it would be possible to have the metadata updated in real-time whenever the image is modified by some tools or plug-ins. This would allow some of the metadata to be displayed in the image info window, or maybe in the status bar of the image (more and more programs are doing that). Currently, the metadata tree is only available inside the metadata editor, which is implemented as a plug-in. This results in several round-trips via the PDB whenever something must be updated. For example, assuming that Exif would now be handled correctly, the current implementation would lead to the following scenario when a JPEG image is saved: - the JPEG plug-in calls plug-in-metadata-set to update some metadata - this is passed to GIMP - GIMP starts the metadata editor plug-in - the metadata editor asks GIMP to get the parasite attached to the image - the parasite (XMP) is parsed and stored in a tree - the tree is updated according to what was requested - the tree is encoded into a parasite (XMP) - the metadata editor asks GIMP to attach the parasite to the image, then it exits - (if there is some window currently displaying the metadata associated with that image, it is *not* updated) - the JPEG plug-in is informed that the operation was successful - the JPEG plug-in calls plug-in-metadata-encode-exif in order to get an Exif block from the updated metadata - this is passed to GIMP - GIMP starts the metadata editor plug-in again - the metadata editor asks GIMP to get the parasite attached to the image - the parasite (XMP) is parsed and stored in a tree - the metadata editor updates some metadata that must be updated when an image is saved - the updated tree is encoded into a parasite (XMP) - the metadata editor asks GIMP to attach the updated parasite - (if there is some window currently displaying the metadata associated with that image, it is *not* updated) - the contents of the tree are encoded in Exif - the metadata editor returns an array with the Exif block and exits - GIMP returns the array to the JPEG plug-in - the JPEG plug-in can now save the file with the Exif block, then exit - (if there is some window currently displaying the metadata associated with that image, the user must remember to refresh the view) And here is what would happen if the metadata tree could be managed by the GIMP core, but we still assume that the conversion to/from Exif is done by an external plug-in: - the JPEG plug-in calls gimp-metadata-set to update some metadata - this is passed to GIMP, which updates the metadata attached to the image - (if there is some window currently displaying the metadata associated with that image, it *will be* updated) - the JPEG plug-in is informed that the operation was successful - the JPEG plug-in calls gimp-metadata-encode-exif in order to get an Exif block from the updated metadata - GIMP updates some metadata that must be updated when an image is saved - (if there is some window currently displaying the metadata associated with that image, it *will be* updated) - GIMP starts the metadata editor plug-in - the metadata editor makes several calls to gimp-metadata-get in order to retrieve the parts of the metadata that are relevant for Exif - GIMP
Re: [Gimp-developer] Enhancement request - Use alpha channel for non-transparent information
On Sun, 20 Jul 2008 21:22:11 +1000, Snake Arsenic [EMAIL PROTECTED] wrote: Okay I made a feature request at http://bugzilla.gnome.org/show_bug.cgi?id=543810 but it's missing a solution that will not remove any functionality. [...] I think that it would be a big mistake to use the alpha channel for anything else than transparency. I assume that you are asking for this because you have some program (I don't know which one) that is incorrectly using the alpha channel to store bump map information or something else that is not related to transparency. It is likely that this program doesn't use a file format that supports layers or independent channels, so its authors of have decided to hijack the alpha channel in some existing file format. The correct way to solve this problem is to use layers instead of abusing the alpha channel (or maybe additional channels, but I think that using layers would be more convenient in this case). With layers, it is very easy to toggle the visibility of the image or the bump map layer, specular map layer or whatever else you are working on. So instead of extending the mistakes done by the authors of some other software, it would be much better to know what file format has been subverted, and to perform the conversion in the file plug-in: * When the plug-in loads a file that uses this strange format, it would convert the alpha channel into a layer and mark that layer (using a special name like the GIF plug-in does for animations, because that can be edited easily by the user if necessary). * You would then be free to edit the image in GIMP and modify the layer containing what should be visible or the layer containing the bump map. * When saving the file, the plug-in would detect that some layers have a special name and would then combine these layers in a way that can be read by whatever other program you are using. So I suggest that you: 1) Identify what file formats need some special treatment. 2) Check if there is a way to detect what files using that format are special, so that we do not have to ask the user every time if a file using that file format should be read in the intended way (alpha channel = transparency) or in the non-standard way (bump map). 3) Suggest improvements to the corresponding file plug-ins, instead of requesting major changes in the GIMP core. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP metadata plug-in
On Fri, 18 Jul 2008 19:04:47 +0400, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 12:52 PM, Roman Joost wrote: Is there anyone who can give me valuable pointers? I try to come up with something usable ... Raphael Quinet is the last guy who worked on it I already offered my help to Roman via IRC and we discussed how to proceed. Sorry for not mentioning it here. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improved drawing modes
On Fri, 22 Feb 2008 10:17:26 +0100, Radoslav Schudich [EMAIL PROTECTED] wrote: the available drawing modes should have these options too (there are plenty (21) drawing modes, but I definitly miss these: ERASE (to be able to erase the drawing (not just one color) with any drawing NEGATIVE -it makes the drawing/editing easier, because when you want to erase something, you do not need to change your tool 2 eraser, but can choose to erase the painting with the brush you currently have. Could you explain why it would be easier to do this with additional drawing modes instead of using the existing shortcuts to switch to the eraser and then switch back to your previous drawing tool? If you use the existing shortcuts for the tools or if you define new ones, then you only need to press the key for the eraser, erase what you want, and then press the key for the other paint tool to continue drawing. You can do that without having to move the mouse to the tool options and change the paint mode, which is more cumbersome in my opinion. Also, for those who use a drawing tablet, it is much easier to switch tools than to play with drawing modes. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cleaning up GIMP versions in Bugzilla
On Wed, 19 Dec 2007 10:05:46 +0100, Michael Schumacher [EMAIL PROTECTED] wrote: Von: Sven Neumann [EMAIL PROTECTED] We should clean this up, now that 2.4 is out. It would be nice to combine all 2.2 bugs to version 2.2.x and all 2.3 bugs to version 2.3.x. What about the 2.4-rcX ones? We do not accept bugs for them, so they shouldn't be there, and should also be included in the cleanup. Unfortunately, several stable Linux distributions are currently including 2.4-rc3 (Fedora, Ubuntu and many derivatives) or 2.4-rc2 (Mandriva). It is likely that we will still get many bug reports for these versions in the next six months. If we simply remove 2.4-rc3 from the list of available versions, it is likely that the users will incorrectly assign the bugs to 2.4.0 or 2.4.3 instead of reporting the bug against their distribution. So I suggest that we keep the 2.4-rcX releases until the middle of next year, or at least 2.4-rc3. Removing it too early would just result in having more bugs assigned to the wrong version and we would not even see that we should reject these bugs. According to distrowatch, the following distributions include 2.4.0rc3: • Absolute Linux: 12.0.7 • Ankur Bangla: 7.10 • Edubuntu: 7.10 • Fedora: 8 • Geubuntu: 7.10 • gOS: 1.0.1 • K-DEMar GNU/Linux: 4.4.3 • Kiwi Linux: 7.10 • Linux Mint: 4.0 • MoLinux: 3.2 • Ubuntu: 7.10 • Ubuntu Muslim Edition: 7.10 • Ubuntu Studio: 7.10 • Xubuntu: 7.10 And the following distributions include 2.4.0rc2: • Linux Caixa Mágica: 12-RC1 • Mandriva Linux: 2008 And only one distribution includes 2.4.0rc1: • RAYS: 2.0 -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: my summary.
On Thu, 22 Nov 2007 08:47:40 +0100, [EMAIL PROTECTED] wrote: I find it rather arrogant to presume that those who can code are the only ones who can contribute to development and as a consequence anyone who can code is also an authority on graphic design and UI implementation. You are distorting what Sven said, but this seems to be a rather common perception and complaint so maybe this deserves some clarifications: Yes, the development of GIMP 2.6 will be mostly developer driven and there will not be much room left for additional suggestions and other stuff that is not already in the list of tasks that we are discussing here. I am not saying that to disappoint you. I am saying that because we have to cope with reality. Here are some reasons: - We have far more ideas than developers. We even have far more *good* ideas than developers. - The development cycle leading to GIMP 2.4 was much too long. It took almost 3 years since the release of GIMP 2.2. The development of GIMP 2.6 should be much shorter so that everybody can benefit from new features and other improvements without having to wait several years between stable releases. But this means that we have to make some hard choices and leave some interesting stuff for later. - The integration of GEGL and the support for higher bit depths is not a trivial task. Although there were great hopes that GIMP 2.6 would have good support for 16 bits per color channel, fancy color spaces and other features that many users are waiting for, we will not be able to get all of that ready in time. We will make some steps in the right direction, but there will still be a lot of work left for after 2.6. So what does that mean? We already know at this point that it will be challenging to achieve all goals that are mentioned in the draft roadmap for 2.6. Some of these tasks may seem to be rather obscure and may not bring many visible changes in GIMP 2.6, but they are necessary so that the releases that will follow 2.6 can support higher bit depths (in the core and in the plug-ins) and many other long-awaited features, including some improvements in the user interface. Considering that we are already struggling with the current list of tasks for which some volunteers exist (there are developers willing to spend some of their spare time working on them), I think that Sven is right when he reminds you that it is not the right time to discuss things that are not in the scope of 2.6 (tasks that are not already supported by a volunteer developer). -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Wed, 7 Nov 2007 04:03:51 +, Karl Günter Wünsch [EMAIL PROTECTED] wrote: So you suggest that the GIMP is changing the orientation tag when it is loading the image. This is mandatory according to the EXIF specification. A program that supports EXIF and wants to display the image correctly must load the image according to the orientation specified in the EXIF Orientation tag (this may involve rotation and/or mirroring) and must then clear the tag to indicate that pixel data is now having the same orientation as the image that it represents. Section 7.4 Application Software Guidelines of the EXIF specification explains that several tags must be updated by any software that saves an image containing EXIF information: Orientation must be set to 1 (the default top-left orientation) after rotating or mirroring the pixel data as appropriate, Software must be set to the name of the program that saves the image, DateTime must be set to the current date and time, YCbCrPositioning must be set according to how the data is saved, etc. If the resolution of the image has changed, then tags like XResolution, YResolution and ResolutionUnit may also have to be updated. What then happens if later I decide to rotate the image again manually? If you want to go there, you are opening up a whole new set of possible scenarios which will end up confusing users and other programs. This is not confusing at all. This is how all programs should behave. If the Orientation tag is set to any value other than 1 (top-left), then it means that the pixel data is not in the same orientation as the image that it represents, and any EXIF-compatible software that loads the image must rotate it. To simplify things a bit, the Orientation tag is just a way for a camera to say: hey, I'm a camera with limited memory buffers and I could not save the pixel data correctly, so please rotate the pixel data as appropriate when you load it so that you can display the image as intended. I always understood the question so that I either want to ignore the rotation flag or not but that the EXIF would stay untouched, no matter what I decide there... No, that's wrong. And that's one of the reasons why I want to remove this confusing question. The EXIF standard defines precisely the list of tags that must be updated and the list of tags that must be copied unchanged. Unfortunately, older GIMP versions were violating that standard by copying the whole EXIF block unmodified and this caused many problems, including images having the wrong orientation. EXIF in an edited image has little resemblance with the original anyway, so I would suggest stripping that except for the IPTC tags. I would also be happy if the IPTC tags were settable in the GIMP, instead of having to resort to other programs. IPTC tags are not part of EXIF. They are a different set of tags that are stored in another JPEG APP marker. The ability to edit and save them may be included in GIMP 2.6. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] XCF saving all state = no more temporary parasites
Here is a brain dump about XCF and state persistence. It is just food for thought and does not require immediate action for 2.6, except maybe for the handling of the flag GIMP_PARASITE_PERSISTENT: Some time ago, Peter mentioned that he would like the XCF file format to save all state associated with the image, so that you can reload the file later and continue exactly where you left off. This implies that each XCF file would have to save the state of the image as well as a bit of the GIMP state but we still have to discuss how far we want to go with that. For example: do we save the state of all tools in each XCF file? Do we save the current settings for all plug-ins? Do we allow the user to remove that information before sharing the XCF file with other users? But besides the state of the environment (GIMP tools and plug-ins), we should also ensure that the state of the image is correctly saved. With the current GIMP, this is not perfect because some information about the image exists only in internal (temporary) data structures and some other data is stored in image or layer parasites that are not persistent so these things are not saved in the XCF file. For example, if you save a work-in-progress as XCF and come back to it later, then you may have lost the original file name, you may not be able to recompose layers that were decomposed from another layer and you may get different settings if you save the image as TIFF or JPEG (because the parasites decompose-data or tiff-save-options are not persistent). If we want to solve some of these problems in 2.6 or later releases, then a first step would be to make all parasites persistent (as if GIMP_PARASITE_PERSISTENT was always included in the flags). We will also have to ensure that all binary parasites handle byte ordering correctly because any XCF file could be loaded later on a different platform. Would there be any objection to making all parasites persistent by default? -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF saving all state = no more temporary parasites
After the quick feedback that I got on IRC, I think that I should clarify a few things... If I understood correctly what Peter was suggesting some time ago, this was about making sure that the XCF files contain all the information necessary to continue your work in such a way that it would make no difference if you close GIMP and reload the XCF file(s) or if you just continue working without closing GIMP in the meantime. Of course there are some conflicting goals here: XCF was not designed as a save workspace format that would include all open images (not just one) and the complete state of the user interface including window positions, tool state, etc. And personally, I do not think that we should go in that direction because that would belong to a new GIMP workspace file format that would not be an image file format like XCF is supposed to be. I deliberately included the examples about tools and plug-ins in my previous mail because I wanted to see how other developers would react. And it looks like mitch reacted strongly on IRC. ;-) However, if you consider only the information that is directly related to each image, then it would make sense to save as much of it as possible in the XCF file so that it makes (almost) no difference if you close GIMP and re-open the XCF file or if you just continue editing it. So here is a short list of what I think makes sense to include in XCF files: - All image parasites and layer/drawable parasites. They should all be persistent - no reason to have exceptions. - All settings of file plug-ins, because these settings should be associated with each image (e.g., using image parasites) instead of using global last vals. It does not make sense to save the settings of other plug-ins (filters) because these are usually shared globally and would change if you load/save several images. - Some other image data that is currently in internal data structures and not in parasites. For the file name, the best solution may be to keep the current get/set_filename() functions using the internal file name (which would change once the file is reloaded from XCF) but add a new gimp-file-name or gimp-original-file-name parasite so that it is still possible to associate an image with its original file. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF saving all state = no more temporary parasites
On Fri, 9 Nov 2007 10:15:42 -0800, William Skaggs [EMAIL PROTECTED] wrote: From: Raphaël Quinet [EMAIL PROTECTED] - All image parasites and layer/drawable parasites. They should all be persistent - no reason to have exceptions. The problem is that when a parasite gets saved, it becomes in effect a part of the API that must be supported forever. [...] This sort of thing may make sense for stable releases, but during development it is often a great convenience to be able to experiment with formats without every attempt being a commitment that will bind you forever. Well, the developer releases are not supposed to be stable. And as long as the development tree is still far from any feature freeze, then it is not wise to expect that its APIs will be supported forever. The format of some persistent parasites has been changed during the 1.3.x development cycle in a way that was not backwards-compatible (maybe during other cycles as well, I didn't check). So I don't think that we have a real problem here. If you really think that unstable releases should never save stuff that may be changed before the stable release, then we could add a new flag GIMP_PARASITE_UNSTABLE or GIMP_PARASITE_EXPERIMENTAL and define that flag only if GIMP_UNSTABLE is defined. That would do exactly the opposite of what we have now: parasites would be saved unless marked as unstable. But that's a bit overkill... -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
Here is my contribution to the GIMP 2.6 roadmap: a description of the remaining tasks related to the metadata viewer/editor and some enhancements for the jpeg plug-in (and other plug-ins). In the following list, the tasks marked with a + are the ones that I would like to include in 2.6, while the tasks marked with a - will be postponed until after 2.6. These optional tasks are listed here for completeness and they could still be included in case there is a sudden rush of volunteers willing to contribute to these improvements. ;-) * metadata core (stuff that does not need a user interface): + migrate some parts of the metadata core to a library that can be used by the main app. as well as some plug-ins + clean up the PDB interface + convert EXIF to XMP + convert XMP to EXIF - convert IPTC to XMP (IPTC Core for XMP) - convert XMP to IPTC - rewrite the XMP parser and the internal data model * metadata viewer/editor (user interface) + implement the user-friendly tabs in the metadata editor - make the tabs configurable, similar to Adobe's XMP panels - easy merging of XMP presets from a drop-down list or something similar (e.g. to apply a Creative Commons license or to set a group of properties such as creator, publisher, etc.) - allow the creation of such XMP presets - warn the user if the metadata states that editing the image is not allowed (XMP Rights Management) - implement history tracking for XMP Media Management - allow creative editing of the embedded thumbnail * jpeg plug-in + simplify the user interface: the default view should show only a selection between a few options (e.g, high/medium/low or 0-12 like in Photoshop) combining both quality and subsampling; move the old 0-100 quality slider inside the advanced options + remove the prompt for EXIF orientation: it should always be done - allow lossless or nearly lossless saves if only a few changes have been applied to the original image (e.g. 90 degrees rotation or minor edits in a limited area) * all file plug-ins + handle metadata correctly (at least for jpeg, tiff, png) + make sure that the last used settings are saved in a parasite attached to the image instead of using global save_vals, etc. - make it easy to save and restore settings (more than one set) in case the user wants to apply the same settings to several images In case the description or purpose of some of these items is not clear, here are some additional comments: The metadata editor uses XMP internally, because XMP is a superset of EXIF, IPTC and other metadata standards (or de facto standards). The XMP parser and generator are already included in GIMP 2.4. I also wrote some code to convert from/to EXIF, but I did not finish it and I think that it is better to rewrite it from scratch anyway. The problem with EXIF is that although the basic features are easy to parse, there are dozens of special cases and broken implementations to take care of, especially for the handling of MakerNotes. As we discussed already several months ago, it would be useful to move some parts of the metadata handling code into a library that can be used directly by other plug-ins or by the gimp core, instead of invoking the metadata plug-in as in 2.4. It should be possible for the user to keep the Image Properties window open at all times and to see the changes in real-time (resolution, size, comment, etc.). In order to allow these real-time updates, the code displaying this part of the image metadata should be part of the gimp core. This does not mean that all metadata handling should be done in the core: it would also be possible to have only the viewer part and the basic metadata handling in the core but keep the editor part as an external plug-in. Another option would be to keep all that out of the core but change the plug-in API so that it allows a plug-in to remain attached to an image while other plug-ins are running, and change the protocol so that it allows a plug-in to get real-time updates about what happens to the image. Regarding the user interface and the options (probably post-2.6) to make tabs configurable or to choose XMP presets from a list, I think that it is easier to understand if you look at these images: http://www.creativecommons.org/images/metadata/xmp-adobe-panel.png http://www.creativecommons.org/images/metadata/xmp-cc-panel.png http://www.creativecommons.org/images/metadata/xmp-multiple.jpg Note that in these images, the Creative Commons panel is an extension that can be downloaded from the CC site (it's a simple XML file) and it shows up among the other XMP panels, with the appropriate widgets for editing specific parts of the XMP metadata. See also: http://wiki.creativecommons.org/XMP_Help There are also some improvements for the JPEG plug-in. As I mentioned some time ago, I would like to hide the current quality slider among the advanced options, and replace it by a
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Sat, 3 Nov 2007 00:06:18 +0100, Karl Günter Wünsch [EMAIL PROTECTED] wrote: On Friday 02 November 2007, Raphaël Quinet wrote: There are also some improvements for the JPEG plug-in. As I mentioned some time ago, I would like to hide the current quality slider among the advanced options, and replace it by a smaller selection of pre-defined quality levels. [...] every site I post my images to has stringent restrictions on file size [...] Having preset quality settings really is no option, it is a major annoyance in Photoshop new users I spoke to always are struggling with! It looks like what you want is a Save for Web feature (especially because you mention posting images to some sites). Photoshop offers two different ways to save a JPEG image: 1) The normal Save assumes that you use JPEG like most other (lossless) image formats. Professional users expect that the image will be saved with a rather high quality, will contain the appropriate color profiles and other metadata related to the image so that it can be integrated in a publishing process and eventually printed. Photoshop allows the user to select quality levels between 0 and 12 (but each of them sets more than just the quality because the subsampling parameters are also affected). The lowest level (0) is equivalent to quality 85 in GIMP, and the highest level (12) is somewhere between 97 and 98 in GIMP. But using levels 11 and 12 is not recommended, so the recommended High quality level is 10, which is equivalent to quality 93 in GIMP. 2) The Save for Web feature assumes that you will put the image on some web site instead of printing it, so you care more about the size of the file than about its faithful rendering on a printer. Save for Web allows you to remove most metadata from your image and gives you more control over some JPEG parameters that can help you to reduce the size of the file. Among others, it has a slider that goes from 1 to 100 so that you can fine-tune the size/quality and it also has an option that lets you enter the target file size so that Photoshop can select the compression level that brings you as close as possible to this target value. Note that the 1-100 slider in Photoshop is not the same as in GIMP: the corresponding range in GIMP would be 55-98 (approximately). Experienced Photoshop users will select Save or Save for Web depending on what they intend to do with the image. The goals are different and almost mutually exclusive: 1) Save: high fidelity for printing, include all metadata, no need for a preview of the JPEG compression quality, no need to estimate the size of the file before saving 2) Save for web: focus on the size/quality trade-off, it is important to have a preview and to predict the size of the file, no need for metadata, assume sRGB color profile. Currently, GIMP tries to do a bit of both in the same jpeg plug-in and does not do either of them correctly: - For a normal Save, it is a bit stupid to have a quality slider that goes from 0 to 100 if the useful range is only between 85 and 95. - Showing only the quality slider in the default view misleads users into thinking that they only have to play with that value in order to reach a target size for the file. Changing the subsampling parameters can be as important in order to reach the best size/quality ratio. - It is necessary to check or uncheck several checkboxes in order to select if metatada and image thumbnails should be included or not. - Several other checkboxes that are rarely used clutter the list of options. The choice of DCT method and the inclusion of restart markers are special features that are almost never used (or used wrongly). Considering all that, I think that it would be much better to provide a simplified set of choices. Each of them would combine several parameters such as quality and subsampling. This would streamline the interface for the common case for our target users (cfr. GIMP vision). Of course, the advanced settings would still be available and this would include the old quality slider if you think that it is useful. But for the kind of use case that you described, the ability to enter a target size for the file would be more useful. We could also change the jpeg plug-in so that it remembers if the advanced options are expanded or not, and maybe make it remember that across sessions. So if you insist on using the old quality slider for each image, you could still do that easily. -Raphaël P.S.: For more information about the mapping between Photoshop and GIMP quality levels, see: http://blogs.gnome.org/raphael/2007/10/23/mapping-jpeg-compression-levels-between-adobe-photoshop-and-gimp-24/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Help needed for the gimp web site
GIMP 2.4 will be released very soon. It should be a matter of days. However, the new web site for 2.4 is not ready yet. It would be nice to get some help and have the web site ready for the release. As you may already know, a temporary web site has been set up at next.gimp.org (please do not publish links to that site outside the GIMP lists!). I am looking for volunteers who could contribute contents for the following pages, in order of decreasing importance: Required for the 2.4 release (blockers): * http://next.gimp.org/release-notes/gimp-2.4.html The release notes for GIMP 2.4. Several sections are incomplete. * http://next.gimp.org/features/ List of features presented in a graphical way. See the FIXME message near the top of that page. Optional improvements: * http://next.gimp.org/release-notes/gimp-2.4-cm.html A description of color management as an addition to the release notes for GIMP 2.4. Still incomplete. * http://next.gimp.org/about/introduction.html The original introduction and list of features, partially redundant with the new list in /features/. Maybe both could be merged? * http://next.gimp.org/docs/userfaq.html The user FAQ should be updated. Some sections are obsolete (Xinput, MIT-SHM, ...), the sections about fonts and file formats date back from the GIMP 1.x times, most of the troubleshooting section should be rewritten, etc. Some answers could be shortened by linking to other parts of the site or docs.gimp.org (e.g., the list of books should link to /books/). * http://next.gimp.org/about/history.html History of GIMP releases. I'm not really sure about what to write in that page (compare with prehistory.html and ancient_history.html) or how to make a pretty timeline as a simple image (without using JavaScript). So maybe this can be left for later. If you want to help for any of these pages or improve some other parts of the site, please contribute directly in SVN. If you do not have SVN commit access, you can also post bits of improved text to the gimp-web list and someone will take care of committing them for you. If you have SVN access to the gimp-web module, please use the branch gimp-web-v2.4 instead of the trunk, which is only used for the old site and will be replaced soon. Several people have reported that they experienced difficulties in building the web site from SVN or setting up a web server, etc. If you only want to check that you did not break anything before doing a commit, then you do not even need a web server to test your changes: make DocumentRoot=/tmp/wgo This will build and install the generated HTML files in a temporary directory /tmp/wgo without requiring you to set up anything special. If this works, then chances are the you did not break anything. You will not be able to see the correct style sheets and included files, but at least this will check the basic syntax of your pages. -Raphaël P.S.: This message is also cross-posted to the gimp-developer list, but please send replies to the gimp-web list only. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] other things we need for the 2.4 release (again)
On Thu, 04 Oct 2007 00:30:05 -0400, [EMAIL PROTECTED] wrote: I have created a text file outlining the major fixes that TinyScheme-based Script-fu might require (link provided below). I suspect others are much more capable than me at producing what you are looking for but I think the points I mention will be the most problematic for script adapters. http://flashingtwelve.brickfilms.com/GIMP/Scripts/Script-fu-2/Reference/Script-fu-2.4.txt Great! Thanks a lot for this nice summary of the changes. I will integrate your guide into a web page for the new web site. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Splash for 2.4
On Fri, 28 Sep 2007 09:09:29 +0300, Aurimas Juška [EMAIL PROTECTED] wrote: Interestingly enough, I could never think of a splash screen that would be made for one version (2.4) and imposible to rework for other (2.6). You proved it's possible :) Actually, I would really enjoy having a variation of that splash screen used as the official splash for GIMP 2.6. This would be much more interesting than for GIMP 2.4. Other suggestions: maybe with a Wilber tattoo on one hand, and of course writing GIMP instead of The Gimp. Keep in mind that GIMP is an acronym and should always be written in all caps. We use that acronym as a product name and it is pronounced as a word and not as individual letters, so it should be written without The. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving selections
On Wed, 12 Sep 2007 14:36:35 + (UTC), Christian Henz [EMAIL PROTECTED] wrote: Raphaël Quinet raphael at gimp.org writes: Yes, there is: - Alt+Ctrl moves the selected pixels. - Alt+Shift moves a copy of the selected pixels. I'm currently struggling with this in 2.4.0-rc2: After selecting a region, I can resize and move the selection by dragging the mouse within the selection. When I press either Alt+Ctrl or Alt+Shift, I can start a new selection within the area of the current selection. I have not found a way to move the pixels yet (except cut-and-paste of course). Did you first confirm the selection by pressing Enter or clicking once inside it? Once the editable rectangle is confirmed and turned into a real selection, you should be able to move its contents with Alt+Ctrl. Also, In the move tool, the options in the Selection tab are always disabled, and there are two entries named Move selection. This looks like a bug. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
On Thu, 30 Aug 2007 15:56:16 -0600, Scott [EMAIL PROTECTED] wrote: On Thu, Aug 30, 2007 at 08:56:33AM +0200, Jakub Friedl wrote: I think that use image file quality unless defaults are 'better' is not thee problem. Problem is inheriting image quality between different images in one GIMP session. I have a default quality of 85. Then I open DSLR image with quality 95. Save it with that quality. Then I open and save low quality cameraphone image. But I am not offered my default nor the original cameraphone quality (which would be both understandable) but the DSLR quality of 95. Huh? These images have nothing in common except they have been opened in the same editor session. Do not mix them up. There are times I definitely *want* to save the settings from a previous save. [...] If you want to save several images with the same settings, you can use the buttons Save defaults and Load defaults. We also have an enhancement request (bug #120829) about providing multiple presets that could be saved and re-loaded when necessary. I think that it is much better to require an explicit action if you want to re-use some settings from one image to the next, instead of always doing this automatically. Each image should have its own settings and should not be influenced by how you saved unrelated images in the same session. As in the example given by Jakub, it is annoying that the parameters used for saving a high-quality DSLR image are automatically re-used for saving a low-quality cameraphone image. This should definitely change for 2.6. But my question was about what kind of workaround can be implemented quickly for 2.4. It looks like it might be better to have all plug-ins broken in the same way instead of just fixing the most used ones, so that would be the second option that I described in my previous message: ignore the settings from the original JPEG images and always re-use the parameters from the last saved image. This is bad, but at least this is consistent with other file plug-ins (until they can all be fixed). -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
On Fri, 31 Aug 2007 12:24:47 -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: It sounds like what's happening is something like this: 1) Current JPEG quality setting is 85 2) User selects Use quality settings from original image if original image is better 3) Original image has quality setting of 98 4) User saves image 5) Now the current JPEG quality setting is changed to 98 Is that correct? Almost. Step 2 currently happens automatically if the quality of the original image is better than the defaults (because of the complaints that gimp was destroying the quality of some images without warning). But this may change, so step 2 could again require an explicit action from the user. If so, then (5) seems wrong to me. [...] Yes, this is exactly what I tried to explain in my previous messages. The problem is that the JPEG plug-in and most other file plug-ins will automatically re-use all settings from the last file that was saved. My own preference is to err on the side of caution; I'd rather make a mistake of saving at too high of a quality (which loses less information) than too low. If I accidentally save a thumbnail at quality 98 or 100, all I've done is wasted a little disk space; if I save a good image at 85, I've lost a lot of data. And this is what is currently implemented: if the quality level of the original image is higher than the current default value, then the quality from the original image will be selected automatically. But since the JPEG plug-in shares the same behavior as the other file plug-ins, this new value is automatically remembered for the next time you save an image. The combination of these two things (using the original quality if it is higher, and the automatic re-use of the last values instead of using the defaults) causes the problem reported by Jakub: if you load and then re-save many images that were saved at different quality levels, you end up with the last image saved at the highest quality level (maximum value from all images), which may be much higher than the default value or than the original quality of that image. This is a bug that should be fixed. But after discussing this briefly with Simon in #gimp, I think that it would be better to postpone the real fix to GIMP 2.6 because it would not be possible to fix all (or even most) file plug-ins for 2.4. And if only the JPEG plug-in (and maybe PNG) behaves differently than other plug-ins, then some users will probably complain or at least be confused. It may be better to postpone the real fix until all plug-ins support a way to load and save defaults, and maybe support multiple presets. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
On Thu, 30 Aug 2007 00:57:44 +0200, [EMAIL PROTECTED] wrote: Gimp should not decide what is better because it cannot know what is required so cannot make that choice. This sort of surprise behaviour is precisely the kind of thing I was warning against in making covert changes to user data. I think that you are trying to shoot the wrong target. The main problem that I described in my previous message is not the fact that GIMP tries to preserve the quality of the original image or decide what is better. The problem is that some changes that you make when saving one file are propagated to all other files that you save later. The recent updates to the JPEG plug-in make this problem more obvious, but it also affects all other file plug-ins. Before jumping to conclusions about where the problem comes from, please try the following exercise: - Load or create a GIF animation (2-3 layers should be enough). - Save it as A.gif and let's pretend that you don't like the speed at which that animation runs so you set the delay to 333ms and check the box Use delay entered above for all frames. - Close that image. - Open or create a new, totally unrelated GIF animation. - Save that image as B.gif. Although you probably wanted to keep its settings or at least save it with the default values, you see that Use delay entered above for all frames is now checked. The settings from an unrelated image that is now closed are used for saving your new image. If you do not want to destroy the timing of your animation, you have to pay attention and uncheck that box before you save the file. Does it make sense that two unrelated images influence each other? But things are even more confusing if you keep some images open. Try the following exercise, with PNG this time: - Load or create a new image. - Save it as A.png but set its compression level to 0 because you want to waste some disk space and disable all other options because you do not want to save the image comment, creation date, etc. - Keep A.png open and load or create another image. - Save the second image as B.png. Although you probably wanted to use your default settings (which can be customized with the buttons Load/Save defaults), you see that the same parameters as A.png are now used when saving this image. You do not like this, so you set the compression level back to 9 (you can also check or uncheck some of the other boxes) and save the image. - With both A.png and B.png still open, load or create a third image. - Save that image as C.png. Now you see that C.png inherited the settings from B.png, the last image that was saved. - Make some small changes to A.png and save it again using a new name such as D.png. By now, maybe you expect that saving D.png would use the same settings as C.png, the last image that was saved? But no, this time you see that D.png keeps the settigns from A.png because it was still open. - Now if you make some changes to B.png and give it a new name E.png, then that file will use the settings from B.png. But if you had closed and re-opened B.png, then you would see that E.png is saved with the parameters from D.png, not B.png. Are you confused yet? If you work on two files in parallel (A.png and B.png) and save them alternatively as your work progresses, then any new file that you open and save will inherit the settings from A.png or B.png, depending on which one was saved last. And if you are still convinced that all of this makes sense, try to play with some settings that are enabled or disabled depending on the contents of the original image. For example, if the original PNG image has transparency (alpha channel), then you will be able to check or uncheck the box Save color values from transparent pixels. This setting may be propagated to other PNG images that also have an alpha channel. But if you load a PNG image without alpha channel, then this option will not be available. After saving that last file, can you correctly guess if that box will be automatically checked or not when you load another PNG image with transparency and then try to save it? I consider the current situation to be broken for all file plug-ins. Instead of re-using the settings from whatever image was saved recently, each image should keep its own settings and should not be influenced by what you do with the other images. The save settings should come from the original image or from the user defaults if the image has never been saved yet. It should of course be possible for the user to customize these defaults (currently, this can only be done for JPEG and PNG, but the old bug #63610 is about extending this to other plug-ins). I hope that you are convinced that something is wrong with the behavior of the file plug-ins. Now, regarding the JPEG plug-in, I see two ways forward: 1) Do not re-use the values from previous (unrelated) invocations of the plug-in. This ensures that each file
Re: [Gimp-developer] moving selections
On Wed, 29 Aug 2007 19:25:01 +0400, Alexandre Prokoudine [EMAIL PROTECTED] wrote: Say, I need to select a region and move it. Documentation clearly states: Click-and-drag then allows you to move the selection and its contents, while the initial position remains empty. That bit of docs probably belongs to 2.2, but definitely not to 2.4: Yes, the behavior has changed during the 2.3.x development. Clicking without modifiers will now always start a new selection. With 2.2 and previous versions, some users complained about the different behavior of the selection tools if you were clicking inside or outside an existing selection. While paste in place and under cursor definitely belong to 2.6, I wonder if the move selection with its contents feature got lost due to all the changes to rectangular tools. Yes, there is: - Alt+Ctrl moves the selected pixels. - Alt+Shift moves a copy of the selected pixels. The user and me checked: - docs - UserFaq in wiki - google - spec for new rectangle tools You forgot to check the status bar messages while using the selection tools. They suggest to try Alt, and when you do that you will see the explanation about what you can do. The docs will eventually be updated for 2.4, and then it will be easier to find this information. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving selections
On Wed, 29 Aug 2007 13:38:26 -0400, Kevin Cozens [EMAIL PROTECTED] wrote: On 8/29/07, Raphaël Quinet wrote: - Alt+Ctrl moves the selected pixels. - Alt+Shift moves a copy of the selected pixels. That seems backwards in a way. To make it easy to remember which moves (ie. shifts) the pixels and which moves a copy it would be better the other way around. The C from Ctrl would make one think of Copy while Shift would be just that (shifting but not copying). Probably too late to change this and would confuse users who are already used to it as it is now. It should not be too hard to change this. This would not even require a string change because the messages suggesting to use the various modifiers are generated dynamically. I remember discussing these combinations of modifiers with mitch, so we should wait until he can comment on that before changing anything. Also, while I understand your arguments about shift = move and C as in Copy, these are only valid in a few locales (mostly en_*). And if you compare with how the modifiers are used for other operations, then you will see that we tend to use Shift for things that are less destructive than Ctrl. Maybe that was the reason for selecting Alt+Shift for copy. I don't remember. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Annoying behavior of shared settings for file save plug-ins
Most file-save plug-ins share a behavior inherited from other plug-ins: they save and retrieve their last values so that invoking them again will use the same parameters. As discussed previously, this behavior is fine for image filters but leads to annoying consequences for file plug-ins: if you set some parameters when saving a file, then the same parameters will be re-used if you save another (unrelated) file with the same file format during that GIMP session. These settings will be used instead the default values normally set by the plug-in (which may be user-configurable, as in the PNG and JPEG plug-ins). Today, Jakub Friedl reported in #gimp that this behavior can lead to surprising results, especially after the changes in the JPEG plug-in that ensure that the initial quality level for the JPEG save dialog is at least as good as the one from the original image. Because all settings from the JPEG plug-in (including the quality level) are re-used from one file to the next, the net result is that the quality level always increases if you load and re-save many files that were originally saved with different quality levels. Of course I could just add a quick workaround and change the code that sets the initial quality level so that it ignores the value coming from the jsvals. But wouldn't it be better to remove the call to gimp_get_data (SAVE_PROC, jsvals) and ignore all these values? Is there still a reason to keep these shared settings, considering that each image that has been saved at least once gets its own jpeg-save-options parasite, and the user also has the option to change and save the defaults (which go into a global parasite jpeg-save-defaults)? -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tile creation and tile caching
On Wed, 22 Aug 2007 21:39:32 -0700 (PDT), rayadurgam sudha [EMAIL PROTECTED] wrote: hello every one, can any one tell me when a map is tiled, what is the extent of zoom we can specify which does not create any problem for us as developers and users to view the map. please reply to this.. its urgent Please try rephrasing your question and providing more context. As your question stands now, it is very difficult for anyone to provide a meaningful answer. What do you mean by when a map is tiled? What kind of problems are you afraid of? Who are the users? Any GIMP users? Users of a specific program? What is this map anyway? What are you trying to achieve and why is it urgent? Oh, and please, please avoid quoting the whole mailing list digest in your message. It seems to be totally unrelated to your question and it is just a waste of bandwidth. If you ask better questions, you will probably get better answers. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option Use custom quality settings for JPEG files
On Wed, 15 Aug 2007 10:20:48 -0400, [EMAIL PROTECTED] wrote: Quoting Robert L Krawitz [EMAIL PROTECTED]: The problem is that custom tables seems very confusing -- it sounds like the user's going to be asked to input something she knows nothing about. One could argue that Use existing image quality settings [...] My only comment on this issue is that the term image is consistently employed within the GIMP vocabulary to mean the in-memory copy of the picture being edited [...] I think that using the terms original image would avoid this problem. We are basically left with two options: 1) Use custom quality settings - Hard to understand for most users - Technically correct description - No need to change the code; this is what we have now 2) Use quality settings from original image - Easier to understand for most users - Correct description for the most common usage scenario - Requires some small changes to the code - Breaks the string freeze before 2.4 It seems that going for (2) would be better for the users but would annoy some translators. But I got several requests to go for something like option (2), so I would like to know if it is worth breaking the string freeze. Opinions? -Raphaël P.S.: please do not mention bikesheds. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On Tue, 21 Aug 2007 15:48:15 +0530, Amit Kumar Saha [EMAIL PROTECTED] wrote: Is there any way to make GIMP plugins themselves extensible. My point here is that, can we make a GIMP plugin which allows itself modifiable by a end-user to include a new functionality without much of a hassle on part of the end-user. Does any one know of a method to do this or any GIMP plugin which already does this? Besides the scripting languages mentioned by others, you could also take a look at the MathMap plug-in if you are good at math... MathMap home page: http://www.complang.tuwien.ac.at/schani/mathmap/ Nice examples of MathMap usage: http://www.flickr.com/groups/mathmap/ -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On Wed, 22 Aug 2007 23:19:30 +0100, David Marrs [EMAIL PROTECTED] wrote: Amit Kumar Saha wrote: Am i thinking in a way that could possibly be implemented? or is the word extensible remotely applicable to my idea? So what you're talking about here is a graphical interface to the API that a user can use to build his own extensions? Essentially, it's a graphical programming language. There are quite a few examples of these in the music world that allow the construction of modular synths (amongst other things). Not only in the music world. Around 1993 or so, I remember using a program called Khoros Cantata to design some image filters. A quick search on the web returned this tutorial with screenshots of the old X11 version that I used: http://www.cse.psu.edu/~cg585/cantata-over.html Just imagine that the glyphs (the boxes that can be connected) could be the operations that GIMP offers through the PDB. It seems that Khoros Cantata has been acquired at least twice by different companies, has been ported to Windows, and is now sold as Accusoft VisiQuest: http://www.accusoft.com/products/visiquest/overview.asp The interface has changed a bit, but it is still based on the same ideas of connecting glyphs providing various functions. By the way, this brings back some memories about what I did in 1993 as an exercise for a course in digital imaging. Students were asked to write a new filter for Khoros and use it to perform some interesting image transformations. I decided to write a filter that would use various correlation methods to reconstruct an image in which the lines were shifted horizontally by some random amount. The default method was optimized for un-shifting images at TV resolution (PAL) that were shifted by one of three predefined offsets picked at random. The method worked surprisingly well. The code and the results were presented to the professor. He asked if, by any chance, this could be used to decode Canal+ images (a pay TV channel that was popular in several European countries). And the answer was yes. Not in real time because the 486 processors that were common at that time were not fast enough, but the method worked well with recorded TV streams (sometimes even without using inter- frame correlations). Ah, I still have fun when I remember this and when I consider that the professor gave one of the top marks for this exercise. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Missing button to confirm some tool actions (usability)
On Fri, 17 Aug 2007 01:15:37 +0200, Martin Nordholts [EMAIL PROTECTED] wrote: Raphaël Quinet wrote: One of the changes from GIMP 2.2 to 2.4 is the streamlining of some tools [...] However, as noted by one user on IRC today, this has also removed the big Crop button that existed previously in the pop-up. [...] One idea would be to put such a button in the status bar, just like the Cancel button that appears when a plug-in displays its progress information. Interesting observation, but does it make sense to have buttons in a place that (to my understanding) is supposed to be a monologue, i.e. just providing information; not offer interaction? Wouldn't it make more sense to have this button in the Tool Options? Well, the bug report was about having a button somewhere - anywhere. The suggestion to place it in the status bar (in the same place as the Cancel button that already appears when a plug-in is running) was just an idea, but certainly not the only way to solve this problem (assuming that we consider it as a real problem that has to be solved). Now, I know that we don't like more stuff in there, but imo that's the right place for such a button. Tool options should be reserved for options, not for actions. And indeed, we have too much stuff in there: most users already have to scroll in order to see all options. On the other hand, we already have some actions in there, such as Auto Shrink Selection (rectangle tool) or Create Selection from Path and Stroke Path (paths tool). So maybe we could add another button among the tool options. I don't like the idea of overlays that has been suggested by others (displaying controls over the image) and we should get rid of the annoying pop-ups, so for the moment I only see the following options: 1) put the confirmation button in the status bar, 2) put the confirmation button in the tool options, 3) ignore the issue and assume that all users will read the message suggesting that they press Enter. Other ideas or opinions are still welcome... -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Missing button to confirm some tool actions (usability)
I originally intended to submit this in Bugzilla, but let's discuss this here first: One of the changes from GIMP 2.2 to 2.4 is the streamlining of some tools and removal of some annoying tool pop-ups that were breaking the workflow and stealing the focus from the canvas. The pop-up is gone from the Crop tool but is still present in the transform tools. However, as noted by one user on IRC today, this has also removed the big Crop button that existed previously in the pop-up. Although there is now a status bar message that says Click or press Enter to crop once the crop rectangle has been defined, it seems that some users still expect to see some kind of button somewhere. This issue may also affect other tools such as the transform tools if we also get rid of their pop-ups. One idea would be to put such a button in the status bar, just like the Cancel button that appears when a plug-in displays its progress information. This could be done for all tools that have a state in which some actions should be confirmed (some selection tools, transform tools, etc.) But other solutions may also be possible, unless we close this issue as WONTFIX. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option Use custom quality settings for JPEG files
On Mon, 13 Aug 2007 13:36:05 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: On Mon, 13 Aug 2007 07:10:30 -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: Would Use existing image quality settings be a better name for this? I considered naming this option Use original quality settings, but one thing that I forgot to mention in my previous messages is that it is possible to write a script or plug-in that attaches different quantization tables to any image. [...] Although I was a bit reluctant to do this, we could try to change the name of this option to Use original quality settings or Use quality settings from original image or something like that. This would require several changes in behavior explained below. This new meaning may not be appropriate if other quantization tables than the original ones are attached to the image, but if we consider that usage to be an exception, then maybe we can optimize for the common case if this could make the option more understandable. Anyway, if we want to change that string, then we have to reach a consensus on that in the next few hours and make sure that it will not change again until GIMP 2.4 is out. We should be in string freeze now. If we change the label, this also changes the meaning of the option and this will require some changes to the code: - Currently, Use custom quality settings is only available when the quantization tables are non-standard ones. If the tables can be generated by the IJG JPEG library, then the option is grayed out because the user can get the same table with the existing quality slider (and that slider is already set to the right value if the quality of the original file is better than the user's default). If that option is changed to mean I want the same settings as the original image instead of I want to use some non-standard tables, then that option should always be available even if the original image used standard quantization tables. - Enabling that option should not only change the quality slider, but it should also change the choice of subsampling parameters, even if the chroma subsampling in the original image is not as good as the user's defaults (i.e., if the default is 1x1 and the original image used the lower quality 2x2 or 2x1). This would ensure that all significant parameters from the original image are re-used when saving. Note that it would be a one-way change: enabling the option Use original quality settings would change the subsampling parameters, but changing the subsampling parameters later would not disable the option (unlike what is done when the quality slider is moved). - Optionally, the usage (or not) of optimized Huffman tables could be detected in the original image and re-used when saving. I think that it would be better to leave it always enabled (always optimize) but if we want to be as close as possible to the original image, then we could disable the optimization if the original image was not optimized. Implementing these changes would be easy (except for the last one, maybe) and I know exactly what would have to be be changed so the code itself is not an issue here. But we should quickly decide what this option should mean. I like the current meaning (custom tables) but some of you think that it would be easier to understand something referring to the original quality settings. If we can reach a quick agreement on what is better (considering the differences explained above) and if it is not too late for 2.4rc1, then maybe I could change that option. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] mentioning Photoshop on this list
On Wed, 15 Aug 2007 12:04:08 +0200, Danko Dolch [EMAIL PROTECTED] wrote: 01. Yes good idea (but never speak out the evil word pho***o* - dev. are a bit sensitive to it ;-) Just a little thing that I would like to clarify: mentioning Photoshop or other products on this list is perfectly OK. If anybody on this list feels offended of feels compelled to react strongly when someone mentions Photoshop, Paint Shop Pro, Windows, Adobe, Microsoft or some other proprietary products or companies, then they do not belong here. Feel free to have constructive discussions and to compare GIMP with other products here. Other programs also have great features, so describing these features and their pros and cons can be a nice way to make GIMP even better. However, there are some things that you should avoid: - Assuming that everybody knows what you mean when you talk about some specific feature of another program. I do not have a copy of Photoshop (*) and most GIMP developers do not have one either. I have not seen nor used any recent version of Photoshop. So if you mention some specific feature of another program, please be sure to describe it precisely instead of just saying that we should implement this or that like in Photoshop. - Assuming that we want to have the same features as another program. With the help of Peter, we have developed a vision for GIMP: http://developer.gimp.org/gimpcon/2006/index.html#vision Features that do not fit in the GIMP vision will probably not be implemented. Among other things, GIMP does not try to copy Photoshop or MS Paint. - Assuming that we will implement some useful feature in the same way as another program. There is often more than one way to implement something. Each solution has advantages and disadvantages. We should always try to implement the solution that fits best together with other GIMP features. So when you describe a feature, try to describe its purpose (what does it do? why is it useful? to whom?) before describing how it works. Most of the comments on the list that were complaining about a message mentioning Photoshop were due to one of the reasons given above. The complaints that were not due to one of these reasons can probably be ignored. So feel free to mention other products or programs here, as long as you provide useful information. By the way, there is no need to censor or change the name of a product or company when you mention it (Ph*t*sh*p, Windoze, ...) We can speak like grown-ups. Or try to. ;-) So these were just my 2 cents to avoid spreading misconceptions about what is OK and what is not OK on this list... -Raphaël (*) I might still have a CD with Photoshop 4.0 LE for Windows 95 that that came with my scanner. But my old Win95 PC has not been booted since a very long time. And a 10 years old copy of Photoshop is probably irrelevant for most comparisons. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option Use custom quality settings for JPEG files
On Mon, 13 Aug 2007 09:22:58 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Sun, 2007-08-12 at 23:44 +0200, Raphaël Quinet wrote: Since Friday, I added a new option to the JPEG save dialog: Use custom quality settings. If some quantization tables were attached to the image when it was loaded, then this option allows you to use them instead of the standard ones (different quantization tables are generated by the IJG JPEG library for each quality level). Why do we need an option in the GUI for this? If there are quantization tables attached and the user doesn't change the save quality, then just use them. Or is there a real disadvantage in doing that? To me it looks like you are asking the user a question that she is unlikely going to understand. And you are forcing the user to make a decision that you can better do for her. I think that this option is still useful. Maybe not for disabling it when it is enabled, but for enabling it when it is not enabled automatically. It is usually better to use the custom quantization tables if they are better than your default quality settings. But if they are not better, then it is nice to give a choice to the user. If the quantization tables found in the original file are not better than your default quality settings, then the option Use custom quality settings will be available but not enabled. This ensures that you always get at least the minimum quality specified in your defaults. If you did not make major changes to the image and you want to save it using the same quality as the original, then you can do it by enabling this option. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option Use custom quality settings for JPEG files
On Mon, 13 Aug 2007 11:16:15 +0300, Alexander Rabtchevich [EMAIL PROTECTED] wrote: Why don't add such a wonderful floating tip with a short description of the switch and not to revoke the possibility from a user? This is already done. There is a tooltip associated with that option and it explains what it can be used for. Just try it an see for yourself... Sven is right to be concerned about the number of options in the JPEG save dialog. But as I explained in my previous message, this one is useful so that is why I added it. Besides the option Force baseline JPEG that I removed last Friday, there are other options that could be removed in the future: - the choice of DCT method (integer, fast but less accurate integer, or floating-point) because the speed differences are not significant anymore, - the ability to add restart markers because unreliable channels are much less common nowadays, - the smoothing option because this can also be performed by the usual blur filters. All these options could still be available through the PDB interface for those who really miss them, but otherwise I think that they should be removed from the advanced options soon after GIMP 2.4 is released. It will then be time to think about redesigning the JPEG save dialog from scratch. As I mentioned earlier, I would like to simplify that dialog and only have a dozen presets for the quality settings instead of having the 101 values in the quality slider plus the choice of chroma subsampling in the advanced options. Picking one of these presets would select the corresponding quality level (quantization tables) and the most appropriate chroma subsampling. These may still be available in the advanced options, but most users would never have to worry about them. I am not sure if the best way to make a choice among the dozen presets would be a set of radio buttons, a slider with discrete values or a combo box, but this is something that we can discuss later when we redesign that window. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] New option Use custom quality settings for JPEG files
As discussed last month, the JPEG save dialog will now help you to pick more appropriate quality settings if your image was originally loaded from a JPEG file. Two weeks ago, I modified the jpeg plug-in so that it detects and saves the quality settings when loading a JPEG image. This includes the overall quality level, the subsampling parameters and the quantization tables if they are different from the ones that can be generated by the IJG JPEG library. The quality level and subsampling parameters of the original image will be used as initial values when saving the image if they are better than your default settings. Since Friday, I added a new option to the JPEG save dialog: Use custom quality settings. If some quantization tables were attached to the image when it was loaded, then this option allows you to use them instead of the standard ones (different quantization tables are generated by the IJG JPEG library for each quality level). If you have only made a few changes to the image, then re-using the same quantization tables will give you almost the same quality and file size are the original image. This will minimize the losses caused by the quantization step, compared to what would happen if you used different quantization tables. The following table shows several examples of JPEG files that I re-saved using three different settings: - default GIMP settings (quality 85, chroma subsampling 2x2), - similar quality and sampling parameters (detected from original), - with new option custom quality settings (re-use quant. tables) The colums in the table show the mean difference in value for all pixels of the image, the maximum difference in value, the size of the DCT compressed data saved on disk (excluding comments, thumbnail and metadata) and the relative difference in size. Mean diff. Max diff. Size on disk Nikon D70 (Fine) - 3008x2000 2521329 - Default2.121575341 -77% - Quality 98, sampling 2x1 0.6 6 2377909 -6% - Custom quantization tables 0.2 5 2471203 -2% Nikon D70 (Normal0 - 3008x2000 3394771 - Default3.631 1301350 -62% - Quality 97, sampling 2x1 0.410 3256047 -4% - Custom quantization tables 0.410 3255992 -4% Canon G5is (Superfine) - 3264x2448 2985249 - Default2.939899083 -70% - Quality 95, sampling 2x1 1.414 2373022 -21% - Custom quantization tables 0.311 2949326 -1% Sony DSC-D700 (Fine) - 1344x1024 676492 - Default3.361175496 -74% - Quality 97, sampling 2x1 1.418603643 -11% - Custom quantization tables 0.517636818 -6% Photoshop (Save for web 100%) - 500x333 112425 - Default3.245 32624 -71% - Quality 98, sampling 1x1 0.9 7110693 -1% - Custom quantization tables 0.2 5121285 +7% Photoshop (Save for web 3%) - 921x921 102471 - Default0.615173831 +70% - Quality 45, sampling 2x2 2.517138955 +35% - Custom quantization tables 0.0 9112797 +10% SonyEricsson K750i (Fine) - 1632x1224 510916 - Default3.936539013 +5% - Quality 76, sampling 2x1 0.735507275 -1% - Custom quantization tables 0.128507543 -1% These examples show that re-using the same quantization tables as the original image minimizes the differences in the image and produces almost the same file size. Editing images in a lossy format such as JPEG is not recommended, but at least this new feature allows you to minimize the quality degradation in case your source images are not availabe in a lossless format. As far as I know, this ability to re-use custom quantization tables is unique to GIMP. Even Photoshop does not allow you to do that easily. Some command-line programs such as IJG's cjpeg allow you to supply your own quantization tables, but this is not as convenient. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor
On Fri, 13 Jul 2007 22:42:29 +0200, [EMAIL PROTECTED] wrote: On Fri, 13 Jul 2007 20:49:49 +0200, [EMAIL PROTECTED] wrote: I fail to see how I have misused the term default in any of this explanation. [...] When an image already has a value for jpeg_quality , or any other paramter, replacing this is not providing a default it is a forcing. I hope that you both read the message in which I was suggesting to use the terms default, original or current depending on where some values come from. As I explained in that message, the original value (read from the file) will usually override any default value (coming from GIMP or from the plug-in). However, some plug-ins do not even attempt to read the original value for some parameters because for some file formats it does not make sense to re-use the same values as in the original file. For JPEG quality, I think that it is best to do as in Tor's patch: if the original value is higher than the default, then use that. Otherwise, use the default so that the user is not surprised to have a file saved with a lower quality than expected. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
On Wed, 11 Jul 2007 19:04:59 +0100, David Marrs [EMAIL PROTECTED] wrote: As an experiment at work I decided to work on just the one image when saving for web and found that I really don't need to do the spot comparisons between images after all. What's more important is the ability to change the quality of a jpeg with minimum faff. It turns out that PS's save for web has a couple of flaws in this regard: [...] I think that Photoshop also does a couple of things in the right way and I would like to confirm that but I do not have access to PS. Besides allowing you to quickly check how changes in quality affect the final output size, it also automatically changes the way a file is saved compared to a normal Save. I remember reading somewhere that Save for Web was automatically discarding metadata that is not useful for the web and also allowing you to easily omit ICC profiles and other things that increase the file size (assuming that web browsers use sRGB). It would be nice if you or any other Photoshop user could confirm that Save for Web automatically discards metadata. I am almost sure that it discards XMP and probably EXIF (at least the thumbnail), but I am not sure about IPTC. So if you have an image that contains metadata such as copyright, author, location, all camera settings and so on, please try to save it with Save for Web and reply to this list saying which of these fields are preserved in the final output and which of these are discarded. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Let me also try to keep this (relatively) short. I'm not good at this. :-) On Thu, 12 Jul 2007 13:29:49 +0200, peter sikking [EMAIL PROTECTED] wrote: I take the vision as broad as it can be explained (it was phrased not so specific for a reason), but not broader. That's certainly fine. But if you only check the comments that you have made in the last two days in this thread, you will see that you have emphasized several times the term high-end. Specifically: 'High-end' is the word I want us to focus on. This means focusing only on a minority of GIMP users. And as I wrote earlier, I am convinced that it's the best thing to do as this is the best way to have real progress. However, we should still be careful about what these improvements (or changes, in general) mean to the majority of our users (those who do not fit in the high-end definition). This is at best a small percentage of the current GIMP users. [...] But we have to acknowledge that the vision (or the way we use it) is targeted mainly at a minority of users. This minority is almost certainly the most interesting subset o I do not believe that. You do not believe that this minority is the most interesting subset or that it is a minority? Assuming the latter, I am sorry but I believe that the vast majority of GIMP users are not high-end users. Most users do not use GIMP every day, probably not even every week. But the cumulative time that all those users spend using GIMP is probably much larger than the time that the few experienced users who need and use the high-end features spend with GIMP. So I would like GIMP to focus on high-end features as much as possible according to our vision. But if some of the required changes imply a significant regression for the majority of the users, then we should think twice about them. The changes can still be applied even if they add a cost for some users because it is impossible to please everybody, but we should keep some balance and not always focus exclusively on the experienced users. And I thought that we all understand that there is a choice of several free software programs out there for users who want to do simple red-eye removal from their holiday jpegs. Unfortunately, until that choice really exists this is a moot point. we agreed at the vision meeting that the choice is there. This was mentioned, but there was some disagreement (well, at least during the part of the meeting that I attended - I missed the discussions on the second day). There was certainly an agreement on the fact that GIMP cannot do everything for everybody and that some other programs should fill the niches that we do not cover. But I don't think that there was ever an agreement on the fact that the choice is there (last year during the meeting, or even today). I could not agree with that because there is no real choice among free software for browsing and doing simple adjustments on holiday pictures. There is currently nothing that comes close to Photoshop Elements or even to the various simpler programs that come bundled with most cameras. As I wrote, F-Spot is coming close for some features (and some of the important ones have only been added in the recent months), but it is still necessary to complement it with GIMP or Krita for some operations such as correcting some errors with the clone tool, doing finer color adjustments or just rotating the image a bit. Nothing very fancy nor high-end, but this is still something that people use GIMP for. This may change in the future if F-Spot or others get better, but I doubt that it is part of F-Spot's vision to include things such as our paint tools or transform tools. Yet this is something that some users expect to find in Free Software because they can do that with the free but proprietary stuff that they got with their cheap point-and-shoot digital cameras. I just don't want to forget about these users too early, even if they are not the ones we try to please first. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Thu, 12 Jul 2007 14:31:16 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: Let me also try to keep this (relatively) short. I'm not good at this. :-) I could have made it much shorter. Summary: 1) Our vision focuses on a minority of GIMP users (experienced users, or those who need high-end features). And that's a good thing because it helps us to have a clear direction. But we must still balance that with the interests of the majority whenever possible. 2) There are still many simple usage scenarios that are not covered by any other program (free software), so there is no real choice besides GIMP for many users. Wow, I can write something in less than ten lines. :-) -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] default vs. original vs. current settings
On Thu, 12 Jul 2007 23:29:01 +0200, [EMAIL PROTECTED] wrote: If there is an image specific value you do not need a default. overriding a default with an image-specified value is a contradiction. This reminds me about something that should be clarified... For all these parameters that affect how an image is saved, where do these various values and defaults come from, and how to name them? I propose the following terms (feel free to propose something else if you have better ideas): default, original and current values. This is a slightly expanded version of the comment #14 that I added to bug #63610 in 2003; in that comment I forgot the original setting. 1) The default setting is the one that is hardcoded or configurable in GIMP or in one of its plug-ins. Sometimes the default value can be empty or not set. Some examples: a default image comment can be configured in the Preferences, the JPEG plug-in uses a default quality setting of 85, GIF does not interlace the file by default, etc. The default setting applies to all images. 2) The original setting is the one that is found (or not) when an image is loaded from disk. For example, an image file may include a user comment and this comment will be preserved when the file is saved later. The original setting only applies to that specific image. 3) The current setting is whatever is currently associated with one specific image. Once it is set (coming from the default or original setting), it will always be used whenever this image is saved. It can usually be changed by the user in the dialog window of the file plug-in. In theory, these parameters should work like this: all new images or images loaded from disk get the default setting except if some files have an original setting, which is then used instead of the default one. This then becomes the current setting, which is associated with that image every time it is saved. In practice, there are several exceptions due to implementation details or leftovers from the past. For example, the current setting may not actually exist until the file is saved (it only exists once the save plug-in creates it). But there is a bigger problem that I mentioned in bug #63610. There is a confusing historical feature that introduces another source of settings for some parameters: 4) The session setting is a side-effect of the fact that file plug-ins currently behave like other plug-ins (filters). This is a value that is set the first time you save a file in a specific format and that will affect all other images that you save during that session (until you quit GIMP). This behavior is appropriate for filters but is confusing and dangerous for file plug-ins. The problem with session settings is that something that is changed when saving one image can trigger unexpected changes in all other images. For example, you use Save As to save an image using lower quality settings for testing, but you do not see that from then on, all other images that you save (normal Save) in the same format will also use that lower quality instead of using the default value. IMNSHO, the right way to fix bug #63610 is to provide an easy way for all file plug-ins to save and reload one or more sets of default values and then forbid all file plug-ins from using session settings (save_args or save_vals or whatever the array of saved GimpParamDef is called in each plug-in). In fact, removing the usage of session settings could already be done right now in all file plug-ins, even before having a nice library for file plug-ins that would provide a unified way to save and load default values. This would solve one of the problems that has started this long thread about the JPEG quality factor: saving one image in low quality will not cause other unrelated images to be also saved in low quality. The other improvement that can be implemented without waiting is to read or compute the original quality from JPEG files and to use it if and only if it is better than the default quality. I am working on a simple extension of the nice patch that Tor provided a few days ago. -Raphael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 12:29:23 +0200, peter sikking [EMAIL PROTECTED] wrote: creating interaction requires making hard choices, because you cannot make an application for everybody. For that you use the product vision that you set as a team at the beginning of the project. And then you don't fudge when the moment is there. I would like to temper this a bit (not agent provocateur as gg, but maybe devil's advocate): a team that is too rigid about its vision and never adapts it over time runs a real risk of becoming irrelevant after a while. On the other hand, having no vision at all or ignoring it and running like headless chicken is usually worse. You make hard choices about which features to include and which not. Which workflows to actively support and streamline, and which go on the back seat. About beginners vs. Experts. But one should always balance the interest of the few who are targeted by our product vision with the interest of the majority of the users who are not necessarily part of that vision. In other words, a decision that provides a small improvement for the target users but implies a significant regression for all other users should be considered very carefully. Our current vision is rather elitist. This is not a bad thing because this is often the only way to make real progress. But we should also be aware of its consequences. Sven did not set the product vision, the GIMP team did by consensus. I only moderated that session. But I am here to implement that vision on an user interaction level. Again, to temper things a bit: this was only a subset of the developers present at LGM last year (GIMPCon 2006, see the minutes at http://developer.gimp.org/gimpcon/2006/ and read the section GIMP Vision). I hope that this was a representative subset of the GIMP contributors (of course it was, I was there!) but we should also keep in mind that nobody has absolute authority over the GIMP project. It is always possible for someone to propose someting that goes against the current consensus and hopefully convince others that this is the right thing to do. This may be good or bad depending on the context (it should also be possible to stop useless arguments by saying that something is out of scope for GIMP). I am not judging the merits of the way we work, but just stating that this is something to keep in mind. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 16:32:11 +0200, peter sikking [EMAIL PROTECTED] wrote: Raphaël wrote: I would like to temper this a bit (not agent provocateur as gg, but maybe devil's advocate): a team that is too rigid about its vision and never adapts it over time runs a real risk of becoming irrelevant after a while. On the other hand, having no vision at all or ignoring it and running like headless chicken is usually worse. I agree that a product vision, like a national policy, should be reviewed every, say, 5 years. Do realise that when you chance the the vision, that you restart, from zero, a process that takes about 5 years. And thanks for saying that ignoring the vision is worse. We also have to be humble and remember that writing down the current vision only took us a couple of hours, not 5 years (basically one hour of discussion at LGM plus some e-mail exchanges while we were polishing the minutes). Again, I am playing the devil's advocate here, just trying to counter-balance your argument: I agree with the vision and I think that we should all follow it; however, I also want to be realistic and not see it as a sacred thing that is cast in stone. But one should always balance the interest of the few who are targeted by our product vision with the interest of the majority of the users who are not necessarily part of that vision. Few? there are millions of users within our vision out there. And if we work to make GIMP represent this vision coherently in the UI, then GIMP will become a viable, natural choice for the people we want to use it. Sorry, but I have to disagree here. If you just look at the part of the product vision that says GIMP is ..., then it could apply to a large number of GIMP users. But if you look at the context of the vision (which is not explicitely written in that section, but is part of the Targeted user base in the meeting minutes and the user scenarios + expert evaluation on gui.gimp.org), then it is clear that the vision is targeted at experienced, professional users. This is at best a small percentage of the current GIMP users. As I wrote elsewhere, our current vision is rather elitist (the vision itself or how it is usually referred to). Again, there is nothing wrong with that because this is usually the only way to have real progress. But we have to acknowledge that the vision (or the way we use it) is targeted mainly at a minority of users. This minority is almost certainly the most interesting subset of our users, but it is a minority nonetheless. And I thought that we all understand that there is a choice of several free software programs out there for users who want to do simple red-eye removal from their holiday jpegs. Unfortunately, until that choice really exists this is a moot point. Basically, there is currently no good free software alternative to Photoshop Elements or even to the simple program (proprietary, Windows-only) that was delivered with my camera and allows one to quickly browse images, correct red eyes, exposure or color casts, crop/resize images and view/edit metadata. F-Spot comes very close to doing all that, but still has some weak spots that require you to use GIMP, Krita, mtPaint or Paint.NET for adjustments. Many of the quick actions provided in Photoshop Elements (which comes bundled with some cameras) are not available in any free program yet. Again, I am not saying that we should do all that and try to solve all problems in GIMP. I prefer to stick to the current vision. I am just continuing my devil's advocate role and stating that you should not claim that there is a choice when the choice does not really exist. In other words, a decision that provides a small improvement for the target users but implies a significant regression for all other users should be considered very carefully. Actually in this case it the other way around. There is a significant improvement for target users, with clarification of image degradation of everyone, and little or no regression for the lossy-jpeg users. We seem to disagree on that, but maybe it is better if I address this point in a reply to your previous message. Again, to temper things a bit: this was only a subset of the developers present at LGM last year (GIMPCon 2006, see the minutes at http://developer.gimp.org/gimpcon/2006/ and read the section GIMP Vision). This is a slippery slope. If anybody can excuse themselves from the vision when they personally do not like the logical outcome of applying it to a hairy UI design question, and bang in their yeah, but what about me feature into svn, then we are back at the headless chickens state. Unfortunately, you skipped the part of my message in which I wrote: It is always possible for someone to propose someting that goes against the current consensus and hopefully convince others that this is the right thing to do. The last part (convincing others) is important. Making
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking [EMAIL PROTECTED] wrote: There is also a real benefit in opening a jpeg and then saving the result in another (GIMP) file. We see from the explanations in this thread that opening a jpeg and then saving it again means a loss of information. So overwriting an original is a loss. Working on a full-fidelity copy version is preferred. Note that in the workflow that I described, I never mentioned overwriting the original. On the contrary, I said that the final JPEG file would be saved under another name. The early part of this thread is full of misunderstanding at which point working with jpeg incurs quality loss. I say it is because of the you can work in jpeg myth. I am still confused that you talk about saving intermediate results while working on a jpeg. Either each save reduces quality (implicit save and reload, ouch) or there is a penalty for closing the file and reopening it, because you lost the full-fidelity internal (GIMP) representation, ouch. I am not sure about what others had in mind in this thread, but I I was mostly focusing on corrections to the source photos such as correcting the exposure or color balance and making other minor edits with the clone tool, etc.. These steps can be performed in a single session without having to save any full-fidelity internal representation. When I mentioned saving intermediate results, I meant saving copies of the image that you are currently working on, if you want to check how the final output will look like (including losses due to compression). If you intend to work further on the image or to re-use some parts of it in a collage or in a more complex work, then it certainly makes sense to save the XCF version (or any other lossless format). The same applies if you work more than a few minutes on the image and it would cost too much to re-do these changes from the original in case you decide some weeks later that you need to apply more changes to the image. But for the simple workflow that I described (which is or was rather common for me), in which simple corrections have to be applied to a large number of images without intending to work on them further, then it makes sense to have JPEG as input and as output without wasting time or space with intermediate formats. So I see real benefits for a high-end image manipulation program that lossy formats are pushed out to the very beginning and very end of the workflow. That the working copy of the file is GIMP format, in full fidelity, any GIMP operation naturally possible, and with no penalty for opening and closing the file. I am not disputing that. We should encourage users to use the lossless XCF format for all things that may need to be edited later or re-used in other images. As long as this can be done without breaking common workflows, then it's fine. I don't mind if the simple load-edit-save cycle for JPEG images produces a warning the first time I do that, telling me that saving in JPEG will result in a quality loss and recommending XCF for saving any work-in-progress. But would mind getting this warning every time or being forced to use a different menu option than the normal Save for the second and subsequent attempts at saving the image. This is how I interpreted your initial reaction. If I misunderstood what you meant and you did not intend to break the flow, then I am sorry for the misunderstanding and we can forget about it because there is really no issue. -Raphaël P.S.: If this issue is cleared and we ignore the arguments for the sake of argumenting (my previous message), then I think that I have a solution for the original issue mentioned in this thread: this is very close to the patch proposed by Tor and it also supports JPEG files that were not created by libjpeg. More about that later, when my code is ready. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 18:26:38 +0200, Michael Schumacher [EMAIL PROTECTED] wrote: Von: Raphaël Quinet [EMAIL PROTECTED] We also have to be humble and remember that writing down the current vision only took us a couple of hours, not 5 years (basically one hour of discussion at LGM plus some e-mail exchanges while we were polishing the minutes). ... plus the better part of two days during the GIMP usability weekend in Essen. And this does still not take Kanila's and Peter's effort into account. I was referring to the vision, not to the use cases. But you are right that a lot of work was also invested in the usability aspects derived from the vision, and Peter and Kamila should of course be credited for that. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Tue, 10 Jul 2007 09:51:24 -0700, Akkana Peck [EMAIL PROTECTED] wrote: Another thing I'm unclear on in this thread: when I first heard the idea of forcing Export instead of Save, the plan seemed to be that Save would always save XCF, and anything else would require Export. But now you seem to be telling us that the issue is lossiness, and the point of Export is to make it more hassle to save to lossy formats, to discourage use of those formats. Does that imply that Save will include PNG, TIFF and other non-lossy formats? If you consider the whole image (including layers, metadata, etc.), then the only lossless image format is XCF. All other formats drop some information: PNG cannot save layers, TIFF cannot save all GIMP parasites, etc. In fact, even the current XCF loses some information if you consider that it does not record the full undo history and the current tool contexts, but this is something that most users accept. So I think that the statement from Peter that singled out indexed image formats and JPEG was slightly misleading (and this triggered my initial reaction). Basically, only XCF would be saved and all other image formats would be exported. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Mon, 9 Jul 2007 17:32:29 +0300, Tor Lillqvist [EMAIL PROTECTED] wrote: Sven Neumann writes: If someone wants to try to recover some of the JPEG save settings when loading the JPEG file, feel free. I did. Thanks for this very nice patch! It would be even better to do the same for the chroma subsampling method (easy) and for images that do not use the standard IJG tables (a bit harder, but it can be guesstimated). This would provide a better default value in the JPEG Save dialog than the hardcoded value that we currently have (even if that value can be customized to some extent). I also like the fact that it will only use the estimated value from the file if it is larger than the default. It is nice to be able to adjust the parameters in the Save dialog starting from a value that is reasonably close to the original settings when the file was created, instead of always starting from a fixed value. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Mon, 9 Jul 2007 17:54:29 +0200, peter sikking [EMAIL PROTECTED] wrote: guys, what a thread. I say that the solution for all this lies in treating these lossy (my spell-checker proposes lousy) formats the same we are (gonna) handle indexed mode: import + export only. Eek! That would significantly break the flow for what must be the most common image format for photography. I prefer the current behavior in SVN, in which you get the dialog for the first time you select Save, but subsequent saves of the same image (while you are still working on it) will not force you to pick a new file name and validate the parameters again. I have hard time believing that the reason a file is jpeg on your camera memory card is the same as being jpeg at the end of your workflow in GIMP. Afterwards it is about saving space on your disk or saving bandwidth on the internet. Different requirements == different quality factor, I say. Before I started shooting only in raw format (so before I bought larger memory cards for my camera), I shot a lot of JPEG pictures. I kept them all as they came out of the camera. But some of them required editing, such as removing red eyes or correcting obvious color casts. In these cases, I stored the edited images next to the originals (with a slightly different file name like dsc0042_edited.jpg) and I was interested in getting files that were about the same quality and size as the unedited ones so that they somehow fit in my collection. Making them fit (having similar size/quality tradeoff) is not really a major concern, but I still took the time to experiment a bit with the sliders until I found out that for most of my photos, using a setting around 92-94 was reasonably close to what the camera produced. This value did not work for all photos because some of them were shot with different camera settings, but at least that was a good estimate for most of them. If the patch provided by Tor was extended to support quantization tables produced by other software than libjpeg (by finding the closest match), then it would reduce the amount of guesswork. Side note: as suggested by Sven in #gimp, I just had a look at ImageMagick to try and find out how they retreive or guess the quality settings from JPEG files. The code is about 100 lines long and can be found in ImageMagick-6.3.5/coders/jpeg.c, around line 830. It is based on a comparison of the difference produced by the quantization tables in the file with the 100 possible tables produced by libjpeg. If no exact match is found, then the closest one is selected. They use pre-computed hashes and sums for the libjpeg tables in order to speed up the comparisons. The license of ImageMagick is compatible with the GPL so we could even consider re-using their code. We would only have to include their license with the jpeg plug-in. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP project leadership (was: about carol)
Hi Louis, On Fri, 22 Jun 2007 08:38:59 -0400, Louis Desjardins [EMAIL PROTECTED] wrote: Isn't there a way on the channels (IRC, bugtracker, mailing list) to simply restrain the access to a specific individual when things get to a point where repetitive demands and persuasion don't seem to give any results? This is not so simple, in part due to the way the GIMP project is organized (or not) :-). Short recap for those who are not familiar with the project: - When it comes to the code, neo (Sven Neumann) and mitch (Michael Natterer) are by far the most active developers. They have the final say on most technical decisions. Have a quick look at the ChangeLog and you will see which names appear frequently. Like many free software projects, GIMP is like an informal meritocracy, so those who contribute more have more authority over the technical aspects of the project. - But when it comes to the infrastructure such as the IRC server ircd.gimp.org, the web servers, the mailing lists and the gimp.org mail server and user accounts, yosh (Manish Singh) owns or operates most of it. He is also an active developer. Since he is the administrator of these servers or services, he is the only one who can restrain access to these channels. - In the past, we had several proposals for setting up some kind of code of conduct or guidelines for participation in the project. There were also some proposals about what to do when someone misbehaved. But these proposals were never formally approved and were never enforced. I think that the last attempt was initiated by bolsh (Dave Neary) before he decided to quit the project, mostly because of Carol. Of course we have some guidelines such as the List Etiquette published on our web site (http://www.gimp.org/mail_lists.html) and some IRC rules on our wiki (http://wiki.gimp.org/gimp/Irc). But these are recommendations and they are rarely enforced. Usually, Yosh has been swift in blocking access to people who misbehaved on this mailing list or on IRC, except for Carol. There are several reasons for that, including some that are related to Carol's past situation, but I don't think that it is up to me to explain them. I probably do not know half of these reasons anyway. Yosh has mentioned in a previous message that it will take him a bit more time to state his opinion on this matter and I respect that. Since he is the only one who can enforce any decision, there is not much point in arguing about Carol and continuing this discussion until he explains what he intends to do (and why, maybe). Let's face it, I realize this is pretty unusual and must very rarely happen but there is a possibility that someone else steps in one day with the same behavior. While there are of course no ways to prevent this upstream can we at least make sure there are ways to prevent this person from being in contact with the community once the problem has been clearly identified? I really wish we can sort this out because this might happen elsewhere in any other project. It is not an exclusivity of the gimp team! The problem that we have been facing with Carol for several years is quite unusual, and as far as I know, exclusive to the GIMP team (alas!). In part because Carol's behavior is rather unusual: sometimes she tries to help, sometimes she tries to mislead people, sometimes she harrasses people. And in part because we never took any effective measures against her, contrary to other annoying people who disturbed the project and were quickly excluded from this list or kicked from IRC. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about carol
On Thu, 21 Jun 2007 12:51:50 + (UTC), Daniel Pisano [EMAIL PROTECTED] wrote: Mukund Sivaraman muks at mukund.org writes: If there are anyone who know her personally and are nearby, please get her medical attention. Yes, please. Her condition is serious. You both raised several valid points about Carol's unacceptable behavior. However, it would have been better to avoid stating on a public mailing list that she needs medical attention (regardless of whether it is true or not). These comments should have been private. They can easily be perceived as an insult and they weaken your other arguments because you are attacking her person instead of her behavior. I still have some respect for Carol as a person and her medical condition is none of my business. However, her behavior is not acceptable and it has a negative impact on the project and its developers, as can be seen from the comments posted here. I just want her to stop doing what she is doing to the project; I do not care about the rest of her life. Considering that she did not stop despite numerous requests over the years, Sven is right in that some administrative action is required now. And as sad as it might be, she should also understand that her actions resulted in her not being welcome anymore. She used to be a member of the GIMP community, but not anymore. She should try to find some other people who welcome her, preferably in real life and not online. -Raphaël P.S.: I'll stop patronizing now. I also have my bad habits... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about carol
On Tue, 19 Jun 2007 09:01:46 +0200, Sven Neumann [EMAIL PROTECTED] wrote: I don't know if everyone of the GIMP development team is as annoyed of Carol as I am, but I know that there are quite a few people who are. As I have been involved in several incidents with Carol some years ago, I should probably comment on this. For a while, I felt responsible for all the bad things happening to Carol. I still feel sorry about what happened in 2003. But I cannot feel responsible for what Carol has been doing since then (which is not very different from what she did before anyway). Also, I used to be upset whenever Carol was posting nasty comments on IRC or on the GIMP mailing lists. I have learned to ignore the negative comments and only pay attention to her useful contributions, but newcomers and casual contributors do not have the opportunity to know this in advance. It was a pleasure for me to meet Carol at LGM last year and discover that we can have friendly face-to-face conversations. This is something that I appreciated very much. Unfortunately, this does not seem to be the case online: her negative messages or gibberish on IRC or by e-mail have discouraged more than one contributor. So while I thank Carol for her contributions to the GIMP web site or for her own web site and tutorials, I think that her behavior online has brought more harm than good and has seriously hurt the project. I am not sure about the best way to handle this because I hate excluding people, but preventing her from harrassing others on IRC and removing her op access would certainly be a good start. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what, no prog?
On Wed, 20 Jun 2007 20:04:01 +0200, [EMAIL PROTECTED] wrote: make maintainer-clean ./autogen.sh It would be a good idea to check the contents of config.log at this point (or later). In particular, check that the --prefix argument was correctly passed to configure. You will find how configure was invoked in the first few lines of config.log. make make install Maybe it is a stupid question, but did you check that both make and make install were successful? If yes, did you at least check the last dozen lines of output from make install to see where stuff was being installed? -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is there any thought of layer blending in the future?
On Thu, 12 Apr 2007 21:42:28 -0500, Jim Sabatke [EMAIL PROTECTED] wrote: There is an excellent tutorial on using PS to do this at: http://www.luminous-landscape.com/tutorials/glow.shtml This would be VERY useful in gimp. Has here been any consideration of this functionality? If you are looking for a quick soft glow effect, you can use Filters - Artistic - Soft glow (in GIMP 2.3.x). But if you want to follow the tutorial step-by-step and if you really want something like adjustment layers, then you should look at this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=79025 -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] LGM: top-10 feature requests...
On Fri, 13 Apr 2007 16:47:30 +0200, peter sikking [EMAIL PROTECTED] wrote: To keep it interesting for the GIMP crew and the users in the audience, I would like to centre this around the top-10 most requested features in GIMP. You know the ones that make your eyes roll when they get posted here or in bugzilla, again, and again, and again. Of course I am looking for the ones that are UI related, so 16-bit color is not interesting, but adjustment layers is. Please help us to make this list by suggesting these top-10 bugs. Well, this is not exactly a top-10 list because some of them have sub-cases, but hopefully you can get something out of this list. I tried to order this with the most important first. 1) (by far) Single window interface, a.k.a. MDI. Note that there are two cases (Window-in-window MDI and Tabbed MDI) that are probably mutually exclusive. Each option has its advantages and drawbacks, and each has its supporters who usually reject the other proposal: 1a) http://bugzilla.gnome.org/show_bug.cgi?id=7379 1b) http://bugzilla.gnome.org/show_bug.cgi?id=121087 2) Adjustment layers http://bugzilla.gnome.org/show_bug.cgi?id=79025 3) Layer trees or layer groups http://bugzilla.gnome.org/show_bug.cgi?id=86337 4) Avoid popup dialogs for tools, file plug-ins, etc. http://bugzilla.gnome.org/show_bug.cgi?id=85579 http://bugzilla.gnome.org/show_bug.cgi?id=319963 5) Organize brushes, palettes, gradients... in categories http://bugzilla.gnome.org/show_bug.cgi?id=119874 ...and make it possible to delete or hide the default ones http://bugzilla.gnome.org/show_bug.cgi?id=118742 6) Save for web http://bugzilla.gnome.org/show_bug.cgi?id=98017 7) Better printing support (colors, one image on multiple pages, multiple images per page, ...) 8) Improvements to the text tool 8a) Support for multiple styles (font, size, color, ...) http://bugzilla.gnome.org/show_bug.cgi?id=122706 8b) Applying transformations on text http://bugzilla.gnome.org/show_bug.cgi?id=125144 8c) Text along path http://bugzilla.gnome.org/show_bug.cgi?id=169616 8d) Adjustable letter spacing http://bugzilla.gnome.org/show_bug.cgi?id=331952 9) Painting with natural brushes / simulate natural media http://bugzilla.gnome.org/show_bug.cgi?id=65118 I probably forgot some, but I suppose that you will get several lists so you can have fun merging them. Note that I did not list several frequently requested features that have only a minor impact on the user interface, such as support for 16-bit colors (as you mentioned), support for spot colors, better color profiles, better metadata support, etc. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] One-click binary downloads via the gimp website
On Tue, 10 Apr 2007 16:34:45 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Thu, 2007-03-29 at 11:39 +0200, Raphaël Quinet wrote: Providing a one-click download button is unlikely to cause more problems or confusion. In my opinion it would. Users wouldn't know where to get information about the installer they just downloaded or where to report problems with it. Why wouldn't they know? They visit www.gimp.org to get their software, so it makes sense that they also look around on that same site if they want to get information or to report problems about what they just downloaded. Currently, even if they download the binary package from SourceForge, they will anyway have to go back to www.gimp.org if they want to get the information about how to use Bugzilla to report bugs. And since we discussed previously the opportunity to move the installer FAQ to gimp.org (if Jernej agrees), the users would find everything they need on the web site. We should IMO keep a Download button and we should try to figure out the user's operating system to make it as simple as possible to get to the page where we explain that the GIMP team only provides the source code and where we point people to the binary installer. We should also encourage Jernej to provide a single installer for GTK+ and GIMP. Regardless of what we say about it, people do not care if the team provides only the source code. As I mentioned previously, the Windows package built by Jernej is considered as the GIMP package by most users and they probably do not know that the only official package from the team is the source code. And IMHO, they shouldn't even have to know. Most Linux users know that when a new package is released (GIMP or any other software), this usually means that a new version of the source code is out and they either have to build it on their own or to wait for their favorite distro to update their package. Windows users and MacOS X users do not have the same expectations: they expect to be able to download and install the software immediately. If the Windows binary package is not available, then the software is not released yet. Since Firefox was cited as an example at the beginning of this thread, I think that we should follow the same example and try to have installers for Windows and MacOS X (if possible) ready when we announce a new stable release. Other packages that are less popular than GIMP or Firefox follow the same model, so why couldn't we help our users in the same way? I know that this is a change compared to our current policy and it also raises some practical problems if we want to have packages ready on time (more pressure on Jernej...) but I think that it would be better for the (Windows) users than sticking to the current policy we only release the source code. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-Developer] One-click binary downloads via the gimp website
On Thu, 29 Mar 2007 00:29:26 +0100, David Marrs [EMAIL PROTECTED] wrote: It was suggested on the gimp-web mailing list that we could provide direct links to binary packages for popular platforms such as Windows or Mac, based on user agent detection. The link would be provide from the home page - see http://next.gimp.org/ for a taster. I liked the proposal (presuming reliable packages for 2.4 are made available) and can provide the necessary code. Sigh! That reference to next.gimp.org should not have been mentioned outside the gimp-web mailing list. It's not a secret (anyone is free to join the gimp-web list or the discussions on IRC) but we should make sure that the new design is not discussed too early on various blogs or web sites, otherwise this would ruin the effect for the 2.4 release. So if you have visited that site and you want to comment on it, please limit your discussion to the gimp mailing lists or IRC channels, but do not spread this URL before 2.4 is released. Thanks! -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-Developer] One-click binary downloads via the gimp website
On Thu, 29 Mar 2007 08:20:58 +0200, Sven Neumann [EMAIL PROTECTED] wrote: [...] But if there's a download button on the front-page that directly instantiates the download, then we are effectively providing binary packages. It doesn't matter if the packages are hosted elsewhere. To the user it will appear as if we would provide the binaries. I don't think that it would be a problem. Over the years, Jernej's installer has evolved into something that can only be described as an official package for Windows. Regarless of what we state about it, I bet that most users consider it as the GIMP for Windows. Providing a one-click download button is unlikely to cause more problems or confusion. The situation may be different for Mac users or users of other platforms, but then again if the web site statistics are still the same as when I last looked at them, then the majority of our visitors are using IE on Windows. It is reasonable to think that a fair number of these visitors are interested in getting the installer for GIMP on Windows. If we decided that we want to do this, then we should probably really provide the binaries and we would have to move things like the Win32 user FAQ (http://gimp-win.sourceforge.net/faq.html) and the gimp-app bug-tracker (http://sourceforge.net/projects/gimp-app) to gimp.org and to our bug-tracker. I don't think we are prepared to do that. Moving the Win32 user FAQ to www.gimp.org may or may not be a good idea. I think that Jernej should state his opinion on that. Regarding gimp-app, I am not sure because we do not (or did not) get too many Mac visitors and I do not know to what extent they perceive the gimp-app package as official. This may change if the native GTK+ port evolves, but for the moment I am not sure that we even need to have a direct download button for Mac packages. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-web] http://perl.net.au/wiki/New_GIMP_FAQ
On Thu, 22 Mar 2007 20:57:28 +0200, Shlomi Fish [EMAIL PROTECTED] wrote: http://perl.net.au/wiki/New_GIMP_FAQ Feel free to fill in more questions and answers. Please keep it under the PD (or fork it). There's not a lot there. Thanks for the effort, but if you had looked at the recent discussions on the gimp-web list, you would have seen that a new GIMP user FAQ has already been added to the new revision of the web site. You can get it from SVN by checking out the branch v2.4 of the gimp-web module. It still needs to be cleaned up and edhel is working on it. I suggest that you join this effort instead of starting a separate version of the FAQ. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla
On Wed, 21 Mar 2007 10:41:48 -0700, Manish Singh [EMAIL PROTECTED] wrote: On Wed, Mar 21, 2007 at 08:00:42AM +0100, Martin Nordholts wrote: Though, Inkscape I think seems to have succeeded better than both GIMP and Krita (attatching new and prettier script version) Yeah, but not by much. The point being, pretty much all free software projects could use more contributors, and I don't think perceived rudeness is the primary cause of this. The Linux kernel folks are far ruder than anything that's happened on this list, but the number of contributors is in the thousands. We seem to have a rather bad reputation, though. Try the following totally unscientific exercise: associate the terms gimp developers or gimp contributors or gimp hackers or gimp admins (including the quotes) with words such as rude, arrogant, unfriendly, assholes and so on. Then count the number of pages that are found for each of these combinations using your favorite web or newsgroup search engine. Continue this exercise by taking a random sample of these hits, checking how many of them actually accuse the developers of being rude versus how many are just accidental associations due to the fact that these terms appear on the same page but in different contexts. And adjust the total number of hits according to the proportion found in the random sample (the other option is to perform an exhaustive review of all hits - good luck with that). Now that you have these unscientific numbers for GIMP, repeat the exercise for Linux developers, kernel developers, GNOME developers, Inkscape developers, and so on with Krita, KDE, Mozilla, OpenOffice... Of course these numbers have to be weighted according to the total number of hits without the derogative terms (e.g. gimp developers without rude, etc.) I did not waste too much time on this pointless exercise, but it looks like GIMP does have a bad reputation, as it comes first or second in the associations with rude, arrogant, unfriendly, etc. The Linux kernel guys are a bit more rude and the GNOME developers are more arrogant (but not so rude nor unfriendly). But overall, GIMP scores rather high. It will probably take a long time to change that perception... Note that I do not intend to continue this discussion nor to perform this silly exercise in depth. We have already discussed this long enough and I hope that we will all be a bit more careful when replying to questions or bug reports. For Bugzilla, I think that the general guideline would be to always thank the reporte, even if the bug report is not so good. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools
On Tue, 20 Mar 2007 11:28:49 +0100, Simon Budig [EMAIL PROTECTED] wrote: Joao S. O. Bueno Calligaris ([EMAIL PROTECTED]) wrote: Simon, where does that forbid one to add words like thanks, please, would and etc... to even a short answer, like a FAQ URL??? Nothing forbids that. The absence of these things does not make an answer rude though, which is the point I am arguing. The absence of thanks may be perceived as rude, especially in the context of a bug report closed as WONTFIX, INVALID or NOTGNOME... Let's take the perspective of the bug reporter: if you report a bug or suggest an improvement and your report is rejected by the developers, then your initial impression will be slightly negative. A neutral explanation may be perceived as rude because you took the trouble to find out how to report GIMP bugs, you registered in Bugzilla, you spent the time to write the bug report and the only thing you get in return is a too brief message telling you that your bug report was rejected. Contrary to what Michael wrote in another message, I like the canned replies in Bugzilla because most of them start by thanking the reporter. Although I agree that they could be improved and could include two lines about how to avoid duplicates in the future or how to find some FAQs and so on, they are good enough in most cases. These thanks help to offset the negative impression that the reporters might have after seeing their bug reports rejected or marked as a duplicates of another one. In summary, never assume that a short message is neutral. The context may lead to a negative perception of your message so it is useful to compensate for that by being more polite than usual. And yes, this may mean thanking the 100th clueless user who suggests again to support more than 8 bits per channel or to improve the user interface by implementing some kind of MDI model. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-unstable-2.3.11
On Thu, 08 Mar 2007 10:15:53 +0100, Petr Gajdos [EMAIL PROTECTED] wrote: Hi, I'm solving bug (https://bugzilla.novell.com/show_bug.cgi?id=231161 ) in package gimp-unstable-2.3.11. [...] Is it OK to replace 2 by 4 in the definition of 'values' variable? Yes, of course this is OK. Thanks a lot for reporting this bug and for providing a patch. This is now fixed in SVN, revision 22070. I am surprised that such a bug was able to hide in our code for several months without being noticed. Boo! for the developer who introduced it in the code! :-) No, I will not give any names - the culprit has already been identified and he pleaded guilty. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On Sun, 25 Feb 2007 21:01:47 +0100, peter sikking [EMAIL PROTECTED] wrote: Let's look at the user requirements: for a _moment_ you want to see what you are _doing_ at high magnification, while working on a _macroscopic_ scale. I would like to know why you state that the user requirements include showing for a _moment_ what you are doing at high magnification. If the view of the zoomed-in area does not overlap the normal work area, some users may be equally interested in seeing at all times what they are doing at high magnification so that, for example, they could detect any unusual details that are not visible at a smaller scale. Or they could be interested in seeing the high magnification area at many moments that are relatively close to each other in time so that, for example, they could precisely adjust several points in a path or iscissors curve. To me, the argument that the zoomed-in area should only be displayed for a brief moment is far from obvious. I add here that to be able to be of help, the magnified area needs to have a strong relationship (closeness) to the actual mouse position, but always needs to be out of the way. everything speaks for a key-triggered loupe. Again, this is far from obvious. You state that it always needs to be out of the way but there is no real way to ensure that it is _always_ out of the way, except by letting the user position some window in advance (which then speaks against a key-triggered loupe). Otherwise, there is no way for GIMP to predict what area close to the mouse pointer is a safe area that the user is not interested in. The user may still be interested in some context around this area in order to be able to align things, repeat some pattern, etc. during the moment that one is focussed on the detail there is plenty screen space to put a really sizeable loupe window, and it will be automatically close, but also automatically out of the way. You assume that focusing on the detail means that the user lost interest in the context. This is not always the case. If you do not let the user position the high magnification area (as would be possible with an auto-tracking view), then the key-triggered loupe would probably have to support a combination of modifiers so that the user can tell GIMP: no, don't pop it up somewhere above my mouse pointer, but rather somewhere in the lower left corner, or somewhere far to the right. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changes in script-fu in 2.3.14
On Tue, 30 Jan 2007 08:24:40 +0100, Sven Neumann [EMAIL PROTECTED] wrote: On Tue, 2007-01-30 at 09:11 +0200, Alexander Rabtchevich wrote: But the inability to use global variables along with scheme syntaxes leads to a good deal of parentheses which could be a problem to a programmer. I don't see how this introduces the need for more parentheses. Just to prove that point, a couple of weeks ago I fixed a bug in a script that looked like this: (define (some-function ...) (begin (set! undeclared-var some-value) (... more code ...) )) Fixing this problem was easy and made the code shorter: (define (some-function ...) (let ((declared-var some-value)) (... more code ...) )) -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changes in script-fu in 2.3.14
On Tue, 30 Jan 2007 16:06:00 +0200, Alexander Rabtchevich [EMAIL PROTECTED] wrote: Some more thoughts on local variables in scheme from a newbie POV. Due to a parenthesis syntaxes of variable declaration area, if variable x is declared before variable y and y is declared before x is dropped, x remains active at least until y is dropped. [...] So what? Keep in mind that premature optimization is the worst ennemy of the developer. Script-Fu was never designed to be especially efficient: it was designed to get the job done with a minimum amount of developer effort. Also, does it make sense to worry about leaving a variable and its context in memory for a little while when this variable only takes a few bytes and the data that you are manipulating is several orders of magnitude larger? Keeping an integer and its context on the stack means almost nothing in comparison with the megabytes of image data that the script is processing. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changes in script-fu in 2.3.14
On Mon, 29 Jan 2007 16:05:26 +0200, Alexander Rabtchevich [EMAIL PROTECTED] wrote: Many 3-rd side script-fu scripts, working in 2.3.12, refused to work in 2.3.14 on Windows. One of them even kills Gimp at program start. Where can I read what has changed in script-fu specifications to adapt scripts? Or has the API changed? As you can read in the NEWS file, the Scheme interpreter for Script-Fu has been replaced in 2.3.13. The old one (SIOD) was replaced by a better one (TinyScheme). TinyScheme offers a better support for the Scheme standard and for foreign languages: the old Script-Fu based on SIOD did not work well with UTF-8 strings. The old interpreter tolerated some poor programming constructs that are not tolerated anymore by the new one. The main difference is that all variables have to be declared before being used. The old interpreter allowed you to do a (set! ...) on a variable without declaring it first and without giving it an appropriate scope in a (let ...) or (let* ...). Besides encouraging bad programming style (global variables), this resulted in some namespace pollution and even in some bugs due to undetected spelling errors in variable names. The new interpreter does not accept these errors anymore, so if you have a script that was abusing set!, then you should fix the bugs in your script and ensure that all variables are given an appropriate scope using let. Maybe we should retroactively change the NEWS file and add another line to the 2.3.13 entry saying something like all variables in script-fu should be declared before being used? -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] getting 2.4 out of the door
On Thu, 18 Jan 2007 08:32:05 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Raphael, what about your status bar message changes that are supposed to go in under the string freeze? I got sidetracked by some issues with the intelligent scissors tool. I have just committed a first patch that improves the tool a bit (bug #398309) and includes some new status bar messages. I also prepared some code to fix bug #345541 (usage of modifiers in the scissors tool) and I will commit it soon. I still have to commit a slightly larger patch dealing with the status bar messages for the transform tools. I will try to commit that tonight. And what are the plans for the metadata editor? As I mentioned on IRC a couple of times and probably here as well, it would be better to schedule it for 2.6 and disable it in 2.4. I do not want to delay 2.4 because of this feature and it is unlikely that I could finish the editor in the next couple of weeks or even that someone could help me to bring it to a reasonably stable state. I will get back to the metadata editor as soon as I am done with some of the 2.4 bugs, but I think that it will take too much time to implement the missing features: finish the conversion from and to EXIF, add the conversion from and to IPTC, finish the widget re-organization, add descriptions and help messages for all XMP/EXIF/IPTC values that can be set from the GUI. Also, adding/replacing the support for metadata in all file plug-ins will require some changes in the GUI of these plug-ins. It is probably not a good idea to do that under time pressure and under a string freeze, that's why I think that postponing this to 2.6 would be the better choice... unless we do not plan for 2.4 before the summer, but I hope that we will manage to release it sooner. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] getting 2.4 out of the door
On Fri, 19 Jan 2007 14:10:44 +0300, Alexandre Prokoudine [EMAIL PROTECTED] wrote: [...] Out of curiosity, are you planning to use Exiv2 for that? Exiv2 seems to slowly obsolete libexif these days, because it reads/writes both EXIF and IPTC (IIM). It's already used by UFRaw, digiKam and Rawstudio. The code that I started writing two years ago includes a (very limited) EXIF parser and does not use libexif nor exiv2. There were several reasons for that: - The metadata editor works with XMP, which is a superset of the other metadata formats and can be extended easily. So instead of keeping the EXIF block in memory and fetching values from it on request (as done by libexif and most other libraries), the tags in the EXIF block are read one by one and converted immediately to XMP. - Libexif was very EXIF-centric (of course). The same applies to exiv2, although I did not consider it at that time. It contains lots of nice descriptions and help strings for the various EXIF tags, but many of them are not appropriate after the data is converted to XMP. For example, some separate EXIF tags are merged into a single XMP property, some others are orgnized differently and accept a different range of values, etc. - There was an explicit wish to avoid depending on libexif. Its API has changed a couple of times and broke the GIMP plug-ins. It contained several bugs that caused many bug reports to be reported against GIMP while the bugs were in the library. And the libexif code was not very clean nor easy to follow. In retrospect, given the time that has passed since then and the lack of progress on my part, maybe I should have used some library anyway. I am not sure... I did not evaluate exiv2 at that time. It shares some of the problems described above for libexif, but it seems to be structured and maintained in a better way. On the other hand, it is written in C++ instead of C and it is licensed under the GPL only. I would like to use a rather permissive license for the metadata editor so that it could be re-used in other applications. That's why I picked the LGPL for the moment, although I could even use a more permissive license as long as I am the main author of the code. Using exiv2 would introduce a dependency on GPL-only code and limit the opportunities for re-use of the metadata editor. The next version will most likely feature i18n support, and since support for XMP/EXIF/IPTC in GIMP means showing all those variables translated, reducing overhead for translators would be awesome. Exiv2.pot has over 1000 messages, so you might guess how much work it would be for GIMP translators, if they did it alone... ;-) Sure. But as mentioned above, many of these messages are specific to EXIF and may be irrelevant or inappropriate when the metadata is converted to XMP. The messages that refer to the specific encodings used by EXIF (rational numbers, date formates, etc.) would have to be replaced by different messages in the metadata editor. Besides, there are many other properties in XMP that are not part of EXIF and would have to be described, translated, etc. This includes the Dublin Core properties, the license-related stuff (Creative Commons, etc.)... Although it would be possible to fetch some of the tag descriptions from the library and have all other descriptions in the editor itself, I am not sure about how much work would be saved by that. I haven't really made up my mind yet. Maybe I should just get rid of the code that I started writing a long time ago and use some EXIF library instead. Maybe this would save some development time. Maybe not. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Wed, 17 Jan 2007 16:00:00 +0100, Thorsten Wilms [EMAIL PROTECTED] wrote: On Wed, Jan 17, 2007 at 06:36:27AM -0800, Saul Goode wrote: If the only difference is whether a mouse-click is used on the canvas or a keystroke/menu/widget action is used to invert the selection, I suspect you shall have a difficult time convincing the GIMP developers to add your concept of a drawing zone to the core and have it honored by all the paint tools. No. First it's important that it's not an additional mouse-click. Not even a click, just where the button/pen-down happens if you start to draw. Keep in mind that what you are suggesting is a rather specialized use case. Even if the concept is interesting and would save you some time, it has a cost for all other GIMP users: menu clutter, additional stuff in the UI, etc. And of course there is also a cost for the developers, not only in implementing the feature but also in maintaining it and fixing bug reports releated to this new feature and its interaction with other current or future GIMP features. So unless you can convince the developers that the concept of Drawing Zones would be useful for a significant percentage of GIMP users, you have to balance the advantages of that new feature with the (minor) disadvantages that it would cause to all other users. It looks like the best solution in your case would be to use some keyboard shortcuts for switching quickly between layers: this would have a small cost for you without costing anything to anybody else. If you work 10 hours + on an image, every click more or less counts. Especialy not having to think about any other operation but drawing is a big one. On the other hand, if you work 10+ hours on an image and if you do that on a regular basis, then you could consider using some additional input device (e.g. MIDI controller) so that you can bind some of its controls to GIMP actions. I haven't checked what is really possible with cheap MIDI controllers, but you might be able to use a pedal or something like that and switch layers with your feet. :-) -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 32bit BMP appear blank
On Wed, 3 Jan 2007 17:10:54 +0200, Aurimas Juka [EMAIL PROTECTED] wrote: This is a summary of Bug 352262 32bit bitmaps (*.bmp) appear blank ( http://bugzilla.gnome.org/show_bug.cgi?id=352262 ) which as Sven said is important to be settled before releasing 2.4 version. [...] The main question: should those bytes be ignored (as it is done by many applications) or should some workaround be used (in case we want to support 32bit bitmaps with alpha channel)? I did a quick web search to see how some applications dealt with this problem and I found a number of links to photoshop plug-ins (including one GPL program [1]) and standalone programs for converting or editing Windows .BMP or .ICO files. It should be noted that the support for the alpha channel is an extension added in Windows XP (and made partially obsolete by the usage of PNG in Windows Vista) so it is unlikely to be available or even mentioned in programs, books or official or unofficial specifications written before 2001. As mentioned on many web sites, there does not seem to be any complete and official specification of the BMP file format available anywhere. Even the documentation from Microsoft (MSDN Library) does not mention the usage of the alpha channel although it is used in Windows XP. I have not tried these programs supporting alpha channels in BMP but from their descriptions I could identify the following strategies when loading 32-bit BMP or ICO files: 1) Always ask the user if the alpha channel should be used or not 2) Use the alpha channel if and only if it contains at least one non-zero value. 3) Use the alpha channel if the file name ends in .ICO, ignore it if it is .BMP. The second strategy seems like a good compromise and would probably work in most cases (i.e., match the user's expectations). -Raphaël [1] http://www.telegraphics.com.au/svn/icoformat/trunk/dist/README.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] string freeze for 2.4
On Wed, 20 Dec 2006 09:55:44 +0100, Sven Neumann [EMAIL PROTECTED] wrote: When using a drawing tool (Paintbrush, Airbrush, or Pencil), Shift-click will draw a straight line from your last drawing point to your current cursor position. If you also press Ctrl, the line will be constrained to 15 degree angles. This works for more tools now than the ones that are listed here. Also, do we still need this tip now that we have statusbar messages for this? There are more tips that are now covered by the statusbar hints. Should they be removed? I suggest to remove the tips that are already covered by status bar messages. There is no need to duplicate these hints and most users will see the status bar messages (far) more often than the tips. Regarding the status bar messages and the string freeze, I would like to announce that I am planning to add a few more messages, mostly for the transform tools. I am planning to work on that next week. I expect that my changes will consist mostly in additions rather than modifications or deletions so hopefully they will not disturb too much the work of the translators who have already started working on the strings for gimp 2.4. I will try to commit the changes to CVS as soon as possible next week (after Christmas). -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] default setup for 2.4 comments
On Wed, 06 Dec 2006 18:36:53 -0500, Adrian Likins [EMAIL PROTECTED] wrote: Sven mention on irc the issue of choosing what the default setup for 2.4 should be. So here are some of my thoughts: 1. In the toolbox, the fg/bg color, and brush/patter/gradient boxes should be on. Maybe. But another option (mentioned in your point 2) would be to make sure that the color selector tab is always included in the default session (even when upgrading from a previous gimp version!) and that it is visible by default (first tab). In this case, I am not sure that we need the separate indicator. We can save some precious desktop space by not having it on by default. 2. Add color selector and palette dialogs to the default Layers, Channels, Paths, Undo | Brushes, Patterns, Gradient dialog that comes up currently. Yes, it should be there by default. The default left-side panel should be: Layers, Channels, Paths, Undo | Color, Brushes, Patterns, Gradients. Adding Palettes there by default could also be useful, especially with the new (and very useful) palette color picker in the color selector. 3. Change the default image size (any particular reason it is 377x233?) I'd suggest 1024x768 I'd suggest VGA (640x480) or even less, so that it fits on a 1024x768 screen. Web statistics from July 2006 show that only 19% of the users have screens larger than 1024x768. While I expect this percentage to be higher among GIMP users (maybe close to 40% or 50%?), we should still make sure that the default settings work fine on a typical laptop screen (widescreen laptops are not so common yet even if they represent the majority of the new sales in many countries). 4. Don't show the devices dialog by default. It's a bit redundant with #1, and only shows one device for most users. Right. 5. It might be nice to have the stock round/square brushes be dynamic brushes by default. (If I understand correctly, theres a small concern that this might break some existing scripts?) This has been discussed before. From my point of view, I am not concerned at all about the scripts but I am more concerned about usability aspects. The current bitmap brushes allow you to quickly switch between different predefined sizes without having to play with the brush size slider. This is not so easy to do with scalable brushes. 6. A wider selection of basic brushes would be good, especially with the #5. Agreed. Any proposals? 7. I'd like to see some high resolution brushes included, especially now with brush downscaling being easy to get to. Again agreed. Any proposals? ;-) 8. Maybe some more examples of pixmap/hose brushes. I kind of hate that green pepper and vine brush (and I made them...). Not sure what exactly yet, but I have some ideas: a. something that makes obvious use of the directional pipes would be good. b. Maybe a simple tube drawing brush (aka, a rendered sphere with the spacing set to a low value) c. Maybe a couple more (bigger) sizes of the Pencil Sketch brushes d. a wilber brush? (totally useless, but hey... it's wilber) e. a series of flipped versions of the Caligraphic Brush series Some time ago, I found some nice examples of directional brushes: one with ants and the other one with feet. Alas I don't have them anymore and I am not sure about their licence terms. But something like that would be nice to include in the default GIMP package. I have seen many PSP brushes showing random water drops, snowflakes or other things similar to the animated Sparks brush. Adding one or two of those could also be nice. These may not be very useful for graphics professionals, but it would certainly be nice for the amateur web designers or for those who want to impress their friends by creating cheezy Christmas cards with GIMP. 9. I'd turn on Save Tool options on exit by default. We have a reset to default in the dialogs if someone wants to reset the tools. Hmmm... I'm not sure about that one. I easily forget that I had lowered the brush opacity in my previous gimp session and sometimes it takes me a while to see that something is wrong. I prefer to start in a predictable state. Of course I can turn off the auto-save feature. But I am not sure about what the default should be... 10. Man, am I ever tired of those default pattern options. (Mostly my fault unfortunately). They didn't age very well. Not sure if we can do much about it without breaking scripts. We could add more without breaking scripts. On the other hand, I am not sure if it is worth it. I do not use them much anyway. 11. Ditto with the gradients, though we should probably add another example or two of using the dynamic color stuff in gradients Agreed. The first 4 gradients after the FG to BG ones are not so interesting (Abstract 1, 2, 3 and Aneurism). -Raphaël
Re: [Gimp-developer] Intro and a CVS question
On Thu, 23 Nov 2006 13:00:32 -0600, Chris Mohler [EMAIL PROTECTED] wrote: What release should I be checking out of CVS? Or stated another way - on various bug entries, I see please create a patch against current CVS. Is current CVS gimp-2-2? If no specific branch is mentioned, current CVS usually means the HEAD branch. This is what you get if you just do a cvs checkout without specifying a revision or branch (i.e., no option like -r gimp-N-N). -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Switch to Tiny-Fu, end of Script-Fu maintenance?
On Fri, 13 Oct 2006 11:42:25 -0400, Kevin Cozens [EMAIL PROTECTED] wrote: My source tree of CVS GIMP now contains a Tiny-Fu'd version of Script-Fu. The changes are available as patch files ready to be reviewed. I am now waiting on a final ok before the changes will be commited to CVS. Consider this to be a conditional OK from my side. I have discovered a number of bugs in your patches, but they can be fixed easily so I trust you for fixing them before committing them. Sven suggested I provide the URL to where I have placed information and patches regarding updating Script-Fu as some other people may wish to review the changes. The URL is http://www.interlog.com/~kcozens/software/gimp/patches/. At that location you will find a README file and three patches. The README file contains some basic information about the patch files and how they are to be used. As stated in the README, you will also need three directories and a few other files from Tiny-Fu. The total size of the patch files is about 928k. Anybody who tries to apply these patches would be well advised to pay close attention to the README file first. ;-) Maybe it will be updated to cover some of the points that I will mention in this message, but for the moment you also have to take care of the following: - script-fu.patch and wrapper.patch have to be applied from one level above your top gimp dir, or from the top dir using -p1 - But scripts.patch should be applied from within plug-ins/script-fu/scripts - The README does not mention that you also have to copy contactsheet.scm, tiny-fu-set-cmap.scm, ts-helloworld.scm from tiny-fu's scripts dir (and rename tinu-fu=* to script-fu-*) - You have to run make at least once from the top-level directory so that configure rebuilds your Makefiles (if you are in maintainer mode). You can also re-rerun autogen.sh. Once this is done, you will probably discover a couple of bugs (they might be fixed by the time you read this): - gimp-labels.scm is missing a quote at the end of lines 130 and 145 - sota-chrome-logo.scm has a e instead of ( before line 200 - Some scripts such as waves-anim.scm or spinning-globe.scm do not initialize some variables that should be initialized to 0. When you run them, you will get an error saying that or is used with an argument that is not numeric. This is easy to fix by searching for the operation or and making sure that the variable is correctly initialized to 0. Regarding the latter bug (which occurs in more than one file), this is also related to a stylistic change that I do not like very much. Basically, declarations like this: (let ((var1 (expr1)) (var2 (expr2) ...) ...) were rewritten in the following way: (let ((var1) (var2) ...) (set! var1 (expr1)) (set! var2 (expr2)) ...) I prefer the old style, especially when the expressions are relatively short. This didn't worry very much when these changes were in Tiny-Fu CVS because I thought that it would be changed back later, but now it looks like these changes are here to stay. The old style makes the code more compact and easier to read (IMHO). Besides, my old LISP professor told me to avoid (set! ...) whenever possible and claimed that LISP machines worked better when the declarations were in the (let ...). I have never verified that dubious claim, but I still try to avoid set! whenever possible. Anyway, I assume that these bugs will be fixed soon because most of them are rather minor. Once they have fixed, you have my OK for committing (unless someone else objects). I will probably be away for about one week so I will not be able to comment further on this in the next few days. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Switch to Tiny-Fu, end of Script-Fu maintenance?
On Thu, 05 Oct 2006 20:15:58 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Thu, 2006-10-05 at 10:10 +0200, Raphaël Quinet wrote: From my point of view, Tiny-Fu is now ready to replace Script-Fu and I would like to encourage everybody to make the switch so that we can fix any remaining bugs. Considering that Tiny-Fu solves some real problems (i18n), the sooner we can do the switch, the better. [...] Then, I would suggest that instead of ending maintainance of Script-Fu that we switch the Scheme interpreter in Script-Fu to tiny-scheme. Instead of removing our only platform independent language binding, we should apply the changes that Kevin has done in the gimp-tiny-fu module to the plug-ins/script-fu directory in the GIMP tree. [...] Yes, that would be the best solution. In restrospect, I think that it was not such a great idea to encourage Kevin to develop Tiny-Fu in a separate module: although it provided a safe sandbox for experimenting with the new interpreter without disturbing the existing scripts, it resulted in a lot of duplicated efforts and the main negative effect was that many people did not even try Tiny-Fu and it slowed down the replacement of siod by tinyscheme. If you compare this with the Python code or even with the SoC projects that were started in separate branches, it is obvious that developing code inside the gimp module leads to a much faster adoption and creates less conflicts. I would have been better to encourage Kevin to use the tinyscheme interpreter in the gimp tree (probably in a branch). My suggestion to disable Script-Fu by default was basically made out of despair because I thought that you would not try Tiny-Fu otherwise. But if you agree to replace the interpreter, then that's even better. But anyway, let's wait for Kevin's comments... -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Switch to Tiny-Fu, end of Script-Fu maintenance?
Since last week, Tiny-Fu is able to run many of the old Script-Fu scripts unmodified: it reads files with the *.scm extension and uses the script-fu-* namespace so that it can process the calls to script-fu-register. I tested Tiny-Fu with several third-party scripts or scripts that are not in the gimp module (e.g., scripts from gimp-gap). I tried a few dozen scripts written for GIMP 2.0 and 2.2, and most of them ran without problems: there were no difference when the scripts were executed with the old Script-Fu interpreter (siod) or with the new Tiny-Fu interpreter (tinyscheme). I only got problems in a couple of scripts that were not declaring variables correctly or were incorrectly mixing the scope of some variables (global/local). For example, this occured in the smart remove object script that came with with the resynthesizer plug-in. But most of the scripts worked fine with Tiny-Fu. In fact, some of them even worked better: for example, Script-Fu's text circle had problems processing text containing foreign characters, while Tiny-Fu processes these characters without problems. Besides these improvements, the main visible difference is that Tiny-Fu registers some menu entries using the name Tiny-Fu instead of Script-Fu. For example: Xtns - Tiny-Fu - Tiny-Fu Console. However, even that could be changed easily if most developers or documenters prefer to keep the old name for historical reasons. From my point of view, Tiny-Fu is now ready to replace Script-Fu and I would like to encourage everybody to make the switch so that we can fix any remaining bugs. Considering that Tiny-Fu solves some real problems (i18n), the sooner we can do the switch, the better. Unless anyone objects, I would like to commit a trivial patch tomorrow that disables Script-Fu by default in configure.in. It will still be possible to use the old interpreter by using --enable-script-fu explicitely, but otherwise Script-Fu should be considered as obsolete. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
On Tue, 3 Oct 2006 23:54:35 -0400, Christopher Curtis [EMAIL PROTECTED] wrote: On 9/27/06, Raphaël Quinet [EMAIL PROTECTED] wrote: This is a different issue from what was discussed here. You can toggle between moving layers, selection masks or paths by using the modifiers: Ctrl or Alt (this will soon be indicated in the status bar). I don't How will this be indicated? Is it via 'discovery mode' or 'explicit mode'? A bit of both... The status bar messages explain what operations will be performed with the current combination of modifers and in addition they suggest to try to other ones. There would not be enough room in the status bar to explain what each modifier does, except when the messages are really short. In addition to the status bar messages, you also have the tool options indicating what each modifier will do. Although this is not done yet by all tools (due among other things to the limitations of the API that generates a list of options from enums), you can see that some tools mention Shift, Ctrl or Alt next to some options that can be toggled. So this gives you the explicit mode to some extent. [...] The [Alt] selections are very confusing, too. [Alt]-drag moved the window (KDE grabs it); Some window managers do grab the Alt modifier. This is why GIMP does not use Alt for anything important. All actions that can be performed in GIMP using the Alt modifier can also be performed in some other way. Besides, window managers should not grab Alt by default. They should use the Windows key instead of the Alt key if it is present on the keyboard. The vast majority of keyboards available today do have such a key, even on laptops. Some keyboards replace it with a penguin key, but the behavior is the same. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool statusbar error messages
On Wed, 27 Sep 2006 23:50:24 +0200, Michael Natterer [EMAIL PROTECTED] wrote: On Wed, 2006-09-27 at 21:25 +0200, Raphaël Quinet wrote: On Wed, 27 Sep 2006 21:03:30 +0200, Sven Neumann [EMAIL PROTECTED] wrote: How do we handle the statusbar being invisible? Perhaps the statusbar should delegate to gimp_message() if it is not currently shown? Yes, but this should probably not be done by the status bar itself. It should be done one level higher so that the code still knows that it is some error message that is important enough to be displayed with gimp_message(). We only show messages if things didn't happen as the user expected them to happen. We can't just let user actions on the display fail without any comment. The Statusbar should imho just use gimp_message() if it is invisible. There are other messages that can be displayed in the status bar but are not errors. In that case, they should simply not be displayed if the status bar is hidden. Obviously that would include the various hints for the tools, selection sizes, guide positions, etc. They don't use the same function call now, so that's fine. But I was also thinking about using gimp_statusbar_push_temp() for something else than errors. For example, after saving a file it could be possible for the file plug-ins to report things like the size of the saved file, which would then be briefly shown to the user in the status bar. Or if you undo or redo some operation, its name could be briefly shown in the status bar (like in the undo history). These informational messages would be displayed in the status bar without the warning icon that is currently used (we could use some info icon although using no icon is probably better if we want the warnings to be noticed easily). And if the status bar is hidden, they would just not be displayed anywhere because they are not very important anyway. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
On Thu, 28 Sep 2006 01:42:12 +0200, [EMAIL PROTECTED] wrote: [...] 1/ In general I find it needs too many mouse/keyboard actions to achieve a simple operation. 1a/ specific: undo : edit | undo . This must be one of the most common actions I want a one click solution, in the same window as I am editting in. There's always cntl-Z cntl-Y but that means dropping the mouse and diverting my attention away fron the screen. Very slow. Well, the undo shortcut is probably not assigned to Ctrl-Z by accident. Did you notice that there is no Z in undo? Something like Ctrl-U could have been used instead (and was used in the past). But many applications use Ctrl-Z. If you are a right-handed english-speaking user (or at least someone with a qwerty keyboard), you can see that Ctrl and Z are close to each other and can be pressed easily with the left hand while the right hand is on the mouse. You might complain about discrimination against lefties or foreigners, but at least for a large percentage of the users, the Ctrl-Z shortcut can be found easily without diverting attention from the screen or mouse. 1b/ I pull up a dlg. the first text entry is highlighted so I can type to replace , fine. But if I want to edit it eg 100 to 400, I go to select the 1 with the mouse and the editted text gets dragged. Huh? So I have to click to deselect the reselect the bit I want. Solving this problem would probably require disabling drag drop from the input fields. I am not sure that anyone uses that feature anyway, at least for the short entry fields that we have in most dialogs (except for the text tool). I agree that it is more likely that someone who clicks and drags in one of these short input fields wants to select some digits instead of dragging the whole number elsewhere. This should probably be submitted in Bugzilla. 2/ I am continually repeating the same placement/configuration operations where once should be enough. 2a/ It seems none of the filters retain thier position and size, although they retains _some_ of their settings. Right. We do not even have an API allowing the plug-ins to retain their size and position easily. Although the current API based on gimp_get_data() and gimp_set_data() could be used for that, every plug-in writer would have to write hacks around gimp_dialog_new() or gimp_dialog_run() in order to resize the window correctly. In addition, the filters that have a more complex layout with resizeable panes inside the window would also have to remember the size of each of them (e.g. Filters-Map-Bump Map) and those that have multiple tabs should remember which tab is active. specific: Filters | Motion Blur ... I resize to get a more visible preview size and move it out of the way of other things on the screen. Next time I use it I dont want to start again. While this is probably down to the plugin writer, at least the common filters should be vetted/modded to retain size/pos before being integrated. And it should be recommended for all plug-ins. I agree. Please submit this improvement proposal in Bugzilla. It may even be useful to remember the window positions (for the plug-ins) accross gimp sessions. In this case, this information should probably go into the pluginrc or something similar. 2b/ If I use a dlg on one image and set, say units to pixels , if I open another image or even duplicate I have to reset the same options. specific: Image | Scale Image , set to percent . Duplicate image , Scale Image : back to default pixels. Although it would make sense for Duplicate, I am not sure that it would be good to always remember the last values used when you create a new image. The defaults can be set in Preferences-Default Image and I would like these values to be used. 2c/ I have select for tools to store settings but this seems limitted. specific: again the Scale Image dlg. units combo. This is held for the time I edit an image but not affected by the config option :tools store settings. I do not understand what you expect in this case. Things like the resolution, units, grid spacing and so on are a property of the image. The Scale Image dialog should just use what is specified for that image. But maybe I misunderstood what you meant. 2d/ I set a value , eg rotation degrees or scale percent. Next time I pull up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point. Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools.
Re: [Gimp-developer] devel docs
On Wed, 27 Sep 2006 09:05:52 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Fri, 2006-09-15 at 13:39 +0400, Alexandre Prokoudine wrote: As well as I understand, the switch to TinyFu from Script-Fu for 2.4 is quite possible (considering Tiny-Fu is already shipped with GIMP 2.3.x for Windows by default). It is very unlikely that 2.4 will ship with tiny-fu. The next Windows installer will also not include it any longer. We have had the chance to do the transition earlier but for various reasons (most of them simply communication problems), it didn't happen. Now we should give it another attempt at the beginning of the next development cycle. I disagree. 2.4 should definitely ship with Tiny-fu, as it makes debugging and i18n easier than Script-Fu and it deals with several features of Scheme in a better way. You mentioned last week that you wouldn't be against switching to Tiny-Fu in 2.4 if the remaining problems (mainly the namespace issues) could be solved in time. It looks like Kevin had been previously discouraged from fixing these problems because there were communication problems between you and him. But now he has taken the time to work on these changes: you will notice that Tiny-Fu can now read *.scm scripts instead of *.sct. I suppose that it will not take long until Tiny-Fu can process most Script-Fu scripts unmodified (e.g., handling script-fu-register and so on). Since a few days ago, Tiny-Fu is now a replacement for Script-Fu instead of being simply something that can be installed on the side: it uses the same namespace now. I have already started building my GIMP with --disable-script-fu and I see that Tiny-Fu works well (as it did before, but then it was using its own namespace). There are still some minor issues with old third-party scripts because the transition from the tiny-fu to the script-fu namespace is not finished yet, but it already works well. And I trust Kevin for finishing the renaming soon. Please do not block Tiny-Fu again. It is more mature and more stable than several other pieces of code that have been introduced in CVS in the last weeks. If it can run most of the old scripts unmodified, there is really no reason to delay this long overdue replacement of Script-Fu. The Windows installer has shown the right way, let's follow it for all platforms. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool statusbar error messages
On Tue, 26 Sep 2006 15:00:16 -0700, Carol Spears [EMAIL PROTECTED] wrote: we were discussing a few changes to this on the irc, On Tue, Sep 26, 2006 at 02:17:34PM -0700, William Skaggs wrote: From: Michael Natterer [EMAIL PROTECTED] While doing so I noticed they are all bad and inconsistent. Indexed images are not currently supported.(heal) Healing does not operate on indexed layers Healing cannot manipulate indexed images. [...] I am not sure about does not operate vs. cannot manipulate, but I agree with the usage of images instead of layers: talking about images makes it more likely that the user will think about changing the image mode. In the current GIMP, the mode is a property of the image and cannot be changed for individual layers. The only exception is if the active drawable is a channel (saved selection) or a layer mask: these are always grayscale so it would not make sense to display a message like Hue-Saturation operates only on RGB color images if the image is already RGB. But as I mentioned on IRC, the most likely cause of this warning is that the user is not aware that the active drawable is not a layer. So it makes more sense to add tests like GIMP_IS_LAYER_MASK(drawable) or GIMP_IS_CHANNEL(...) and display a specific message for these cases: Hue-Saturation does not operate on layer masks Colorize does not operate on saved channels I'll let the native English speakers decide if does not operate on is better than cannot manipulate, but otherwise I'm ready to add the tests for the layer masks or channels. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Moving selection contents with the move tool?
I just saw (on IRC) a confused user of gimp 2.2.11 who was not able to move a part of an image to a different place. Despite some advice from edhel and myself telling him to just drag the selected area to a different place, it did not work. And we could not understand what was wrong... until he found the solution and told us that he was trying to use the Move tool to move the selected area. Of course if he had not switched to the Move tool and used the selection tools instead, this would have worked as expected. It is just that this user expected the Move tool to be able to move the selection contents, not just whole layers or selection masks or paths. We may have a usability problem here... In the current CVS version, the old way of just dragging the selection does not work anymore. You have to use Ctrl-Alt-Drag or Shift-Alt-Drag in order to perform this operation. (Note that currently, this does not work for the rectangle and ellipse selection tools until the selection has been confirmed). Although the status bar messages try to help a bit, this feature is a bit hidden now. So I am wondering... What should be the behavior of the Move tool when a selection exists? Wouldn't it be good to have the ability to move the selected pixels (and create a floating selection) instead of moving the whole layer? This could be optional (new checkbox in the tool options) because sometimes it is also useful to move the whole layer while keeping the selection intact. But I guess that it would be better to have the new option active by default. If we do not offer this option or another easy way to move the selected pixels, I am afraid that this could become a new FAQ once 2.4 is out. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool statusbar error messages
On Wed, 27 Sep 2006 21:03:30 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Tue, 2006-09-26 at 23:02 +0200, Michael Natterer wrote: I just comitted a change that moves all tool error messages that can happen when clicking the image to the image window's statusbar, using the new gimp_statusbar_push_temp() API. How do we handle the statusbar being invisible? Perhaps the statusbar should delegate to gimp_message() if it is not currently shown? Yes, but this should probably not be done by the status bar itself. It should be done one level higher so that the code still knows that it is some error message that is important enough to be displayed with gimp_message(). -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
On Wed, 27 Sep 2006 13:14:38 -0700, William Skaggs [EMAIL PROTECTED] wrote: It seems that for consistency the Move tool should act like a transform tool --- because after all, it *is* a transform tool. That is, if there is a selection, it should move the contents of the selection, otherwise it should move the layer. Yes, this is why I suggested that this behavior should be the default one for the Move tool. However, I understand that some people might want to be able to move a whole layer even if a selection exists, which is why I suggested to allow this to be toggled. As a side note, it would be nice if the rectangle and ellipse selection tools (not the base rectangle tool) would take Alt into account before the selection is confirmed and behave as if the selection had been confirmed: Alt = move selection mask, Alt+Ctrl = move selected pixels, Alt+Shift = copy selected pixels. It should not be necessary to press Enter before being able to move it. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
On Wed, 27 Sep 2006 13:42:38 -0700, Carol Spears [EMAIL PROTECTED] wrote: On Wed, Sep 27, 2006 at 09:01:29PM +0200, Rapha?l Quinet wrote: So I am wondering... What should be the behavior of the Move tool when a selection exists? Wouldn't it be good to have the ability to move the selected pixels (and create a floating selection) instead of moving the whole layer? [...] i am trying to think of a case where i have a selection and i am trying to move a path and i cannot come up with one. This is a different issue from what was discussed here. You can toggle between moving layers, selection masks or paths by using the modifiers: Ctrl or Alt (this will soon be indicated in the status bar). I don't think that this behavior should be changed. This proposal was about a different thing, which is that the Move tool should be able to move the selected pixels, not just whole layers or selection masks (masks, not contents) or paths. And it should do that by default like the other transform tools (see also Bill's message). -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
On Wed, 27 Sep 2006 23:21:04 +0200, [EMAIL PROTECTED] wrote: You might see it as a lateral translation effected by simple transform matrix multiplication. The user just wants to move a bit to one side. You probably misunderstood Bill. This is exactly what he meant by saying that the Move tool should behave like other transform tools: it should move the selected pixels when there is a selection (instead of moving the whole layer as it does now). BTW How do I move a rectangular selection ?! I don't mean move the selection outline, how do I move the part of the image selected? Well, this is what I described in my message. With GIMP 2.2.x, you move the selected pixels by just dragging them. With GIMP 2.3.x, you currently have to first press Enter to confirm the selection (if you are using the rectangle or ellipse selection tools), then press Ctrl+Alt while dragging the pixels, or Shift+Alt if you want to copy the pixels instead of moving them. Easy, isn't it? And while we're here , why is the rect selection tool not on the palette with the ellipse and free-style tools, do I really have to go off to Tools | Selection Tools | Rectangle ? If you are using a development version, it is likely that your toolrc has not been updated since a while. I recommend that you just delete it and restart GIMP. Just rm ~/.gimp-2.3/toolrc. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] rectangle tool update
On Tue, 22 Aug 2006 10:01:01 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Mon, 2006-08-21 at 10:36 -0700, William Skaggs wrote: if you have to wait until after you have pressed the mouse button in order to activate the constraint. I had quite some difficulty coming up with a reasonable way of dealing with this -- what I finally decided is that the most sensible thing to do is just to make each key-press, while button1 is down, toggle the constraint. I don't think that's a good solution. I would rather implement a different behaviour for the case where the user is changing an already created rectangle. If the user is creating a new rectangle, pressing Shift and Ctrl while the mouse button is down should activate square mode, respective from center. And, and that's important, releasing the modifier keys should untoggle it. Only then can the user discover this functionality without the risk of doing something unwanted. I agree with Sven: releasing the modifier keys should immediately change the mode (square or from center) back to what it was before. This instant feedback on press and release is how all other tools/options behave. Introducing a new concept of sticky modifiers does not improve the consitency of the GIMP user interface. I also agree that the best way to solve this would be check the modifiers only during the initial click-drag but ignore them once the rectangle has been defined. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Script-Fu procedure blurb review
On Wed, 02 Aug 2006 11:38:01 +0100, Toby Speight [EMAIL PROTECTED] wrote: 0 In article [EMAIL PROTECTED], 0 saulgoode URL:mailto:[EMAIL PROTECTED] (saulgoode) wrote: saulgoode 2. In a couple of places I employed the term selection saulgoodeframe in order to differentiate operations that affected the saulgoodeselection mask versus those that affected the selection's saulgoodecontents (e.g., 'script-fu-selection-rounded-rectangle' is saulgoodedescribed as Round the corners of the current selection saulgoodeframe). I feel that selection frame is more intuitive saulgoodethan selection mask in these contexts. Other ideas: selection boundary, selection bounds, selection outline, selection edge. Do any of these make more sense? I would go for selection outline or selection edge. It looks like most users think about the outline of the selection rather than its contents. This can easily be explained by the fact that the outline (the marching ants) is the only visible part of the selection (without quickmask). From a technical point of view, referring to the selection as a mask is more appropriate especially for heavily feathered selections for which the outline is taken arbitrarily at 50%. But even if selection mask would be more appropriate, it may be less confusing to use selection outline because this is understood immediately and there is less risk of confusion with other terms like layer mask, channels and maybe future clipping masks, etc. The terms selection bounds should be avoided because of the confusion with the function gimp_selection_bounds() which returns the bounding box of the selection instead of the selection itself. I did a quick google match between these terms with the following results (in square brakets you have the numbers for gimp + selection term and for photoshop + selection term): - selection outline [1050/609] is the most popular combination of terms for gimp users but not for photoshop users. It is found in tutorials, various articles, in the manual, etc. - selection mask [565/830] is mainly used by gimp developers and by photoshop users. For gimp, selection mask can be found in the archives of this mailing list, in scripts and in the PDB. - selection boundary [478/648] is used in the book Grokking the GIMP, in some tutorials and in archives of this mailing list. - selection frame [350/631] is used mainly in the context of XSane, in the new manual (gimp-help-2) and in a number of false positives from RPM(?). - selection edge [154/1150] is not used much in the gimp context but is the most popular term for photoshop users. For gimp, it can be found in the old manual (GUM) and in the new one (gimp-help-2). -Raphael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Modifiers before or after first click in selection tools (was Re: status bar messages)
On Thu, 22 Jun 2006 08:21:46 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Thu, 2006-06-22 at 00:08 +0200, Raphaël Quinet wrote: Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters. All the other tools create the selection immidiately. All tools consider the state of the modifiers at the moment you create the selection. Whether that is the first click or not seems irrelevant to me. This is not really true for the rectangle or ellipse selection tools or even the free select tool (lasso). I think that you are taking the developer's point of view here, considering when the data structures are created rather than the user's workflow. If you look at the code and see that the selections (the data structures) are created only once the shape has been fully defined, then it makes sense to say that the modifiers deciding if the new selection should be added to, subtracted from or intersected with the old one should only be considered when the data structures exist. But if I think about how I work with selections, I usually do the following: I start with a selection created with one of the complex tools (iscissors, path converted to selection, magic wand or siox) and then adjust this selection by adding or removing some areas with one of the quick (one click) tools such as free select or rect select. Sometimes I also use one of the complex selection tools for adjusting the initial selection. In these cases, the decision to add/subtract/intersect is always taken before the first click with the other selection tool: I start creating the new selection because I know that I will add or subtract it from the existing one. From that point of view (user's workflow), it makes sense to consider the state of the Shift and Ctrl modifiers when the decision to add or subract is taken, which is (at least for me) before the first click. In other words, I think about the modifiers when I start to define what the new selection will be rather than when the selection (the internal data structure) is created. This is only my point of view and I may be biased, that's why I suggested some usability tests to check what is best. If we do not have the time or resources for that, we could at least ask for the opinion of our resident artists or maybe discuss that on gimp-user. From my point of view, I consider the usage of modifiers in iscissors and siox to be inconsistent with other selection tools and I would like to fix that. But I also understand your point of view, which is closer to how the code works. This wouldn't have happened to you if you have had a look at the cursor changes. I know that the cursors are there to help, but it is too easy for me to forget to press Shift or Ctrl again when I finish drawing the shape, maybe because I have the wrong expectations about how the tool should behave. Besides, the cursors are actually wrong and misleading for siox. Compare what happens with one of the simple selection tools (rectangle, ellipse or free select) and with siox. With free select, I do this: - Press Shift to add to the current selection: the cursor shows a +. - Click to start defining the new selection, release Shift: the + is still there while I move the mouse around. - Release the mouse button to finish defining the selection: the new selection is created and added to the current one. With siox (which uses exactly the same cursor), I do this: - Press Shift to add to the current selection: the cursor shows a +. - Click to start defining the new selection (for siox, the first step is to define the area around the object), release Shift: the + is still there while I move the mouse around. - Release the mouse button to continue with the second step of siox (paint over the foreground): now the + is gone. - Press Enter to finish defining the selection: the new selection is created and replaces the current one, despite what the initial cursor was showing. I just discovered this bug, thanks to your suggestion to look at the cursors. Before attempting to fix it, I think that we should decide what is the correct behavior: considering the state of the modifiers before or after the selection is defined (user's point of view) vs. before or after the selection is created (developer's point of view). [...] BTW, does anyone object to removing the possibility of turning context dependant cursors off? They are very important and I can't really imagine that someone would want to work without them. I thought that one of the reasons for having this as an option was that some displays did not allow them or did not work well with them (severe performance
Re: [Gimp-developer] proposal for libgimpmetadata API
On Thu, 22 Jun 2006 08:10:19 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Thu, 2006-06-22 at 00:35 +0200, Raphaël Quinet wrote: Cleaner code (core/GUI separation, maintainable by different people), lower overhead (especially when changing many properties) and more importantly providing the start of a solution for avoiding the concurrency issues that I mentioned earlier. Sorry, but I don't follow you on the first arguments, they seem unrelated. Where the code lives has nothing to do with how clean it is. Well, let's say that it makes it a bit easier if the code is at least split in separate directories (even if a library is not required for that). As for the lower overhead, it does make a difference if the file plug-ins can link with a library directly or if they have to convert all data and pass it through the PDB for every action, especially when these PDB calls have to spawn a new process which in turn decodes the data, re-encodes it again for the PDB (setting the parasite) and then only returns the result to the initial plug-in. These 4 encoding/decoding steps and spawning of new processes have to be done for every single property that is set or read by the file plug-ins. So the argument for having this library now is that it allows avoiding the concurrency issues. But that's something that we will only get later anyway. That makes me think that it will be best to keep the code in a plug-in, accessible over the PDB. That should give us everything we need for 2.4 and avoids the need for defining an API now that we might have to support for quite a while. To be frank, I thought that you agreed with the principle of moving the metadata core into a library when we discussed it last time. I thought that the discussion about the API would be mainly about the features that the API should expose, rather than whether it should exist as a library API or be limited to the PDB. I got a bit bored with the PDB implementation and its limitations, that's why I expected to be more motivated to work on the remaining issues after getting rid of the extra PDB calls. [...] I wouldn't want to see the core crash because some camera manufacturer made a mistake and the camera creates images with corrupt metadata. By the way, crashing the core because of corrupt metadata is not that likely: the core would only handle the metadata that is already in the parasite. Except for corrupt XCF files (unlikely to come from a camera!), the only way for the metadata to be put in the parasite is via the editor (the user enters some data) or via the file plug-ins, which would be based on the same libgimpmetadata library. So even if there is a bug that could crash the parser despite the safeguards in the code, that bug would affect the file plug-ins before they have a chance to store the metadata in the parasite and hand it over to the core. Of course there is always Murphy's law... I understand your concerns. But since you said that we aren't going to have this code in the core for 2.4, what's the point of preparing that move now? If we have a little more time, we can find other ways to avoid the concurrency problem. The core could for example signal image changes to plug-ins that ask for such notifications. That would be useful for a lot of plug-ins and we could add such functionality right after 2.4. I agree that such a notification feature would be useful for a lot of plug-ins. However, my goal is really to have the metadata in the core, handled like any other information about the image: resolution, colorspace, image comment, etc. With the metadata handling in the core, I would like to have some parts visible in the preferences: the Default New Image tab has an expander with Advanced Options. Instead of the generic Comment field, there would be separate options to specify Author and Copyright and I could also add an option for selecting a default license. Another point of integration in the core would be a dockable dialog similar to the Pointer Information dialog (or maybe to the currently non-dockable Image-Image Properties dialog) that displays some of the most important parts of the metadata for the active image. This could be configurable: some users may be interested in the date and location, while others are more interested in the dc:description or dc:creator. The core could also notify the user if there is an explicit copyright on an image (some other programs warn you if you attempt to modify or save an image that has a copyright, but I would rather go for a non-intrusive notification). You can probably argue that some of these features could also be implemented outside the core, but then they would not be very well integrated. For example, it would be difficult to select a default license for all new images if this is not done in the main preferences. -Raphaël ___ Gimp-developer mailing list Gimp-developer
[Gimp-developer] proposal for libgimpmetadata API
In order to improve the support for metadata (XMP and EXIF), I would like to move some of the code that is currently located in the plug-ins/metadata directory into a new library, libgimpmetadata. This library would be linked with all file plug-ins that support metadata. This includes JPEG, PNG, TIFF and maybe GIF, PSD, SVG and other file formats. The metadata is stored internally as an XMP packet inside a gimp image parasite (so it is transparently saved in xcf files). Instead of manipulating this parasite directly, the file plug-ins can use the libgimpmetadata library for getting or setting individual properties in the XMP packet, for merging EXIF data into the XMP packet or for generating an EXIF block from parts of the XMP data. Due to the need to generate JPEG thumbnails, the library adds a dependency on libjpeg. Sven asked for a review of the proposed API for this library, so here it is. Note that the library does not define new gobject classes or anything like that. This is simply a set of functions for accessing the metadata that is attached to the image (in a parasite that should be mostly opaque for the user). /* decode the given XMP packet (read from a file) and merge it into the metadata parasite. */ gboolean gimp_metadata_decode_xmp (gint32image_ID, const gchar *xmp_packet); /* generate an XMP packet from the metadata parasite */ const gchar * gimp_metadata_encode_xmp (gint32image_ID); /* decode the given EXIF block (read from a file) and merge it into the metadata parasite. */ gboolean gimp_metadata_decode_exif (gint32image_ID, guint exif_size, const gchar *exif_block); /* generate an EXIF block from the EXIF-compatible parts of the metadata parasite */ gboolean gimp_metadata_encode_exif (gint32image_ID, guint*exif_size, const gchar **exif_block); /* get the value(s) of a single XMP property */ gboolean gimp_metadata_get (gint32 image_ID, const gchar *schema, const gchar *property, GimpXMPPropertyType *type, gint*num_values, const gchar ***values); /* set the value(s) of a single XMP property */ gboolean gimp_metadata_set (gint32 image_ID, const gchar *schema, const gchar *property, GimpXMPPropertyType type, gint num_values, const gchar**values); /* delete a single XMP property */ gboolean gimp_metadata_delete (gint32 image_ID, const gchar *schema, const gchar *property); /* same as gimp_metadata_get() but simpler, for scalar properties */ const gchar * gimp_metadata_get_scalar (gint32 image_ID, const gchar *schema, const gchar *property); /* same as gimp_metadata_set() but simpler, for scalar properties */ gboolean gimp_metadata_set_scalar (gint32 image_ID, const gchar *schema, const gchar *property, const gchar *value); /* register a non-standard XMP schema prefix for use in get/set procs */ gboolean gimp_metadata_add_schema (gint32 image_ID, const gchar *schema, const gchar *schema_prefix); Example of use: - An image containing both XMP and EXIF information is loaded - Call gimp_metadata_encode_exif (image, exif_size, exif_block) to load the EXIF block into the gimp metadata parasite. - Call gimp_metadata_encode_xmp (image, xmp_packet) to merge the XMP information into the gimp metadata parasite. If some properties are present in both XMP and EXIF (this is very likely), the old EXIF information is overwritten: XMP always takes precedence. - Call gimp_metadata_set_scalar (image, dc, contributor, John Doe); to set the dc:contributor property. - Call gimp_metadata_set_scalar (image, http://ns.adobe.com/exif/1.0/;, UserComment, foo!); to set the exif:UserComment property. Here, the full schema URI is used but it would also be possible to use the exif prefix because this is a known prefix (standardized). - Call xmp_packet = gimp_metadata_encode_xmp (image); to generate a new XMP packet suitable for saving into a file. Most of the functions listed above are currently implemented in the metadata plug-in and exported in the PDB. So you can find a slightly longer description of these functions by looking in the
[Gimp-developer] proposal for better status bar messages (long)
Here is a proposal for improving the messages that are shown in the status bar. Such messages would be very useful for describing some hidden features of the paint tools (bug #124040) but also for the other tools. Basically, I followed this approach: anything that causes a tool to change its behavior (clicking, dragging or using some modifiers such as Ctrl and Shift) should be displayed or suggested in the status bar. Simon has already done that for the path/vector tool and I would like to apply that to all tools. Some of these different modes are already triggering changes in the cursor. However, this is not sufficient because some people may not see these different cursors and because the status bar messages are better for suggesting what modifiers could also be used. I consider the status bar messages to be a useful complement to these cursors. Note that these messages have to be short enough to fit in the status bar. They may not always fit if the image window is very narrow, but then the user who wants to read the messages can resize the window. The goal is to make the messages reasonably short so that they are entirely visible as often as possible. The suggestion to use some modifiers and the optional description of what these modifiers will do is put at the end of the message so that the essential parts are more likely to be visible. Also, some tools allow their mode to be changed permanently via the tool options and toggled temporarily via a modifier. For example, toggling between horizontal and vertical modes for the flip tool. A change in the tool option reverses the meaning of the modifier. The messages below suggesting (try Shift) or (try Ctrl) should probably be built dynamically depending on whether modifiers are pressed rather than depending on the mode of the tool (tool-op). And finally, most tools only consider the state of the modifiers before the first click for deciding to change their mode. This is the case for most selection tools (Shift/Ctrl for add/subtract/intersect), transform tools, zoom tool, etc. But there are some exceptions, such as siox and iscissors that only consider the modifiers after the area is defined. This has been discussed here a few days ago for the new selection tools. Below, I assume that the old behavior (modifiers considered only when starting) is the correct one because this is the one that brings the best consistency accross all tools. If you want to discuss this, please start a separate thread (new subject). PATH TOOL (app/tools/gimpvectortool.c) -- Most messages would remain unchanged, except that SHIFT would be replaced by Shift. For reference, here are the messages currently used, with the updated capitalization: Click to pick path to edit. Click to create a new path. Click to create a new component of the path. Click to create a new anchor. (try Shift) Click-Drag to move the anchor around. Click-Drag to move the anchors around. Click-Drag to move the handle around. (try Shift) Click-Drag to move the anchors around. Click-Drag to change the shape of the curve. (Shift: symmetrical) Click-Drag to move the component around. (try Shift) Click-Drag to move the path around. Click to insert an anchor on the path. (try Shift) Click to delete this anchor. Click to connect this anchor with the selected endpoint. Click to open up the path. Click to make this node angular. PAINT TOOLS (app/tools/gimppainttool.c) --- - When nothing has been drawn yet: Click to paint, or press Ctrl to pick a color. - After the first brush stroke: Press Shift to draw a straight line. (try Ctrl to pick a color) - While drawing a line (Shift pressed): distance Click to draw the line, try Ctrl for constrained angles. - While drawing a constrained line (Shift+Ctrl pressed): distance Click to draw the line. - While picking a color (Ctrl pressed): Click in any image to pick the foreground color. In these messages, distance is the distance shown as number followed by the current unit. For example, 123.4 pixels or 0.1234 m. Tools such as the eraser, convolve and smudge tools can also use these common messages, with some exceptions explained in their own sections below. It would be better to replace the verb draw by the appropriate action for the tool, if this is possible (I didn't check). For example: Press Shift to erase a straight line. COLOR PICKER (app/tools/colorpickertool.c) -- - While picking the foreground color: Click in any image to pick the foreground color. (try Ctrl, Shift) - While picking the background color: Click in any image to pick the background color. (try Shift) As mentioned above, the try messages would be different if the mode is changed permanently in the tool options (opposite meaning for Ctrl). RECTANGLE SELECTION
Re: [Gimp-developer] proposal for libgimpmetadata API
On Wed, 21 Jun 2006 22:54:32 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Wed, 2006-06-21 at 21:15 +0200, Raphaël Quinet wrote: [...] After moving these functions in the new libgimpmetadata library, they would still be exported to the PDB but probably renamed gimp-metadata-* instead of plug-in-metadata-*. I don't really understand that part yet. If the code is in a library that plug-ins can link to, why are the functions exported to the PDB and how exactly does this happen? The file plug-ins would not use these functions via the PDB because they could use the library directly. However, it is still useful to have these functions exported to the PDB so that they can be used by scripts. For example, if you want to have a script that automatically attaches a Creative Commons license to a file, it would only have to call something like this: gimp-metadata-set-scalar (image, xmpRights, marked, true) gimp-metadata-set-scalar (image, cc, license, http://creativecommons.org/licenses/whatever;) That covers the why. Regarding the how, it depends... My long-term goal is to move the metadata viewer/editor into the core (like other info dialogs and so on) because it would be the only way to ensure that it reflects the current state of the metadata while the image is being edited. This would solve some of the annoying concurrency problems: if you open the metadata editor (currently a plug-in), and save the image while the editor is open, then some changes to the metadata are lost because the parasite is modified by the file plug-in but the editor does not know it. I think that I mentioned this before or during the last GIMPCon. So if/when the metadata viewer/editor is in the core, then it makes sense for the core to export some of these functions to the PDB. But I am not planning on migrating the editor to the core right now. In the meantime, it may be better for the editor (the GUI part) to remain as a plug-in and then it would make sense for it to export these functions to the PDB. But even if these functions are temporarily exported by a plug-in, I think that it would be better to name them gimp-metadata-* in order to reflect the intent to move them into the core later, and to avoid breaking scripts that could start using them in the meantime. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Wed, 21 Jun 2006 22:45:55 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Wed, 2006-06-21 at 21:22 +0200, Raphaël Quinet wrote: [...] However, for greater consistency with other tools I think that it would be better to consider the state of the modifiers _before_ the first click instead of when pressing Enter. That does IMO not make sense. The SIOX tool, just like the Intelligent Scissors tool requires the user to work on the selection outline for quite a while. It makes much more sense to respect the modifiers when the selection is actually created and that happens at the end, when the user confirms her work and presses Enter. Users may have a different understanding of what is meant by when the selection is actually created. Or different expectations. We know that it is only done at the end. But I would not be surprised that many users would consider the first click to be when the selection is actually created -- they probably do not care about the difference between a solid outline and marching ants, or between a masked foreground/background and marching ants. They probably consider only when they start defining that selection. Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters. I actually made the wrong assumption once or twice with the iscissors: I wanted to add a new area to a selection so I pressed Shift before clicking on the first point, then added more points, closed the shape, clicked inside it and poof! my selection was gone. I naively thought that it would behave as described above and I did not press Shift for the final click. I lost my selection and I had no way to undo/redo this, except by re-selecting. But maybe I am the only one who has this expectation for the selection tools? I don't know. Only some usability tests could tell what is best... -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for libgimpmetadata API
On Thu, 22 Jun 2006 00:13:13 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Wed, 2006-06-21 at 23:53 +0200, Raphaël Quinet wrote: The file plug-ins would not use these functions via the PDB because they could use the library directly. The file plug-ins could as well use the functions via the PDB then. What's the benefit of linking to them? Cleaner code (core/GUI separation, maintainable by different people), lower overhead (especially when changing many properties) and more importantly providing the start of a solution for avoiding the concurrency issues that I mentioned earlier. I am somewhat reluctant to see such code in the core, or the core linking to it. Simply because experience shows that parsers aren't perfect and can crash. I wouldn't want to see the core crash because some camera manufacturer made a mistake and the camera creates images with corrupt metadata. I understand your concerns. However, I do not see another way to view and modify the metadata in real time. Viewing the metadata should be like viewing any other image properties (info dialog) and doing this in a plug-in that does not know when the image or its metadata is modified means that the metadata displayed by the plug-in may not match the current data: wrong image dimensions, color space, etc. And worse, the plug-in may override some changes to the metadata if it updates it after ignoring other changes that happened outside of its control. With the current plug-in, you may get annoying results such as an image saved with the wrong thumbnail or with other incorrect metadata, just because you forgot to close the metadata editor before saving and to re-open it just after saving. This should not happen in the core. Besides, I try to have a parser that is as robust as possible. ;-) -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tiny-Fu status and information
On Fri, 02 Jun 2006 07:49:05 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Thu, 2006-06-01 at 00:34 -0400, Kevin Cozens wrote: What next? Script-Fu should be removed from the GIMP source tree and made available as a separately developed project. This would allow the first two issues listed under Differences to be easily solved. How would this solve the issues? Do you propose that the installation of script-fu or tiny-fu is mutually exclusive? This would of course be the ideal solution. I do not think that it would be the ideal solution. I have been running the latest versions of Script-Fu and Tiny-Fu together for several months now and I enjoyed the fact that I could easily compare their behavior without having to maintain separate GIMP installations (well, besides the ones for HEAD vs. stable 2.2.x). From my point of view, the ideal solution would be this: - Remove Script-Fu from the gimp module and create a gimp-script-fu module. - Declare that Script-Fu is deprecated (but still available as a separate package for those who really want it). - Distribute Tiny-Fu in the gimp tarball so that it becomes the default Scheme interpreter. Note that the last point does not require merging both modules. This could be done by changing the make dist target in the gimp so that it checks for the presence of the tiny-fu module and bundles the whole thing together. This is the ideal solution, even if it may be controversial. We know that the vast majority of the users will not install a new scheme interpreter if it is not part of the default package. We also know that the Linux distributors and packagers for other platforms will simply follow our tarball structure instead of bundling things together (some distributions provide support for suggested or recommended packages, but again many users do not bother installing these additional packages). So as long as Script-Fu is part of the gimp package, it will prevent Tiny-Fu from being widely adopted. The fact that I was the first one to report the problems in bug #342578 although the problem had existed for several months should tell something about the current adoption of Tiny-Fu. On the other hand, the advantages that Kevin listed for Tiny-Fu over the old interpreter are real and very useful: support for UTF-8, better debugging, etc. Anything that can be done to encourage people to switch from Script-Fu to Tiny-Fu would be a good thing, IMHO. But since you say that tiny-fu is never going to be able to run all script-fu scripts unmodified, the chance that anyone would install tiny-fu in favor of script-fu seems rather small. The changes required are rather small. The main requirements are to rename the *.scm files to *.sct and to replace script-fu-* by tiny-fu-* in the files (both of these are easy). The other changes such as making sure that variables are declared and in the correct scope are only applicable to a few scripts and should have been done in the first place anyway, even for script-fu. And in any case, these changes are only necessary for those who have written their own scripts or downloaded them separately. We have broken more things in the past for Script-Fu itself (e.g., PDB changes) so I do not think that the transition from Script-Fu to Tiny-Fu would be more painful than what he have done previously. If we allow both interpreters to be installed together (which is currently the case), then it would be possible to distribute Script-Fu as an optional package. Those who do not want or cannot update their old scripts could install the optional Script-Fu package to be able to run them. It would simply reverse the current situation by making Tiny-Fu the default and this would be a Good Thing. In regards to some people thinking that moving Script-Fu out of the GIMP source tree is going to make some people feel Script-Fu is being retired they would be correct. A number of the GIMP developers have been wanting Script-Fu to die for some time. It has just been a question of when, rather than if, it will happen. With the Python binding maturing, it could become the default GIMP script interpreter. But people will still want to be able to run some script-fu script occasionally. Whatever comes bundled in the tarball will become the default GIMP script interpreter. In the past, we had Script-Fu and Perl-Fu/Gimp-Perl. Then the Perl bindings started to be distributed as a separate package and people stopped using them rather quickly. The opposite happened for the Python bindings. We can also observe the same thing for many other plug-ins such as gimp-gap, etc. In summary, regardless of what we claim is required, recommended or suggested, the main thing that matters is what comes inside the official gimp tarball. After having tried both Script-Fu and Tiny-Fu for several months, I would like to get rid of Script-Fu as soon as possible. -Raphaël ___
Re: [Gimp-developer] rectangle tools
On Sat, 26 Feb 2005 07:20:29 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ] A) Use a dialog ... Dialog boxes that get in the way are annoying (like popup ads). ] B) Use the Tool Options ... Good choice. People already look there for similar control. ]C) Use the status bar...(x, y, width, height) entry boxes... ]...A little button in a corner of the status bar ... Tool Options would be more consistent than the status bar, as is evidenced by the type of work required to modify the status bar. Most arguments for C are also arguments for B. Not really. There are some differences: for example, the controls in the status bar are more likely to be visible when you want to use them (*) because they would be part of the image window and would not be in a separate window that could be partially hidden by the image window (or vice-versa). Also, they do not take space in the Tool Options dialog box when they are not needed, so this makes the list of options smaller (easier to understand for the user, no need to scroll if you have a small screen, no need to collapse some options and hide them with an expander). I like the idea that the user would only see the controls and options that make sense for the current task: this simplifies the interface and makes it easier to learn. So the idea with (C) is that when you switch to a selection tool, you get the general options in the Tool Options tab and nothing special in the status bar (except maybe for some nice help text like for the Path tool). As soon as you start creating a selection, then you automatically see the controls allowing you to set precisely the position and size of the selection. Note that these controls appear where you are currently seeing the position of the pointer and other information, so this will look familiar. Also, the coordinates in these entry boxes are updated automatically when you drag the selection, which is something that would be a bit more unusual to have in the Tool Options tab (IMHO). I think that it would be nice to have such a solution for the selection tools, the crop tool and all transform tools. D) If you want a button like option C to activate a dialog, it could go in the Tool Options instead of the status bar. The idea about the little button in a corner of the status bar was just in case we need more space for the controls that could not fit in the status bar. But if all we need is some space for four entry boxes and maybe one toggle for the constraints, then I am not sure that we need extra space so this button may not be necessary. -Raphaël (*) Always visible as long as the status bar is visible. One could hide the status bar, but one could also hide the Tool Options. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Report from GIMP talk at FOSDEM
Some short notes about my talk on GIMP 2.2+ and the feedback that I got during and after the presentation: - Several people liked the improved drag-and-drop support and it looks like some of them were not aware of the option to drag images as new layers inside an existing image. - They also seemed to like the generated brushes and the fact that they can be resized easily with some keyboard shortcuts. - Amusingly, the most visible features (previews in tools and plug-ins, for example) caused less reactions than the useful tricks (drag-and-drop, keyboard shortcuts) that are not visible until someone shows them to you or you take the time to read all help pages. - I got some expected questions about the user interface and these turned into a 10 minutes debate between some who would like to see some kind of MDI support (like Photoshop and other programs) and others who prefer the current interface. The expected conclusion is that having MDI as an option would be useful for many users but this will only materialize if someone takes the time to write the code. - One guy asked about better support for typesetting and said that the GIMP was unusable for any serious work if it did not support text orientation and letter spacing. He insisted very much on that. Thanks to Pippin for telling him that most of the infrastructure is ready for that in Pango, but it takes time to implement the GIMP part (UI and logic). I doubt that the guy will submit a patch, though... - I got some questions about how to make sure that one can take a picture in raw format from a digicam (e.g., with gtkam) and have all the metadata correctly handled and preserved until the final image is saved. This is too difficult today, especially if dcraw messes up the metadata for raw images. - One guy asked if a plug-in could be notified of any changes to an image so that it could propagate those changes to another image or a preview. This could be an interesting idea that needs more discussion and would require some changes to the plug-in API and wire protocol. - Surprisingly, I did not get too many questions about support for CMYK or more than 8 bits per channel. Other tidbits about FOSDEM: - Judging by the attendance, the talk by Alan Cox on Sunday about how to manage a stable kernel seemed to be the most popular. The room had 1400+ seats and 3/4 were occupied. - The KDE people were visible and well organized: they printed small posters for each KDE talk with a nice Konqui image, the title of the presentation, its location and time. They were everywhere. In comparison, the advertisements for GNOME talks were invisible. Even GNUstep and Plan 9 had more posters. - There were many interesting presentations. Among those that I enjoyed: Wikipedia by Jimbo Wales, Kernel by Alan Cox, GPL Enforcement by Harald Welte and the desktop track with KDE by Matthias Ettrich, XFCE by Olivier Fourdan and Nautilus by Alex Larsson. - I hope that I will see more GIMP developers next year! -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] rectangle tools
On Thu, 24 Feb 2005 10:23:08 -0800, William Skaggs [EMAIL PROTECTED] wrote: A) Use a dialog similar in general appearance to the Crop Tool dialog, and allow the user either by checking a Tool Option or by pressing a modifier key to enable/disable showing the dialog. Of course the actual contents of the dialog are subject to improvement. B) Use the Tool Options as the place where information is entered, and don't have a dialog at all. It is of course possible that there are other approaches that haven't occurred to me. Here is one that you haven't mentioned: C) Use the status bar for displaying and modifying the position and size of the selection. Instead of displaying a simple text label with the size of the selected area, the status bar could automatically replace this text by two (width, height) or four (x, y, width, height) entry boxes when the user starts selecting something. The value in these boxes would change while the user is dragging the rectangle and modifying the selection interactively but it would also be possible to edit the values directly in the status bar. Note that these entry boxes would only need to be there while a selection is being modified (i.e., after the first click and drag). They do not have to be there all the time while a selection tool is active, so the status bar can still be used to display some other useful information as text when the user is not currently editing a selection. This also means that the box and drop-down list with the zoom ratios can be temporarily replaced in order to gain more space in the status bar for these new entry boxes. In addition, a small icon or expander button could be added to the status bar while such a tool is in use; clicking it would pop up a dialog box containing more options. There are always more options that could fit in the status bar, such as constraining the selection to a fixed aspect ratio, etc. A little button in a corner of the status bar would provide a convenient way to display this dialog with advanced options only when needed. Personally, of the two, I favor A, for a couple of reasons. If C is not accepted, then I favor B. Although you are right that the Tool Options were not intended to be used for active control of a tool, I think that the disadvantages of having a window that gets in the way outweight its advantages. By the way, the status bar is part of the image window so unlike the additional dialog or even the Tool Options, it will never get in the way of the interactive selection. I think that option C would be the most user-friendly: the important information is visible without getting in the way, the interface is easy to understand, and there is no need to remember special key combinations for showing/hiding the dialog with extra options. The disadvantages of option C are that it would require more coding due to the modifications of the status bar and it would not be possible to display all entry boxes if the image window is too narrow. On the other hand, it would be easy for the user to make the window wider whenever necessary. -Raphaël P.S.: I hope to see some of you at FOSDEM on Saturday and Sunday in Brussels. As I already mentioned on IRC in #gimp, I'll try to offer some good Belgian beers to any GIMPers who come and say hello. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GTK+ 2.6, Pango 1.8
On Tue, 08 Feb 2005 22:10:37 +0100, Michael Natterer [EMAIL PROTECTED] wrote: Gimp CVS HEAD depends on GTK+ = 2.6.0 and Pango = 1.8.0 now. Some changes which make use of the new features and/or remove ugly hacks due to the lack of these features have already landed in CVS. For anyone trying to build the latest GIMP on SuSE distros (and others), I highly recommend that you build Glib, GTK+ and their dependencies in a separate prefix. You should *not* attempt to install them in /usr/lib/ or /opt/gnome/lib/. On some systems (not SuSE, though), even installing in /usr/local/lib/ can cause some problems so you should pick your own directory. Although the current Glib and GTK+ are backwards- compatible with older versions, you will often have many problems if you install the new libraries over those that were provided by your distribution. These problems can occur with some applications (not necessarily the GIMP) because the versions that came with your distro may have been customized. rebuilding them with a different configuration or without the patches applied by your distributor will break some applications. The HOWTO Build Your Stable GIMP from CVS gives some good advice: http://www.gimp.org/source/howtos/stable-cvs-build.html Basically, you should follow these steps: - Decide where you want to install the GIMP, GTK+ and other libraries. The HOWTO defines a variable $PRE for that. You can set it to /usr/local/ or even /prefix/, but _not_ /usr/ or /opt/gnome/. - Set $ACLOCAL_CFLAGS and $PKG_CONFIG_PATH so that they include the right directories under $PRE. Don't forget to update your $PATH if necessary. See the HOWTO and the example gimpenv script. - You may also have to add the directory $PRE/lib in /etc/ld.so.conf. - Extract glib-2.6.2, pango-1.8.0, atk-1.9.0 and gtk+-2.6.2 somewhere in a build directory. - For each of these libraries, do: ./configure --prefix=$PRE make make install sudo ldconfig (you can add other parameters to configure if necessary, such as --with-xinput=yes for gtk+, threads options for glib, etc.) - Then you can go to your GIMP CVS directory and do: ./autogen.sh --prefix=$PRE --disable-gtk-doc --disable-print For recent distros, that's all you need to do. For older ones, you may have to start by installing a more recent version of fontconfig and libart2 (libart_lgpl) in $PRE before building GLib and GTK+. For even older distributions such as SuSE 8.1 or 8.2, you will also have to install a newer libiconv, gettext and freetype2 (maybe also a newer pkg-config). Some old distributions may also require a newer version of expat before building fontconfig. In all cases, the installation goes smoothly as long as you specify the right prefix ($PRE) and have the right $PKG_CONFIG_PATH. Summary of the order in which you should install newer packages: - libiconv 1.9.x (only for very old systems) - gettext0.14.x (only for very old systems) 0.13.x should also work - pkg-config 0.15.0 (only for very old systems) - expat 1.95.x (only for very old systems) - freetype2 2.1.9 (only for old systems) - libart22.3.x (only for old systems) - fontconfig 2.2.x (only for old systems) - glib 2.6.2 - pango 1.8.0 - atk1.9.0 - gtk+ 2.6.2 - gimp (CVS) Links to the relevant libraries are on http://www.gimp.org/source/, except for iconv and gettext that are available on any GNU mirror (if you need them) and expat from http://www.libexpat.org/. In all cases, you should double-check first that the missing package is not already provided by your distro in a -dev or -devel package. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpConfig
On Sat, 22 Jan 2005 14:00:42 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Raphaël Quinet [EMAIL PROTECTED] writes: [...] I am worried about the configuration parameters that could be used by more than one plug-in. Of course plug-ins must not access gimprc directly. gimprc is the core rc file and must only be read and written by the core. I was rather thinking of letting each plug-in use it's own config file, located in the ~/.gimp-2.x directory. I expected this suggestion, which is why I wrote that I was worried about the parameters the could be used by more than one plug-in. If each plug-in uses its own config file, then it will become tricky for two plug-ins to share some config settings. This could happen if the load and save plug-ins for some file format want to share some settings, or for parameters that could be shared by many plug-ins, such as some metadata (default author, default copyright/license, etc.) or color profile information, whether some conversions should be done automatically, ... Some of these things could be handled by the GIMP and stored into global parasites as we already have the default comment but that would only solve a part of the problem. Besides, I would prefer to get rid of the default-comment parasite and move that to a proper GimpConfig object instead of having to add several new global parasites for the configurable defaults of some other parts of the metadata (author, copyright, etc.). So we still have a problem for the settings that are used by more than one plug-in. If two plug-ins (or a plug-in and the core) want to save some settings into the same file (gimprc or some other shared file) and do it at the same time, then you don't know if you will only get the settings from one, from both, or if you will get garbage. Although the race conditions would not occur too often and we could decide to ignore them, there are some situations that make them more likely. For example, when you have several images open and you save them all before quitting the GIMP. Regarding concurrent writes, I should probably note that GimpConfigWriter writes to a temporary file and moves it to the final destination when done. This is a good thing and that prevents the garbage case from happening. But there is still a problem if two plug-ins want to update some config settings stored in the same file: you will only get the updates from one plug-in (or from the core), but you don't know which one. Of course, if both plug-ins want to update the same settings, then the user will only get what he deserves. But if they want to update different settings (no conflict) then one of them will be lost. This could be avoided if all GimpConfig updates were serialized through the PDB. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved rect select tool
On Thu, 20 Jan 2005 23:10:18 +0100, Daniel Egger [EMAIL PROTECTED] wrote: On 20.01.2005, at 22:07, Sven Neumann wrote: That sounds akward. Why would I have to convert a selection to a selection? This should be hidden from the user. A generic way to manipulate active selections would certainly be preferable so that arbitrary shaped selections can be moved and (re-)sized by any amount in either directon instead of just manipulated by boolean operations with new selections or grown/shrunk. Several proposals for the selection tools have already been discussed in 2002. I like the idea of being able to modify the current shape freely until it is confirmed in some way. This could be done for the rectangle and ellipse (and rounded rectangle if we ever add this) by having a generic way to adjust the bounding box of the selection. After the shape is applied/confirmed, it could be combined with others using the usual boolean operations. See this interesting bug report for more details: http://bugzilla.gnome.org/show_bug.cgi?id=91934 A similar discussion took place for the crop tool: http://bugzilla.gnome.org/show_bug.cgi?id=91846 This is also akward. The crop tool shouldn't have a dialog, nor should we add one to a possible new rectangle tool. The current rect-select tool shows how the tool-options can be used for this. However, as long as such a generic method does not exist, I'd rather have a well-known interface like the one of the crop tool instead of the current behaviour. The current selection tools are annoying enough to be barely of any use without rulers for anything larger than a 100x100 pixel icon with some heavy magnification. I agree with Sven here: we should get rid of all pop-up dialogs for the tools. If additional input such as dimensions or aspect ratio is required for a tool, then this should be part of the tool options instead of having a separate window which often gets in the way and can steal the input focus, etc. See also bug #85579. As always, everything is open to change, and nothing is written in stone, and all feedback is welcome. I will try to sit down later today and write up a completely different proposal since I don't like your's at all. I for one prefer Bills' approach much to what we have now; but lets see what you'll come up with. I also think that Bill's approach is interesting, but I would prefer a generic concept that can be applied to all selection tools and could also be used to improve the crop tool. I hope that Sven will come up with a good proposal. In the meantime I recommend that you have a look at bug #91934 (linked above), especially comment #5 from Simon. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpConfig [was: jpeg-exif development summary]
On Fri, 21 Jan 2005 00:29:00 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Raphaël Quinet [EMAIL PROTECTED] writes: So the default should be to open the images with the correct orientation without asking, and there should be an option in the preferences (gimprc) that allows the user to ignore the EXIF Orientation tag or to be asked every time. The threshold for adding new options to the gimprc should be high, but I think that this one deserves it. Sure, that has never been questioned. The best thing would probably be to add a [ ] Don't ask me again toggle to the dialog. Well, the main point was that most users should not even see that dialog once, unless they explicitely change the default option in the preferences. This is in line with what other programs are doing and it is IMHO better because most users should not have to care about the details of the file format. But I would suggest that this is delayed until we have established a framework for plug-ins to deal with such preferences. It would be wrong to depend on a modifications to the core here. All plug-ins should have an easy way to store configuration and presets. The current gimprc API in the PDB is not really sufficient for this. Even though the current gimprc API in the PDB is rather simple (both the query and set operations are limited to simple strings), it is not too bad. It is of course a good idea to improve it, but it should not be discarded too early. Using strings, there is the problem of marshalling/unmarshalling the data, but having to use the PDB for this is a good feature from my point of view: it automatically avoids some concurrency problems that could occur if the plug-ins were accessing files directly. It also provides a single point from which some additional policies could be applied. If we want to improve the image export functionality, and I think we want to do that for 2.4, we will also need such functionality. I want to suggest that we implement this by moving most of the GimpConfig functionality from the core to libgimpbase or, alternatively, to a new library, maybe called libgimpconfig. We should try to get this done early in 2.3 since it will allow us to solve quite a bit of useability issues that people have with plug-ins. [...] This is again a good idea, but does this mean that the plug-ins converted to use GimpConfig would then start accessing the config files directly? I would prefer to make sure that all set/get operations for the configuration options are going through the PDB and handled by the core (this could of course be done transparently by the GimpConfig implementation). If not, then it will be necessary to implement some kind of locking mechanism for the files, in order to avoid problems in case the core and a plug-in are trying to update the same file. I am worried about the configuration parameters that could be used by more than one plug-in. There are a few things that we will need to decide upon, like in which library this should live, what namespace it should use (is GimpConfig a good name?), and how much of the core GimpConfig we actually want to expose to plug-ins and modules. There are a couple of features like the ability to nest objects that would perhaps better be kept for the core only as they add quite a bit of complexity. For the namespace, GimpConfig is fine. GimpProperty (or GimpPlugInProperty) could be better for those who are familiar with Java and persistent properties, but could also introduce some confusion with the existing usage of properties that can be set on objects. Regarding the features, I agree that nested objects would be a bit overkill: being able to store simple data types (and edit them with the appropriate widgets) would probably be sufficient. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
