Re: [Gimp-developer] On French Translation
On Thursday 20 January 2005 05:20, Louis Desjardins wrote: Hi, I am new to this list and new to Gimp as well. 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? Well, the problem may be in the fact that the French translation is incomplete, and so gettext leaves the English phrases that were not translated as is. So, it is a known issue in all non-English languages for which there is an incomplete translation. As for addressing them: we need people to volunteer on completing the translation. Are you willing to volunteer? Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Knuth is not God! It took him two days to build the Roman Empire. ___ 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
[Gimp-developer] fourier transform (wiener filter)
yesterday there was a discussion going on about fourier transform. Before the feature freeze for Gimp 2.2 i was working on a wiener filter plugin. This filter uses a fourier transform. A first version is available at http://users.pandora.be/geert.jordaens/wiener/ I also started on writing a chirp-z transform to replace the FFT that is right now implemented in wiener.c. Just wanted to share this. Geert ___ 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
I would hope that if ScriptFu is pulled out, TinyFu will also provide an interpreter directly in GIMP's GUI that one can use interactively. (I haven't used TinyFu)... Perhaps the two interpreters could also co-exist as part of the normal build for one release, at least, while scripts get converted? Just a thought... _-T ___ Speed up your surfing with Juno SpeedBand. Now includes pop-up blocker! Only $14.95/month -visit http://www.juno.com/surf to sign up today! ___ 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
In my experience, being implimentation agnostic is not good- it can fragment the scripting community, Script X dosent work with Tiny fu but and VsVercer for other scripts ,.. you know, it just gets messy. Its best top keep to one, newbies will ask which to use and get confusticated answeres by opinionated experts. Sounds like tinyfu is better and smalled, grerater development? Why not switch? - Cam PS, Im implying that scripting in the 2 script-fu ansd tiny fu isnt the same, if it is - then maby my arg dosent hold, tho in my expereince implimentations are useually diff. [EMAIL PROTECTED] wrote: I would hope that if ScriptFu is pulled out, TinyFu will also provide an interpreter directly in GIMP's GUI that one can use interactively. (I haven't used TinyFu)... Perhaps the two interpreters could also co-exist as part of the normal build for one release, at least, while scripts get converted? Just a thought... _-T ___ Speed up your surfing with Juno SpeedBand. Now includes pop-up blocker! Only $14.95/month -visit http://www.juno.com/surf to sign up today! ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- Campbell J Barton Sierra Suites Hotel 32 Fourth Av Waltham, Room 103 phone: 781 622 1900 mobile: 617 935 6773 133 Hope Street Geelong West, Victoria 3218 Australia URL:http://www.metavr.com e-mail: [EMAIL PROTECTED] phone: AU (03) 5229 0241 smime.p7s Description: S/MIME Cryptographic Signature
Re: [Gimp-developer] script-fu documentation
[EMAIL PROTECTED] wrote: I would hope that if ScriptFu is pulled out, TinyFu will also provide an interpreter directly in GIMP's GUI that one can use interactively. (I haven't used TinyFu)... Tiny-Fu was built using the framework of Script-Fu. It has all the main features of Script-Fu (except for the Browse button in Console mode) but users a Scheme interpreter which follows the standards more closely than the interpreter used in Script-Fu. I would suggest you look at the web page and go over the FAQ in the meantime. It should help you better understand the Tiny-Fu project and how it compares to Script-Fu. You could even try using it. :-) For those of you who don't already know, the Tiny-Fu web page can be found at: http://www.interlog.com/~kcozens/software/gimp/tiny-fu.html (And to some others on gimp-devel: Yes, I know I said I would write an e-mail a while back to talk about Tiny-Fu and to sell it. I swear its on my ToDo list. Other projects have kept it from getting to the top of the list. I will write something up about this long before GIMP 2.4 is released. Really!) co-exist as part of the normal build for one release, at least, while scripts get converted? Just a thought... I started development of Tiny-Fu in a copy of the GIMP source tree. Now I work on it outside the source tree as it is now a separate module. I don't see it getting added to the main tree any time soon and I don't think it should be. Anyone who can build GIMP can download the source for Tiny-Fu, build it, and install it along side Script-Fu. For the Windows users a pre-built binary exists. I don't have the space available to host pre-built binaries for all the different OS and distro's which can run GIMP but I would be happy to provide pointers on the Tiny-Fu web page to any binaries which someone else builds and makes available for download. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|What are we going to do today, Borg? E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpContext and Gimp Perl's non-thread safe resources
Hi, Jared Whiting [EMAIL PROTECTED] writes: Is there anything that takes place behind the scenes that makes sure that each script is running in its own context? Scripts and plug-ins are by default run in the user context. Changing this would have broken backward compatibility so we had to choose the API where plug-ins and scripts have to push their own context if they want to run in their 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? The context stack is local to the current procedure. So if your script is executed in it's own procedure call and pushes a context, then that context is local to that script and can not be accessed by anyone else. Basically my answer boils down to: I don't believe that your scripts are misbehaving the way you described. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
