Re: [Gimp-developer] proposal for better status bar messages (long)
Hi, On Fri, 2006-06-23 at 11:49 -0700, Carol Spears wrote: what is the purpose of a toggle that says Background? There is no toggle that says Background in the options of this tool. That's why I will not try to answer the rest of your mail. You would better look at the tool options again and stop annoying us with your unqualified mails. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
Hi, On Sat, 2006-06-24 at 15:34 -0700, [EMAIL PROTECTED] wrote: I estimate that I am about 15% finished on this task and that it will take me another two weeks to complete. Would this be sufficient for your scheduling needs? That would be sufficient but I am afraid that you misunderstood the task that I am asking you to do. You will see that the actual task is quite a bit less work. The registration blurb for 3dTruchet script: _This script generates a repeating pattern of Truchet tiles (which are randomly oriented quadrants of a circle). The arcs of the tiles are given a 3-D effect using a gradient of the specified colors. The resulting size of the image is determined by a combination of the tile size and the total number of tiles. That's nice, but the task is to come up with a short string that must fit into a single line and is oriented towards the user, not towards a script programmer. The string will be visible in the status bar when browsing the menus. Something like the following would be appropriate for your example: Generate a repeating pattern of Truchet tiles Please have a look at the plug-ins. We have done this there already and the script-fu blurbs should match that style. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
Sven Neumann stated: I am afraid that you misunderstood the task that I am asking you to do. For what it's worth, I did examine the plug-ins but they have two blurb strings available (one for the status line and one for the plugin's Help dialog) whereas Script-fus seem to only have the one. I had mistakenly assumed that the intent was to have a more complete description appear in the script's Help dialog. I understand now what is expected (and certainly a single line blurb will be much easier to produce). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
On Sat, 24 Jun 2006 [EMAIL PROTECTED] wrote: Date: Sat, 24 Jun 2006 15:34:52 -0700 From: [EMAIL PROTECTED] To: gimp-developer@lists.XCF.Berkeley.EDU Subject: Re: [Gimp-developer] Script-Fu procedure blurb review initially set the generated image to clean. It seems unnecessary to prompt for save when closing an unmodified logo; the logo can easily be regenerated with the same values by re-running the script. I've considered this before, it would probably be a good idea. The only reason I could come up with as to why you might want to mark the image as dirty/modified was in cases where there was a stack full of undo steps the user might want to play with. I generally prefer to allow easier modification of things laterby providing seperate layers. -- Alan ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
Hi, On Tue, 2006-06-27 at 05:09 -0700, [EMAIL PROTECTED] wrote: For what it's worth, I did examine the plug-ins but they have two blurb strings available (one for the status line and one for the plugin's Help dialog) whereas Script-fus seem to only have the one. I had mistakenly assumed that the intent was to have a more complete description appear in the script's Help dialog. Yes, unfortunately the Script-Fu API only has a single string for this purpose. I thought about changing it in one way or another (backwards-compatible of course). But since only a handful of scripts did actually provide useful help, I decided that we better use that string for a short blurb. More detailed help should probably go into the user manual instead. Sven ___ 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
Raphaël Quinet wrote: /* 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); The prototype for gimp_metadata_encode_xmp() seems inconsistent to the pattern of the other functions you listed. I would have expected it to be: gboolean gimp_metadata_encode_xmp (gint32image_ID, guint*xmp_size, const gchar **xmp_block); 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. Are you proposing in step 2 of your Example of use above that it be done automatically in the file load plug-ins? I think that would make sense. Any XMP/EXIF data for an image should be converted to parasites on file load and coverted back to XMP/EXIF data on file save. -- Cheers! Kevin. http://www.interlog.com/~kcozens/ |What are we going to do today, Borg? Owner of Elecraft K2 #2172|Same thing we always do, Pinkutus: | Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Mask to selection
Hallo, does there exist a mask to selection function that can be called from within a plug-in? Have I missed it in gimp api? Thank you Ollie ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Mask to selection
On Tuesday 27 June 2006 10:41 pm, sampin wrote: Hallo, does there exist a mask to selection function that can be called from within a plug-in? Have I missed it in gimp api? Hi sampin, Use gimp-selection-load. 'masks' count as 'channels' for gimp-internals purposes. Thank you Ollie ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp python
In bug #346001, Sven wrote: Comment #3 from [EMAIL PROTECTED] (GIMP developer, points: 23) 2006-06-27 13:47 UTC [reply] If you ask me, Python-Fu must not install any plug-ins at all as long as the user interface doesn't hold up to our standards. This includes complete internationalization and localization. I suggest that we disable installation of Python plug-ins for the 2.4 release. (http://bugzilla.gnome.org/show_bug.cgi?id=346001) I consider this both sad and grave. IMHO, the build of python-fu by default, and support for it under Redmond OS is one of the greatest things in this development cycle. I will undertake i18n of the python-fu then, with no delays. What else do you consider important for the UI to have for it to keep up with gimp standards? Regards, JS -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
Sven Neumann wrote: On Sat, 2006-06-24 at 15:34 -0700, [EMAIL PROTECTED] wrote: The registration blurb for 3dTruchet script: _This script generates a repeating pattern of Truchet tiles (which are randomly oriented quadrants of a circle). The arcs of the tiles are given a 3-D effect using a gradient of the specified colors. The resulting size of the image is determined by a combination of the tile size and the total number of tiles. That's nice, but the task is to come up with a short string that must fit into a single line and is oriented towards the user, not towards a script programmer. The string will be visible in the status bar when browsing the menus. Something like the following would be appropriate for your example: Generate a repeating pattern of Truchet tiles Is there a particular need for these blurbs to be short one liners other than making things easier for the translaters? I don't think they should be shortened to the extent that information useful to users might get lost. The example above loses the fact that it is a repeating pattern of 3D Truchet files. One option would be to move the longer blurbs in to the comments at the top of the script files to preserve any information in the blurbs which might be useful to users of the scripts (such as any restrictions for entered values). -- Cheers! Kevin. http://www.interlog.com/~kcozens/ |What are we going to do today, Borg? Owner of Elecraft K2 #2172|Same thing we always do, Pinkutus: | Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
Hi, On Wed, 2006-06-28 at 01:17 -0400, Kevin Cozens wrote: Is there a particular need for these blurbs to be short one liners other than making things easier for the translaters? Yes, they need to fit into the statusbar and should follow the same style that plug-ins use for the blurb. One option would be to move the longer blurbs in to the comments at the top of the script files to preserve any information in the blurbs which might be useful to users of the scripts (such as any restrictions for entered values). If this information was available, it should of course not be thrown away but should be moved to a comment. But since almost no script provides such information, that's an academic question. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
