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 common. > 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 > one. > > 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 anyone. >, 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. Rockwalrus _______________________________________________ Gimp-developer mailing list [email protected] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
