On Mon, Mar 27, 2000 at 05:26:41PM +0000, Ar't <[EMAIL PROTECTED]> wrote:
> xtra/perl-fu/bricks -> xtra/perl-fu/paterns/bricks
> Does this really have to be separated ?
No. In an ideal world, Logo scripts would be in Xtns/Logo/whatever, not
seperated by language-isms. Nobody should need to memoize wether a plug-in
is implemented in c, python or scheme to use it.
IMHO, the perl way (group plug-ins by function, rather than by implementation
language) is the right way.
Reorganization efforts in that direction will certainly clean up the
> script-fu is about scripts, that means files translated on-the-run for
> example perl, scheme, python, basic (yuck) and so on...
Sorry, but there simply is no distinction between scripts and plug-ins
(except for the script-fu case, which needs it's in-memory interpreter).
Sometime after 1.2, gimp-perl will compile pelr plug-ins before
> they work but they don't register (in menu):
Hmm, are you sure that you looked at the right places? The PDB Explorer
(and maybe the DB Browser) will tell you the menu location for all
> these scripts don't work at all:
Do you have any specifics? For exmaple, gimp-make-img-map is not a
gimp-plug-in, so it should not be used as one ;) Also, maybe you are
missing some modules that you had in earlier releases, but never did "rm
> these are not getting copied to $gimp_dir
Hm... Seth, are the versions in the cvs ok to get installed again? I am
not sure wether they should be installed or not.
> these don't work because of the lack of perl 5.0005
Ah yes, they shouldn't get installed indeed. It's on my TODO. Nevertheless,
do they register? They shouldn't, even when they are installed.
> Is "2x2 Blur"(perl) and "Blur"(C) not the same, if so then why double
> the same plugin (and keep your hands away from the C version)
They are not the same. However, the usefulness of "2x2 blur" is
questionable, so if people agree, it could be removed before 1.2.
> Lack of localization for scheme scripts
Indeed. Who is the current script-fu-hacker? How about a
(__ ("translate me, dumbhead")) syntax? I'll extend pxgettext to parse it
unless xgettext doesn't already do that. AFAIK, Sven is trying something,
but I am not sure wether his idea extends to the dialog texts and error
messages as well. In any case, the above solution (awdding i18n) is the
right thing, and unfortunately also the most work-intensive.
> Why colour brushes can be animated and grayscale can not ?
> (Telling me to stop using the colours is not the answer:).
Stop using colours ;-> BTW, you colour is a superset of grayscale, so the
only limitation is memory/disk space, which is a problem for animated brushes
Ideally (long after 1.3), the gimp will compress brushes and load large
brushes only on demand.
Thanks a lot for your comments!
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |