Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
Hi, Kevin Cozens [EMAIL PROTECTED] writes: Another way to look at this is from he point of view of help/documentation. Someone has to create information somewhere that documents the constants used for plug-ins (whether they be C-based, Script-Fu, or Perl). Are you talking about the API docs at developer.gimp.org? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Thu, Jan 29, 2004 at 12:27:44PM -0500, Kevin Cozens [EMAIL PROTECTED] wrote: Is the - vs _ use in function names by C vs. Script-Fu historical (as in typical of the respective languages)? Yupp. values for plug-ins based on different languages? DB Browser shows GIMP_RGB_IMAGE for an image type (for C) but its only RGB-IMAGE for Script-Fu scripts and I have no idea off-hand what it would be for Perl plug-ins (a third set of enums?). Just FYI, perl uses the enums.pl from the gimp core which lists all the enums. It does, however, do this: $const =~ s/^GIMP_//; i.e.., strip the GIMP_-prefix, so the contants are the names with _ (easier to type in perl than -), but withouth the prefixes. Looks like a third set to me. (Also, perl isn't updated automatically, you have to run a script, so it might be sightly out of sync). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
At 09:01 AM 01/30/2004, Marc Lehmann wrote: Just FYI, perl uses the enums.pl from the gimp core which lists all the enums. It does, however, do this: $const =~ s/^GIMP_//; i.e.., strip the GIMP_-prefix, so the contants are the names with _ (easier to type in perl than -), but withouth the prefixes. Looks like a third set to me. A third set? I was afraid that might be the case. (Also, perl isn't updated automatically, you have to run a script, so it might be sightly out of sync). I will take a look at the way gimp-perl does things. The script should be invoked during a build process as it is for the core part of GIMP. Sven isn't sold on the idea of deprecating some of the constants yet. We already have deprecated constants as you can see in the comments in the siod-wrapper.c file. Another way to look at this is from he point of view of help/documentation. Someone has to create information somewhere that documents the constants used for plug-ins (whether they be C-based, Script-Fu, or Perl). If we have one set of constants for use in all plug-in languages the constants only need be documented once for C. For other languages you would need a one liner explaining whether they are the same as for C or whether you need to change _ to - and you are done. Otherwise, you need to have two or three lists all of which need to be updated if/when the API changes. 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 [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Fri, Jan 30, 2004 at 11:57:32AM -0500, Kevin Cozens [EMAIL PROTECTED] wrote: i.e.., strip the GIMP_-prefix, so the contants are the names with _ (easier to type in perl than -), but withouth the prefixes. Looks like a third set to me. A third set? I was afraid that might be the case. Well, a set extremely similar and in-sync (at least loosely) to the C contants, so while technically different constant names, there is a very easy rule to convert from C to Perl: drop the GIMP_. The gimpdoc program already converts between C and Perl method syntax, so it could just be extended to drop DIMP_ for Contants, too. The pdb documentation is almost parseable nowadays (or at leats when I last looked). I will take a look at the way gimp-perl does things. Constants are hardcoded in Gimp.pm, and there is a program named insenums which will replace these in-place. The script should be invoked during a build process as it is for the core part of GIMP. Not so quickly ;) Changes in these enums will immediately break existing scripts, which is a very bad thing. Also, some wild renaming during the 1.3 era resulted in duplicated constants that had to be resolved differently, so this usually involves some manual work, which is why the script has to be run manually, too. Another way to look at this is from he point of view of help/documentation. Someone has to create information somewhere that documents the constants used for plug-ins (whether they be C-based, Script-Fu, or Perl). If we have one set of constants for use in all plug-in languages the constants only need be documented once for C. I am not sure wether I understand your concept of sameness. To me, GIMP_RGB_IMAGE, RGB-IMAGE and RGB_IMAGE is exactly the same constant, just as gimp-drawable-add-layer is the same as gimp_drawable_add_layer and $drawable-add_layer. For other languages you would need a one liner explaining whether they are the same as for C or whether you need to change _ to - and you are done. This is the situation with perl right now, although that line is probably hard to find, but people don't read this type of documentation anyway, they just look at other scripts, and then consistency really pays off. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Fri, 2004-01-30 at 13:06, [EMAIL PROTECTED] wrote: On Fri, Jan 30, 2004 at 11:57:32AM -0500, Kevin Cozens [EMAIL PROTECTED] wrote: A third set? I was afraid that might be the case. Well, a set extremely similar and in-sync (at least loosely) to the C contants, so while technically different constant names, there is a very easy rule to convert from C to Perl: drop the GIMP_. The gimpdoc program already converts between C and Perl method syntax, so it could just be extended to drop DIMP_ for Contants, too. I will take a look at the way gimp-perl does things. Constants are hardcoded in Gimp.pm, and there is a program named insenums which will replace these in-place. For Script-Fu, the leading GIMP- part was being dropped. I will leave the gimp-perl stuff alone for now but for consistancy, it should be updated to accept the new versions of the enums as well as the existing (backwards compatible) ones. I am not sure wether I understand your concept of sameness. To me, GIMP_RGB_IMAGE, RGB-IMAGE and RGB_IMAGE is exactly the same constant, just as gimp-drawable-add-layer is the same as gimp_drawable_add_layer and $drawable-add_layer. It is a case of a rose by any other name or in this case a constant by any other name to paraphrase Shakespeare. Yes, GIMP_RGB_IMAGE, RGB-IMAGE, and RGB_IMAGE are numerically the same. If you use numerical values for function call arguments, then you use the same numbers regardless of plug-in language. On the other hand, if you want to create a new image using an indexed palette its easier to remember to use GIMP_INDEXED_IMAGE rather than 4 or was that INDEXED_IMAGE, or INDEXED-IMAGE? What type of plug-in am I writing again? :-) You get the idea. For other languages you would need a one liner explaining whether they are the same as for C or whether you need to change _ to - and you are done. This is the situation with perl right now, although that line is probably hard to find, but people don't read this type of documentation anyway, they just look at other scripts, and then consistency really pays off. Thats right. People often don't RTFM apart from the difficulty one often has finding relevant documentation. If you go to http://www.gimp.org/, click on documentation, scroll down to the PDB section, then click on the Procedural Data-Base link you get a page called pdb.html. Under Browsing the PDB, it states the following: Because the PDB includes info about plugins, scripts, and extensions, it is very dynamic. The easiest way to search and browse the PDB is to use the DB Browser extension included with the gimp. This is located under the Xtns menu on the main toolbar and allows you to browse and search through the PDB. Very handy. Followed a bit further down with: A typical use of the PDB is to write scripts or plugins. Very handy indeed, and no reference to differences in the named constants based on whether you are writing a script or a (C-based) plug-in. Another reason to keep things close to what is listed under the DB Browser. People are told to use the DB Browser information and yet, it provides misleading information that could frustrate the budding new script writer out there. And finally, on line 263 of plug-ins/script-fu/siod-wrapper.c is a comment which reads: These are for backwards compatibility; they should be removed sometime Following that comment are statements which allow the parser to understand the older constants (ie. the ones not starting with GIMP-). I ran a CVS annotate on this file and that comment and the start of the code below to which allows the accepting of the older forms of constants was in the file since the 1.1 version entered by user mathieu and dated July 17, 2001. It appears in the end that I have merely finished something that was started a long time ago. My patch to accept both old and new forms of the constants is attached to the bug report. I also have the patch and my script to convert from the 1.2 API to the 2.0 API on my web page at: http://pages.interlog.com/~kcozens/software/gimp/updates.html If you want to include the conversion script as part of the GIMP source (as a replacement for plug-ins/script-fu/convert-script) feel free to do so. I have made my case for making the change and provided a patch (sorry I forgot to include a ChangeLog entry), and script to update things to the 2.0 API. I now leave it in the hands of the judges...er...core GIMP developers to decide what they want to do with this. At least I will have a patch I can apply to my own copy of the GIMP should the patch not become part of the official GIMP source. -- 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 |
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Fri, Jan 30, 2004 at 02:19:56PM -0500, Kevin Cozens [EMAIL PROTECTED] wrote:
regardless of plug-in language. On the other hand, if you want to create
a new image using an indexed palette its easier to remember to use
GIMP_INDEXED_IMAGE rather than 4 or was that INDEXED_IMAGE, or
INDEXED-IMAGE?
In perl, INDEXED-IMAGE needs to be quoted rather unnaturally
({'INDEXED-IMAGE'}), so perl users won't bother thinking about
this. Also, perl, unlike C, has mostly working namespaces, so prefixing
each and everything with an application/module name like GIMP_ is not
necessary.
Things are similar for script-fu (there are no namespace issues in
script-fu because it's self-contained and _ looks rather unnatural, I
think).
If somebody wants to write a plug-in in perl who only ever had written
plug-ins in C will have to think twice (at least), there is no doubt.
But a user having used perl before will look at some existing script
anyways (nobody writes plug-ins from scratch).
Think about the GIMP_ prefix as C's way to handle namespaces. As such,
it's part of the C calling convention only. This is handled different in
perl (Gimp::INDEXED_IMAGE or just INDEXED_IMAGE) and script-fu (script-fu
does not have a module or library concept to my knowledge, the the problem
of namespaces does not apply).
What type of plug-in am I writing again? :-) You get the idea.
Frankly, people forgetting which type of plug-in (in which language) they
are currently writing need professional help *g*.
I am rather convinced that the number of people who can't remember that
they are currently writing C as opposed to scheme is rather low compared
to people that are aware of this.
DB Browser. People are told to use the DB Browser information and yet,
it provides misleading information that could frustrate the budding new
script writer out there.
The DB Browser information should be consistent (i.e. for C _or_
scheme). The information in the DB Browser will never apply to perl
(python...) unless it would have a perl mode, as perl simply is a
different language with different calling conventions.
Constant names are a much smaller difference than calling conventions
between languages. It is, in general, impossible to use an API for one
language in another without adapting it to the target language.
And finally, on line 263 of plug-ins/script-fu/siod-wrapper.c is a
comment which reads:
These are for backwards compatibility; they should be removed sometime
It appears in the end that I have merely finished something that was
Cleaning up things by removing cruft like this is very useful, and often
being overlooked. Thanks for doing this :=
I'd also find it cool if you looked into the DB Browser and made it fully
scheme or fully C, i.e. consistent at least to one language. However,
the idea of having the same API, character-for-character, in all languages
is futile. Don't bother with it.
Changing script-fu to comply with this sounds ok, changing the Browser to
comply with script-fu is better, but more difficult (right now it's a mix
of both, or maybe the abstract PDB language?).
Perl specifically has a tool named gimpdoc, which shows calling
conventions in perl, e.g.:
layer = gimp_layer_new (image,width,height,type,name,opacity,mode)
layer = $image-layer_new (width,height,type,name,opacity,mode)
Which is close to actual perl, and should give developers the right
idea. It should convert constant names to perl form, too (it currently
doesn't, AFAICR). Having this info in the DB Browser might be useful, but
making the interface support all languages is quite difficult.
One could also argue that the DB Browser does things the abstract PDB
way, and is fine this way, although a bit unspecified, as long as rules
exist to convert them to specific implementations. In the case of perl,
these rules are stated in the Gimp manpage, which is a must-read if you
want to develop plug-ins from scratch.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
Greetings. I reported something I saw as a bug [bugzilla #132698] and Sven replied that DB Browser shows enum values used for arguments (ie. GIMP_RGB_IMAGE) as they would be used from C plug-ins. It would seem I haven't been following the GIMP development closely enough since I wasn't aware of this. It raises a number of questions though. Is the - vs _ use in function names by C vs. Script-Fu historical (as in typical of the respective languages)? Barring the issue of - vs _, why should we have a different set of enum values for plug-ins based on different languages? DB Browser shows GIMP_RGB_IMAGE for an image type (for C) but its only RGB-IMAGE for Script-Fu scripts and I have no idea off-hand what it would be for Perl plug-ins (a third set of enums?). One could also argue against the C format being chosen for display in DB Browser since a GIMP user would find it much easier (and would be more likely?) to develop their own plug-ins at first in Script-Fu (or possibly Perl) since all they need is a text editor and there are other scripts which can be used as a starting point. I'm also raising issue also because I thought that one of the goals for the 2.0 release is to simplify/tidy-up some things. Having more consistency in the enums used (regardless of language used for a plug-in/script and ignore - vs _ issues) makes sense (to me at least). Trying to get DB Browser to display different information based on you telling it which type of plug-in one wants to create is probably not a good alternative. I think it would add too much complexity and be hard to maintain. Comments? 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 [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
Hi, Kevin Cozens [EMAIL PROTECTED] writes: I'm also raising issue also because I thought that one of the goals for the 2.0 release is to simplify/tidy-up some things. Having more consistency in the enums used (regardless of language used for a plug-in/script and ignore - vs _ issues) makes sense (to me at least). Trying to get DB Browser to display different information based on you telling it which type of plug-in one wants to create is probably not a good alternative. I think it would add too much complexity and be hard to maintain. What are you advocating instead? Perhaps I just missed something but I have not been able to figure out what change you are proposing. The issue you raise has been around forever and it seems that so far you are the first one to find it disturbing enough to talk about it. Perhaps something should be done about this but I don't think it's a severe problem that would justify an incompatible change to any of the language bindings. IMO any language should be free to use the GIMP enum values in the way that is typical for the particular language. Script-Fu uses hyphens traditionally; why should we force it to using the (uglier) underscores that have to be used in the C language? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
At 12:45 PM 01/29/2004, Sven wrote: What are you advocating instead? Perhaps I just missed something but I have not been able to figure out what change you are proposing. The issue you raise has been around forever and it seems that so far you are the first one to find it disturbing enough to talk about it. I thought I had explained it in the bug report I filed but I will me try to make it clearer. In regards to the second point, perhaps it has disturbed other people but not enough to have mentioned it. you said yourself, Sven, in a comment to a bugzilla entry something to the effect that no one has expressed an interest in Script-Fu. I am still interested in Script-Fu. I am involved in a number of other projects so I haven't made the time to learn how to do a C-based plug-in. I find it easier to use Script-Fu to make a script that automates a set of steps I came up with to automate a procedure. In regards to the first point, I am advocating that the enum values shown in DB Browser (for C) be the same as the ones used in Script-Fu scripts (and other language bindings) to provide a better level of consistency across all plug-ins. That way, something you learned to use in one plug-in language doesn't have to be unlearned when you use a different language for plug-ins. For example, if I look in DB Browser for creating a new image, one of the enums shown for argument type is GIMP_RGB_IMAGE. So, since I know for Script-Fu scripts I use - in place of _, I would use GIMP-RGB-IMAGE. When I try running a script with this as things stand now, I will get an error message and be left scratching my head wondering what is wrong with the script since I followed the information shown in DB Browser. You, I, and many people on this list may have the source code available on their machines to figure out what the Script-Fu constants are as compared to what is shown in DB Browser but how many others will? Lately, I only update the collection of scripts on my web page to work with the latest GIMP when API changes. This means it can be a long time from one session of working with Script-Fu to another at my end. The handiest reference I have to refresh me on Script-Fu functions and their arguments is the DB Browser. An alternative would be to have a section of the help system explain that the information in DB Browser is for C plug-ins and provide a list showing the mapping between C enums to those of Script-Fu. This would still mean I have to dig through the help system when the DB Browser is still the quickest help system to access. Also, the help system can lag behind the state of the code at times too so it is not the best method during times of big changes. It would be easier if I could use GIMP-RGB-IMAGE in Script-Fu scripts as I would be led to believe from DB Browser. The only change needed to DB Browser would be adding the display of a comment before (or after) the functions entry information stating something like For Script-Fu scripts, change the _ in function names and arguments to -. Perhaps something should be done about this but I don't think it's a severe problem that would justify an incompatible change to any of the language bindings. If we are to make such a change, now is the time to do it. After all, we are going from a 1.2 release to a 2.0 release so it is to be expected that changes would need to be made to plug-ins from 1.2 to make them work in the new 2.0 version. The next opportunity to make a change would be for 2.2 which might be another year or two down the road but one wouldn't expect such incompatibilities in a minor bump in version (2.0 to 2.2). Changing enums (if one doesn't add new ones and make the old ones deprecated for a while) would mean most (or all) supplied scripts would need to be updated. I have a perl script which updates Script-Fu scripts from the 1.2 to 2.0 versions of the GIMP (except for three functions which have different argument lists). If enums were to change for Script-Fu it would be relatively easy to enhance my script to handle changes to enums as well. BTW, I will make the script available soon for others to try in case there are others out there who find old scripts they want to use with the 2.0 version of GIMP. PS. To all, please don't reply to messages I post to the list AND CC: me as well. Doing so gives me two copies of your message and I get enough e-mail already. I have been a subscriber to this list, and made my small contributions to the GIMP, since the days of the 0.9 series of the GIMP. I have been on gimp-announce too since late 1997. 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 ___
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
Hi, Kevin Cozens [EMAIL PROTECTED] writes: For example, if I look in DB Browser for creating a new image, one of the enums shown for argument type is GIMP_RGB_IMAGE. So, since I know for Script-Fu scripts I use - in place of _, I would use GIMP-RGB-IMAGE. When I try running a script with this as things stand now, I will get an error message and be left scratching my head wondering what is wrong with the script since I followed the information shown in DB Browser. So the easiest solution would be to make script-fu accept the enums with or without prefix. If we are to make such a change, now is the time to do it. The point is that it is already way too late to do any major incompatible change. Our API was frozen from the moment we did the first 2.0pre release. However I don't see any problem in accepting a patch for Script-Fu that makes it accept enums prefixed with GIMP-. Should be a trivial change. The next opportunity to make a change would be for 2.2 which might be another year or two down the road but one wouldn't expect such incompatibilities in a minor bump in version (2.0 to 2.2). Since we want 2.2 to be API compatible with 2.0, we couldn't do an incompatible change for 2.2. On the other hand 2.2 is scheduled for this summer, not in a year or two. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
At 04:06 PM 01/29/2004, you wrote: So the easiest solution would be to make script-fu accept the enums with or without prefix. That would be the easiest solution and maintains compatibility with existing scripts. The point is that it is already way too late to do any major incompatible change. Our API was frozen from the moment we did the first 2.0pre release. I realize that. I had no intention of suggesting a change to the API. Just a change to the enums/constants used by Script-Fu. However I don't see any problem in accepting a patch for Script-Fu that makes it accept enums prefixed with GIMP-. Should be a trivial change. Since it was my suggestion, I suppose that falls in my lap. :-) I'm fairly certain it is trivial. It is more a matter of ensuring that the additions to what is accepted match against what is shown in the DB Browser. If all internal enums/constants start with GIMP- then no problem. The only remaining question is whether the old (non GIMP- prefixed) enums for Script-Fu should be deprecated for later removal and how that should be indicated (or just documented). I will check the help documentation to see if there is any information about Script-Fu scripts that would need to be updated/changed. 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 [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
