Re: [Gimp-developer] jpeg-exif development summary
On Thu, 20 Jan 2005 05:21:37 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [re-formatted to include proper quoting] Alastair M. Robinson wrote: Robert L Krawitz wrote: Raphael's proposal sounds right on the money to me. It comes down to a question of what's most annoying: (1) having to rotate manually an unknown, but possibly quite small number of existing images, on a one-off basis, or (2) having to dismiss (or find a way of permanently disabling) an extra dialog for every existing and future image that has the relevant EXIF flag set. (3) somebody write a command-line tool that will just strip the flag from all the images in a directory (for those who have been using bad versions to fix all their images), along with option (1) above, keeping the kludge out of gimp, while providing the service. Fortunately, there are already several command-line tools available for that, as well as several GUI tools that have some kind of batch mode. One example of such a command-line tool is Jhead. You can either use the option jhead -autorot to rotate the image and clear the EXIF Orientation tag, or use the option jhead -norot to clear the EXIF Orientation tag without rotating the image, assuming that some broken program has already rotated the image without updating the EXIF info. I have also seen some shell scripts that use the command-line exif program to change the value of the Orientation tag directly. So there are already many ways to fix the JPEG files with EXIF info that have been incorrectly handled by some programs (such as GIMP 2.2, but hopefully not 2.4). Although I think that option (1) above should be the default instead of (2), I think that (2) can still be useful in some cases. Some of the EXIF-aware image editors that I looked at are also offering an option to ignore the EXIF Orientation tag (this is never the default, though). Bill has already written the code for asking the user, so let's not throw that away. 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. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script-fu documentation
Campbell Barton wrote: Will thge gimp move to tiny-fu compleately? I am not aware of any plans to replace Script-Fu with Tiny-Fu in the GIMP source tree. Although that might change now that I am about to start testing the Tiny-Fu changes which added UTF-8 support. If Script-Fu was pulled out as a separate module it would make it easier to let users/packagers choose which of the two Scheme-based plug-ins they wish to use. For now, the two will happily co-exist. It may be time to start a message thread about this with the recent branching of GIMP. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] we need more documentation
On Mon, Jan 10, 2005 at 09:38:51PM +0100, Sven Neumann wrote: now that GIMP 2.2 is out and the major problems with the early 2.2.x releases seem to have been fleshed out, it would be nice if we could put some effort into documenting some of the new stuff that's hidden in the 2.2 version. So this is a plea for help on documenting things. I am sorry that I don't have the time to do all this myself, but I can at least try to make a list of things that I think would be worth writing about... i have been working on some of the things on this list. i am curious what others have accomplished towards fullfilling this reasonable request. - nifty things you can tweak in the Preferences dialog and in gimprc i am currently working on the Preferences dialog and am in need for some sane words to describe how to set the units globally. i realize it was discussed on this mail list, however i am finding it difficult to concisely explain how to set the units globally in the way a user could understand and in a way that is actually effective globally. - customizing the GIMP user interface i have two different documents describing how to change the gimps docks and tabs; a short description and a long one. the shorter version: http://carol.gimp.org/gimp2/basics/gui/docks-tabs.html the longer version: http://carol.gimp.org/gimp2/basics/gui/all_my_docks_and_tabs.html - customizing the splash image http://carol.gimp.org/gimp2/basics/gui/splashes/ in addition to the requests on this list, i wrote about how to configure the gimps gtkrc to adjust the plug-in preview size here: http://carol.gimp.org/gimp2/basics/gui/gtkrc.html i am open to corrections and suggestions and/or i will be happy to put the urls to everyone elses effort to fullfill the requests found on this list from these pages. i am really stuck understanding how the new gimp handles units globally, perhaps it is a condition of too much information. a nice concise user friendly explanation of how it works now and what we get from this change would help me (and others). thanks, carol ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On French Translation
Hi, Louis Desjardins [EMAIL PROTECTED] writes: I have a translation issue with the most recent version (GIMP 2.2) and would like more info, please. While many menus and strings are correctly translated into French, lots of others remains in the original version, English. Are there short term plans to address this issue? Is it a known issue? I guess this is meant as an offer to help with the french translation. Otherwise it certainly doesn't belong here. So, please get in contact with the french translation team of the GNOME Translation Project (http://developer.gnome.org/projects/gtp/) and coordinate your efforts with them. Thanks. Sven ___ 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
Hi, William Skaggs [EMAIL PROTECTED] writes: I have been working on a new rectangle-select tool to meet some of the deficiencies of the existing one, and would like to commit what I have to cvs if it is okay. Please don't commit this before we have finished this discussion (that we should have had before you wrote the first line of code). Here is an overview of what I have currently: The New Rect Select is implemented as a separate tool, which does not conflict with the existing rect-select tool and would not replace it until everybody is satisfied with it. The source code is based on the crop tool, and in many ways resembles it, although there are important differences. The crop tool code is the most broken piece of code in that directory. What we really need is not another Crop tool but an abstract rectangle tool that the crop tool, text tool and perhaps even the rect-select tool can be derived from. The tool options have two new entries, toggles for Adjustable and Show dialog. If Adjustable is checked, then the shape of the rectangle can be modified after it has been drawn, by moving the corners in the same way that works for the crop tool. Once it is satisfactory, clicking inside the rectangle converts it into a selection. Clicking outside the rectangle cancels the tool. If Adjustable is not checked, then the rectangle is converted to a selection as soon as the mouse button is released. (That is, it behaves like the existing rect-select.) That sounds akward. Why would I have to convert a selection to a selection? This should be hidden from the user. If Show dialog is checked, then a dialog closely resembling the crop tool dialog is shown whenever the tool is working, allowing values to be entered using the keyboard, and also containing buttons labeled From selection and Auto shrink. (The From selection button creates a rectangle to fit the bounds of the existing selection.) 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. 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. Sven ___ 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
Sven wrote: 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. I'll defer responding to your other points until I see your proposal, but I would like to respond to this one. I think, on the contrary, that the tool options should be used for choices that are (at least potentially) persistent, and that input only relevant to the current application of a tool should be done using a dialog (*). The reason for this is that it is generally best to keep the tool options dialog fixed in size and location, but a pop-up dialog can be positioned and sized as needed. I don't actually share your negative attitude toward the crop tool. The only real problem with it is that the dialog gets in the way when it is not wanted, but that could easily be solved by adding a Show dialog option to the crop tool options. On the other hand, I find the current rect-select options pretty unpleasant to use. -- Bill (*) -- There are exceptions. It isn't worth creating a dialog for one or two buttons, for example the Path to Selection button in the Paths tool. __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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 20.01.2005, at 22:07, Sven Neumann wrote: Please don't commit this before we have finished this discussion (that we should have had before you wrote the first line of code). Typically a proof of concept implementation is more than welcome, so your attitude is hardly understandable. 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. 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. 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. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Improved rect select tool
Hi, Daniel Egger [EMAIL PROTECTED] writes: I for one prefer Bills' approach much to what we have now; but lets see what you'll come up with. I didn't say it's worse than the current approach but it completely contradicts all the work that has gone into GIMP in order to pave the way for better selection tools. I don't want to see that work being wasted and since we are at the very beginning of a development cycle, we don't need to go for quick-and-dirty solutions. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpConfig [was: jpeg-exif development summary]
Hi, Raphal 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. 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. 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. In the core we already make heavy use of the GimpConfig interface. It basically adds serialization capabilites to any GObject that implements it. There's a default implementation that takes care of serializing and deserializing all object properties that have a certain flag set in their GParamSpec. GimpConfig was originally developed to solve the problem that it used to be a PITA to add a new configuration value to gimprc. Nowadays this is as simple as adding a new property to one of the classes that form the GimpRc object. Adding a property to a GObject involves registering a param-spec, a description of the property that defines the type of the value and includes a default value, a description and more. This information can then be used to serialize the value (generate a string representation) and to deserialize it (load the serialized values back in). No extra code needs to be written for this. The addition of the object properties also pays out when a user interfaces is needed to control the properties. We have a couple of convenience constructors in the core. The more generic ones could also be moved to libgimpwidgets. We use these functions to create the widgets in the tool-options dialogs and also the preference dialog. For example in order to create a check-button with a label next to it, we call gimp_prop_check_button_new (config, property_name, label_text); The returned button is a view on the property value. It is synced with the object config. Any change to the button is applied to the object and the button will also change it's state if the value changes by other means. Having this functionality available for all plug-ins and modules will certainly improve things. Plug-in user interface often mainly consist of a couple of widgets to control a number of configurations. If the plug-in implements an object that represents this configuration, the GUI code reduces to a few lines. Implementing a Reset button boils down to calling gimp_config_reset(). This will reset all object properties to their default values. Saving the current values as new default values would also become trivial. Even maintaining a couple of configurations like we do for the tool-options is easy. We can probably implement that as convenience functions in GimpDialog. The next step would of course be to move the PDB to using object properties as well. The work invested in porting plug-ins to GimpConfig will pay out again then. 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. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpContext and Gimp Perl's non-thread safe resources
Hello, I'm not sure if I am understanding the new GimpContext functionality correctly. I had hoped it would resolve issues that my Gimp Perl script has with certain non-thread-safe resources when multiple instances of the script are running concurrently. For example one instance changing the foreground color that another instance is using to render text. It happens infrequently but when I run multiple versions of a script with code like the following I still see occasional images being rendered with incorrect colors: Gimp::init; my $img = gimp_image_new(300, 200, 0); gimp_context_push(); gimp_context_set_background([60, 108, 222]); gimp_context_set_foreground([255,255,255]); my $text_layer1A = gimp_text_fontname($img,-1,0,0,The Quick Brown Fox, 0, 0, 14, 0, Arial); gimp_context_set_foreground([0,0,0]); my $text_layer1B = gimp_text_fontname($img,-1,5,5,Jumped Over the Lazy Dog, 0, 0, 14, 0, URW Gothic L); gimp_context_set_foreground([237,16,16]); my $text_layer2A = gimp_text_fontname($img,-1,0,20,The Quick Brown Fox, 0, 0, 14, 0, Arial); gimp_context_set_foreground([0,0,0]); my $text_layer2B = gimp_text_fontname($img,-1,5,25,Jumped Over the Lazy Dog, 0, 0, 14, 0, URW Gothic L); ... code to save image ... gimp_context_pop(); Gimp::end; Is there anything that takes place behind the scenes that makes sure that each script is running in its own context? Or does the call to gimp_text_fontname simply use the latest context added to the stack, allowing for something like script x switching to look at a context pushed by script y while in the middle of executing calls to gimp_text_fontname? I guess I'm looking for something more like: my $context = gimp_create_context(); $context-set_foreground([255,255,255]); # this call uses the context's foreground color gimp_text_fontname($img,-1,0,0,The Quick Brown Fox, 0, 0, 14, 0, Arial); $context-delete(); I can see how push and pop would make sense for a plugin, but wonder if there's an alternate way for batch image scripting to make use of it. Thanks in advance, Jared Jared WhitingMyers Internet, Inc. Senior Developerhttp://www.myers.com (408) 428-9960 Taking Your Business To The Next Level ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpConfig
Sven wrote: 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. [ . . . ] 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. Looking at the code, it seemed to me that these would be good things to do, and not all that hard. There is plenty of space in libgimpbase, and the name GimpConfig seems perfectly fine. The code in app/config is nice and clean, and separates easily into things that can be moved without too much trouble, and things that ought to stay there. It also seemed to me that the best way to do it was in a single burst of furious energy, because it would be quite difficult to do it gradually and have GIMP continue to build during the process. And then a fit of insanity came over me . . . When I came back to consciousness about six hours later, somehow in my personal tree all these files had migrated over into libgimpbase: gimpconfig.[ch] gimpconfig-deserialize.[ch] gimpconfig-error.[ch] gimpconfig-params.[ch] gimpconfig-path.[ch] gimpconfig-serialize.[ch] gimpconfig-types.[ch] gimpconfig-utils.[ch] gimpconfigwriter.[ch] gimpscanner.[ch] gimpxmlparser.[ch] And somehow the includes had been fixed in about 200 files scattered through the core code so that app would actually build. There is some significant ugliness involved -- in particular, I have config/config-types.h included in a lot of places where it shouldn't be -- but the point is that it builds, and things like that can be fixed one file at a time without breaking the build. So now I have this mass of code that is going to bitrot at a furious rate unless something is done with it, and I am wondering if I can unload it. Best, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
