Re: Perl-Fu plug-ins in 1.1.21
On Mon, May 08, 2000 at 12:47:27AM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > The order of menus was determined by the order of installation. The code > in plug-in.c uses readdir(). On most systems this will give you the plug-ins > in the order the inodes were created. I doubt it. But the usual order in directorirs comes close indeed. This expalins why perl plug-ins were grouped together. > more or less unpredictable, I have checked in some code today that orders > the plug-ins and script-fu scripts alphabetically according to their > translated menu-entries. Very good! > I have however noticed that perl i18n is totally broken at the moment (at > least on my box) and I couldn't figure out why. I checked in a patch yesterday (or the day before) that should fix the ".gmo files not created properly" problem. > passed to menus_create_item...() correctly. Later I found out why this > does not work: gimp-perl sets the domain-path to "/usr/share/locale". > As the po build system in gimp-perl is definitely messed up since no > gmo files are build ever, I can not determine if this is intentional. I'll check (unfortunately, the drive with the sources just stopped working, so I couldn't check it). > I suggest that perl installs its message catalogs under the prefix > however (which is /usr/local/ here) and uses gimp_plugin_domain_add() > instead of gimp_plugin_domain_add_with_path(). Is it guarenteed that .mo files end up in "prefix"/share/locale/? configure does not export the path that gettext uses (so rather than trying to second-guess, I used the same prefix gimp-perl uses). However, if gimp_plugin_domain_add_with_path works as advertised(?), fixing the build process should suffice. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl-Fu plug-ins in 1.1.21
Hi, myself wrote: > I have however noticed that perl i18n is totally broken at the moment (at > least on my box) and I couldn't figure out why. This was broken before my > changes and I have double-checked that the gimp-perl text-domain gets > passed to menus_create_item...() correctly. Later I found out why this > does not work: gimp-perl sets the domain-path to "/usr/share/locale". > As the po build system in gimp-perl is definitely messed up since no > gmo files are build ever, I can not determine if this is intentional. > I suggest that perl installs its message catalogs under the prefix > however (which is /usr/local/ here) and uses gimp_plugin_domain_add() > instead of gimp_plugin_domain_add_with_path(). Actually running autogen.sh in the toplevel gimp source dir solved the problem Salut, Sven
Re: Perl-Fu plug-ins in 1.1.21
Hi, > For 1.2, the solution should be clear: find out why perl plug-ins get > specialcased (maybe because menus.c doesn't know about them but about the > c-plug-ins? or maybe because the i18n code handles them differently?) and > sort everything alphabetically (source language, e.g. english). The order of menus was determined by the order of installation. The code in plug-in.c uses readdir(). On most systems this will give you the plug-ins in the order the inodes were created. This means that the order of menus was more or less unpredictable, I have checked in some code today that orders the plug-ins and script-fu scripts alphabetically according to their translated menu-entries. I have however noticed that perl i18n is totally broken at the moment (at least on my box) and I couldn't figure out why. This was broken before my changes and I have double-checked that the gimp-perl text-domain gets passed to menus_create_item...() correctly. Later I found out why this does not work: gimp-perl sets the domain-path to "/usr/share/locale". As the po build system in gimp-perl is definitely messed up since no gmo files are build ever, I can not determine if this is intentional. I suggest that perl installs its message catalogs under the prefix however (which is /usr/local/ here) and uses gimp_plugin_domain_add() instead of gimp_plugin_domain_add_with_path(). Salut, Sven Salut, Sven
Re: Perl-Fu plug-ins in 1.1.21
On Fri, May 05, 2000 at 01:22:48PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > entries? Sort them according to their original name (easy) or according > to the translated one? I fear that the latter will be difficult and it > would lead to different menu orders depending on what language you > started gimp with. > > I'm undecided. What do you think ? For 1.2, the solution should be clear: find out why perl plug-ins get specialcased (maybe because menus.c doesn't know about them but about the c-plug-ins? or maybe because the i18n code handles them differently?) and sort everything alphabetically (source language, e.g. english). Sorting them alphabetically is not right, either, so maybe we should get 1.2 out and working instead of trying some nasty tricks to still not get it right. (== my opinion, if this was a poll ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl-Fu plug-ins in 1.1.21
On Wed, May 03, 2000 at 03:20:19PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote: > That's why I am surprised to get this problem: I double-checked that I > had no old files in the plug-ins directory before reporting this > strange bug. The only files that are in the plug-in-path came from a > fresh install of 1.1.21. I also re-did a "make" and "make install" in > the source tree to be sure that I was not dreaming. :-) Maybe you have an old gimp-perl installation? You could check the configure output for messages to that extend (gimp-perl _tries_ to chekc for old, incompatible installations). > > If you give me a log-in on your machine I could fix it ;) > > home. But if you want to come and say hello, I can give you my work > address and a roadmap of the area. ;-) Uh ;-> Cool, but I guess it might be a bit *too* far for a casual visit ;) (You could also send me the output of configure + make + make install) > > (that were reinstalled) registered below the existing plug-ins and the > > perl-plug-ins (which you haven't reinstalled) moved to the top. > > register again before the C plug-ins. This appears to be new, > although I do not know when this behavior was introduced because the Hmm.. I just recompiled my tree (cvs last night), nuked ~/.gimp, but I can't see the same behaviour. The scripts seem to be scattered around quite randomly in the menus. Sinc eI do not know wether gimp cares at all about menu-order (ot might be that app/menus.c does something), I shouldn't comment anyway ;) > > a seperate menu hierarchy hardly makes sense. > > The same arguments apply to Script-Fu as well, however there is still > a separate menu hierarchy for these scripts. But maybe a separate > menu hierarchy is not the best solution... This is a (IMnsHO) very nice conclusion ;) From a GUI POV, seperating similar functionality into different menus does not make sense. It only adds work for the user who needs to memorize that a given Filter (say, unsharpen-warp) is not in the Filters menu, but in the Script-Fu menu. It is also hard to explain to new users that "Add Dust" would be found in a "Perl" submenu and not in "Filters", especially since most people do not know what "Perl" is (or Script-Fu). > care too much about the Perl-Fu scripts and do not even test them. I > am sure that I am not the only one who is worried about the overall > consistency of the user interface, but I am surprised by the lack of > comments about Perl-Fu I got some comments to the extent of "perl-fu does not follow gimp-gui standards", but I was never able to find out what that means (i.e. what the gimp-gui standard is, and what must be changed to be more compliant). As for consistency, most perl-scripts use the Gimp::Fu module to create their dialog, which ensures overall consistency between 97% of all perl-scripts. It would also make it quite easy to fix any layout problems since the dialog code is in a central location. After 1.2 is released, that code will change a lot, to make it possible to add internionalized descriptions in an easier way and allow even more customization (people do not like to write their own dialog-code, it seems). > Where are the "many eyeballs" that ensure that "all bugs are shallow"? Oh, the situation has improved a lot. Quite a few gimp-developers do build perl now, and a few even test it. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl-Fu plug-ins in 1.1.21
Hi, Raphael wrote: > But I also noticed that something else has changed in the Perl-Fu > scripts: in the previous versions that I tried (under Solaris), these > scripts were always registered at the bottom of the menus, instead of > being mixed with the C plug-ins. Now it seems to be the contrary: the > Perl-Fu scripts are listed first in each menu, followed by the usual C > plug-ins. This is very distracting. > > Would it be possible to avoid this? I would prefer to have the > Perl-Fu scripts separated from the C plug-ins. Either by adding a > separator in the menus, by adding a little mark next to their names, > or by creating a separate Perl-Fu menu similar to the Script-Fu menu. I'm not sure that seperating the Perl scripts from the C plug-ins makes sense, but the menu order is definitely distracting. I have just done a complete new installation and did note the following: - perl scripts are always at top and appear in random order (well, most probably it's not random, but I can not figure out if there is some sort of order, it's definitely not alphabetic). - C plug-ins are sorted more or less alphabetic. This is however not because we sort them that way, but only because for most plug-ins the menu entries match the binary names quite good. This leads to some strange effects however. In Filters->Distorts for example "Video" appears before "Value Propagate" only because "video" is before "vpropagate" on disk. I guess that with another filesystem we might get totally different results. A possible solution would be to sort the plugin menus alphabetically. I'm not really looking forward to touch menus.c again, but there is already some code in there that reorders menu entries (moving submenus to the top for example), so it should be possible to hook that in there somewhere. So far, so good. But what do we want to do about translated menu entries? Sort them according to their original name (easy) or according to the translated one? I fear that the latter will be difficult and it would lead to different menu orders depending on what language you started gimp with. I'm undecided. What do you think ? Salut, Sven
Re: Perl-Fu plug-ins in 1.1.21
On Wed, 3 May 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> On Tue, May 02, 2000 at 08:15:44PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> > I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of
> > them abort with the following error displayed on the console:
> >
> > ** ERROR (recursed) **: could not find handler for message: 65536
> > aborting...
>
> This happens to any plug-in that doesn't get recompiled when a protocol
> bump occurs. Recompiling the perl plug-in would fix that.
Well, for some reason it didn't, that's why I reported the bug.
I extracted gimp-1.1.21.tar.gz in a new directory and built everything
from there. Then I removed everything from the previous installation
of the Gimp in ${prefix}/lib/gimp and ${prefix}/share/gimp and I did a
"make install".
That's why I am surprised to get this problem: I double-checked that I
had no old files in the plug-ins directory before reporting this
strange bug. The only files that are in the plug-in-path came from a
fresh install of 1.1.21. I also re-did a "make" and "make install" in
the source tree to be sure that I was not dreaming. :-)
> > Marc, I suppose that you are aware of this and that you can fix it?
>
> If you give me a log-in on your machine I could fix it ;)
I could give you a username and password, but that would not help you
because the firewall blocks everything. :-) Even I cannot log in from
home. But if you want to come and say hello, I can give you my work
address and a roadmap of the area. ;-)
Err... Seriously, do you or anybody on this list have any idea of
what could be causing this strange problem? Can anyone report a
successful or unsuccessful installation of 1.1.21 with Perl enabled?
My setup is:
Solaris 2.6
perl5.005_03
PDL-2.003
Parse-RecDescent-1.70
Gtk-Perl-0.6123
glib-1.2.7
gtk+-1.2.7
gimp-1.1.21
> > being mixed with the C plug-ins. Now it seems to be the contrary: the
> > Perl-Fu scripts are listed first in each menu, followed by the usual C
> > plug-ins. This is very distracting.
>
> Hmm... I wonder how the order in the menus is being worked out by the
> Gimp? Registration order? Alphabetical? Being able to control the sort
> order in some sensible way is highly desirable indeed, but will definitely
> not happen in 1.2 (IMHO it's very difficult).
>
> What happened in your case might have been that all the C-plug-ins
> (that were reinstalled) registered below the existing plug-ins and the
> perl-plug-ins (which you haven't reinstalled) moved to the top.
Unfortunately, this is not what happened. As I said, all the plug-ins
and scripts came from the new 1.1.21 package. I just checked a second
time by deleting my ~/.gimp-1.1/pluginrc and the Perl-Fu scripts
register again before the C plug-ins. This appears to be new,
although I do not know when this behavior was introduced because the
previous version (1.1.20) had another problem with the Perl-Fu scripts
and they crashed before registering.
> > a menu is mapped to a C or Perl plug-in. They behave slightly
> > differently (e.g. undo is not always supported, there is a delay of a
> > couple of seconds before the plug-in starts)
>
> This describe the behaviour of a subclass of all perl scripts. _Some_ C
> plug-ins behave the same, btw, as well.
>
> If you look at earlier discussions of this and related points you'll see that
> a seperate menu hierarchy hardly makes sense.
The same arguments apply to Script-Fu as well, however there is still
a separate menu hierarchy for these scripts. But maybe a separate
menu hierarchy is not the best solution...
> OTOH, I'd be all for some visible indication in the menus itself (although
> I am not 100% of wether that makes sense ;) It does not have any
> drawbacks, however).
I don't know if it makes sense, but I would like to have some kind of
indication before 1.2 is released. I was hoping that some people on
this list could reply with good suggestions...
> > for a vote or anything like that, but I would like to hear some
> > opinions... (no flames please)
>
> This has been discussed many times on this list already...
I know, but the final release of 1.2 is just around the corner now and
several things have changed since the last time these things were
discussed.
Also, I have the feeling that many people (not you, of course) do not
care too much about the Perl-Fu scripts and do not even test them. I
am sure that I am not the only one who is worried about the overall
consistency of the user interface, but I am surprised by the lack of
comments about Perl-Fu... Where are the "many eyeballs" that ensure
that "all bugs are shallow"?
-Raphael
Re: Perl-Fu plug-ins in 1.1.21
On Tue, May 02, 2000 at 08:15:44PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote: > I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of > them abort with the following error displayed on the console: > > ** ERROR (recursed) **: could not find handler for message: 65536 > aborting... This happens to any plug-in that doesn't get recompiled when a protocol bump occurs. Recompiling the perl plug-in would fix that. > Marc, I suppose that you are aware of this and that you can fix it? If you give me a log-in on your machine I could fix it ;) > being mixed with the C plug-ins. Now it seems to be the contrary: the > Perl-Fu scripts are listed first in each menu, followed by the usual C > plug-ins. This is very distracting. Hmm... I wonder how the order in the menus is being worked out by the Gimp? Registration order? Alphabetical? Being able to control the sort order in some sensible way is highly desirable indeed, but will definitely not happen in 1.2 (IMHO it's very difficult). What happened in your case might have been that all the C-plug-ins (that were reinstalled) registered below the existing plug-ins and the perl-plug-ins (which you haven't reinstalled) moved to the top. > a menu is mapped to a C or Perl plug-in. They behave slightly > differently (e.g. undo is not always supported, there is a delay of a > couple of seconds before the plug-in starts) This describe the behaviour of a subclass of all perl scripts. _Some_ C plug-ins behave the same, btw, as well. If you look at earlier discussions of this and related points you'll see that a seperate menu hierarchy hardly makes sense. OTOH, I'd be all for some visible indication in the menus itself (although I am not 100% of wether that makes sense ;) It does not have any drawbacks, however). > for a vote or anything like that, but I would like to hear some > opinions... (no flames please) This has been discussed many times on this list already... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl-Fu plug-ins in 1.1.21
>While we are on it, could someone please check that all Perl scripts >register menu names with trailing dots if, and only if, they open a >dialog. Not a Perl script, but the About... menu entry shouldn't have the ellipsis, according to most GUI standards, since in this case opening a dialog is an end itself, not an intermediate step before the operation is performed.
Re: Perl-Fu plug-ins in 1.1.21
Hi, > But I also noticed that something else has changed in the Perl-Fu > scripts: in the previous versions that I tried (under Solaris), these > scripts were always registered at the bottom of the menus, instead of > being mixed with the C plug-ins. Now it seems to be the contrary: the > Perl-Fu scripts are listed first in each menu, followed by the usual C > plug-ins. This is very distracting. > > Would it be possible to avoid this? I would prefer to have the > Perl-Fu scripts separated from the C plug-ins. Either by adding a > separator in the menus, by adding a little mark next to their names, > or by creating a separate Perl-Fu menu similar to the Script-Fu menu. While we are on it, could someone please check that all Perl scripts register menu names with trailing dots if, and only if, they open a dialog. Salut, Sven
Perl-Fu plug-ins in 1.1.21
I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of them abort with the following error displayed on the console: ** ERROR (recursed) **: could not find handler for message: 65536 aborting... And this message is displayed in a pop-up box: [/path/to/script]: the gimp is using a newer version of the plug-in protocol than this plug-in. Marc, I suppose that you are aware of this and that you can fix it? I suppose that this was a consequence of the recent changes in the wire protocol. Hi Mitch! ;-) But I also noticed that something else has changed in the Perl-Fu scripts: in the previous versions that I tried (under Solaris), these scripts were always registered at the bottom of the menus, instead of being mixed with the C plug-ins. Now it seems to be the contrary: the Perl-Fu scripts are listed first in each menu, followed by the usual C plug-ins. This is very distracting. Would it be possible to avoid this? I would prefer to have the Perl-Fu scripts separated from the C plug-ins. Either by adding a separator in the menus, by adding a little mark next to their names, or by creating a separate Perl-Fu menu similar to the Script-Fu menu. I am asking for this on the list because I expect that many developers have different opinions about the placement of Perl-Fu scripts (or Python-Fu). I think that the Perl-Fu scripts "feel" different from the C plug-ins and it would be nice to know beforehand if an entry in a menu is mapped to a C or Perl plug-in. They behave slightly differently (e.g. undo is not always supported, there is a delay of a couple of seconds before the plug-in starts) and their parameters dialog have a different layout compared to most C plug-ins. I suppose that some of these differences (e.g. the Gimp-Perl logo in the dialogs) were introduced on purpose to make these scripts stand out from the others, but then why should they be mixed? I'm not asking for a vote or anything like that, but I would like to hear some opinions... (no flames please) -Raphael
