On 6/21/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> now that marc and sven have had their fun and we have all been allowed
> an example of how the perlized obfiscuates script-foneys with equal yet
> different levels of artificial intelligence; are there opinions of ways
> to rearrange the Xtns portion of the menu system?
> questions i have are these:
> what of the history of Xtns?
> it seems to be steeped in mystery and mis-use
Originally, there was a rule that if you wrote a load/save plug-in,
you added it to the list of loading/saving file types. Otherwise, a
plug-in was supposed to be added to the <Image>/Filters menu.
Extensions were to be added to the Xtns menu.
There was then the problem of what to do with plug-ins that don't take
an image, and therefore aren't very meaningful in the Filters menu.
Following the strict segregation rule of the time, Xtns seemed like
the natural place to put them.
Since then, people started putting plug-ins into the menu structure
willy-nilly, comingled with the core-implemented menu items, and
extensions have gone from being cool to being a last resort if you
can't implement the required functionality with the regular plug-in
mechanism. So what we are left with is the Xtns menu being the junk
drawer of miscellaneous stuff, the only real thing the items having in
common being that they are implemented with either plug-ins or
extensions. Actually, come to think of it, I seem to recall that the
core puts a menu item there as well, so we might not even have that in
> people rearranging the menus now do not seem to see that Xtns
> makes its own image and do not need to start with an image; even
> though the logic is very clear to some.
The thing is that there are plenty of exceptions to that rule.
File|Dialogs being a big source of stuff that doesn't need an image,
for example. I know that the reason for the difference is that the
Dialogs are implemented by the core, but why should I care?
> is there a sane way to include a script from each of the languages?
> examples: font-mapping, yinyang drawing; all the scripts have
> some of the scripting languages have an example that shows how to
> use the script; however the result of using it is ugly.
A unified script browser would be nice. If we had heard about the
Summer of Very Short Coding-related Deadlines sooner, we might have
been able to make it a bounty.
> include a menu entry for each of the gimp script powertools:
> the browsers
> the consoles
> the servers
I see little reason why these shouldn't be a subcategory of the other
dialogs. The name "Development" was suggested.
> potentially helpful non-gimp urls
That opens another can of worms, but to be brief, I like the idea of
having such urls either being redirects from the gimp website, or
dynamically updated every gimp startup.
> i personally would not mind keeping Kevi1 busy with changes to Tiny-fu
> for a while
Kevi? is certainly not the only one qualifed to change the locations
the scripts register under. It's actually a trivial change for
>, however, i am uncomfortable with the limited view i have
> had of the menu reorganization. my completely unresearched opinion was
> formed while seeing that it is being handled by people who have not
> actually experienced the whole gimp eh, experience. i also would be one
> of these people.
Well, no one has experienced all of the "gimp experience." That's
what good old fashioned kibitzing is for.
> i can at least see that by the time i started to use
> gimp, everything that appeared in Xtns were plug-ins that did not need
> an image to start with.
Not technically true, as script-fu scripts are implemented through an
extension, not a plug-in, but this only reinforces the point that no
one knows/cares about the distinction.
> fixing the problem with different types of
> scripts that do the same job in Xtns where it is much more of a problem
> will help everyone with the Image menu which has a few instances of this
> but not as many.
My suggestion is that Xtns menu items that create images should be
called something like File|New Generated Image and that the rest
should be merged with the other dialogs, ether as File|Dialogs or as a
new toplevel Dialogs menu item.
Gimp-developer mailing list