On 6/21/05, Carol Spears 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 /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

Nathan Summers writes:

On 6/21/05, Carol Spears wrote:

different levels of artificial intelligence; are there opinions of ways to rearrange the Xtns portion of the menu system?

Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know.

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,

File->Dialogs doesn't make a new image. I'm with Carol, most of the stuff in Xtns makes a new image, and should be grouped together accordingly.

for example. I know that the reason for the difference is that the Dialogs are implemented by the core, but why should I care?

You shouldn't.

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.

Right. If it were up to me, I'd split Xtns into two menus:

1. Development (or something similar): all the entries that have to do with mechanics of the languages (including C). It would look like:

Module Manager Plug-in Browser
Procedure Browser
Unit Editor
--------
Script-Fu Console...
Refresh Script-Fu
Start Script-Fu Server...
--------
Python-Fu Console...
Python-Fu Browser...

2. All the things that actually make new images. I don't know what to call this menu. Xtns or Misc or Generate (because it generates new images) or Create or New Images or ?? This would include all the submenus that are currently under Script-Fu, without any reference to the word "Script-Fu". Any Python scripts (or C plugins or anything else) that gets added would merge into these menus too.

There was some suggestion on IRC that not all the items in the Xtns->Script-Fu submenus create new images. I haven't gone through them yet to look for counterexamples; if there are some, maybe they should go somewhere else. Likewise, if there are items in Filters which create a new image rather than working on the current one (I don't know of any) then they should move here.

I'd lean toward making both these menus top-level menus in the toolbox window (so there would be four menus, not three), but that would cause space issues in verbose languages and large fonts, so alternately, I'd make Development a submenu (probably of File or File->Dialogs, not of Xtns/Generate/whatever, since the Development items do not create an image). It's more important that the New Image Creating stuff be easy to access than that Development is, because anyone developing scripts for gimp knows enough to use tear-offs, or set up key bindings, or somehow make it easier to get to the language tools.

Kevi? is certainly not the only one qualifed to change the locations the scripts register under. It's actually a trivial change for anyone.

I'd be happy to do the work if we reach consensus on what should be done.

Well, no one has experienced all of the "gimp experience." That's what good old fashioned kibitzing is for.

That's also what discussion on mailing lists, bugzilla and IRC are for. We still won't encompass the whole gimp experience, but at least by doing things in the open we'll have a chance of hearing from a range of people.

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.

I'd argue for that menu being a toplevel menu, so users are more likely to explore it. There are some cool scripts in there.

There's some reorganization that could usefully be done inside that menu as well. Buttons only has two items, Misc only has Sphere, Utils only has two items. How about moving those five items up to be directly visible in the Generate/Create menu?

So it would look like this:

Logos> Make Brush>
Patterns>
Web Page Themes>
-----------
Custom Gradient...
Font Map...
Round Button...
Simple Bevelled Button...
Sphere...

Thoughts?

...Akkana

On Wednesday 22 June 2005 11:36, Carol Spears wrote:

On Tue, Jun 21, 2005 at 05:38:36PM -0700, Akkana Peck wrote:

Nathan Summers writes:
Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know.

True, but...

the one situation that i found this condition of gimp to be effective for was to quickly figure out what was installed and what wasnt when helping people to debug scripts or install necessary scripts.

that usefulness is gone now.

Could a language-related mini-icon (16x16 or smaller) against each menu entry help?

Cheers; Leon

Hi,

Akkana Peck writes:

Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know.

Sorry to disagree with you here but "Script-Fu Console" does certainly belong to Script-Fu and it should be in a menu together with other Script-Fu related actions (such as "Start Server" and "Refresh Scripts"). I think each language binding should very well be allowed to have a submenu in the Xtns menu (or elsewhere) and put strictly language binding specific items there.

for example. I know that the reason for the difference is that the Dialogs are implemented by the core, but why should I care?

You shouldn't.

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.

The current Dialogs menu only contains dockables. Perhaps it needs a different name but I don't think we should add other dialogs there. That would be a major cause of confusion.

Right. If it were up to me, I'd split Xtns into two menus:

Good idea, but please move the two new menus out of the toolbox. I'd like the toolbox menu to go away completely. If we can get rid of Xtns, we are almost there.

Sven

Hi,

Leon Brooks writes:

Could a language-related mini-icon (16x16 or smaller) against each menu entry help?

The idea of the menu reorganization is to hide the language from the user because the user shouldn't have to care what language a filter is written in. Adding a language specific icon is contradicting this effort. There will always be the plug-in browser if someone wants to find out more about a plug-in / script. We should try to improve this browser instead of cluttering the menus with such icons.

Sven

On 6/22/05, Sven Neumann wrote:

Hi,

Leon Brooks writes:

Could a language-related mini-icon (16x16 or smaller) against each menu entry help?

The idea of the menu reorganization is to hide the language from the user because the user shouldn't have to care what language a filter is written in. Adding a language specific icon is contradicting this effort.

I can't speak for anyone else who is working on menu reorginization, but my personal goal is to restructure the menus so that it is easier to find things. Putting everything in the same categories regardless of implementation flows naturally from this desire, since you look for things by functionality, and because searching four menus in different locations is more cumbersome.

It is important not to lose the forest for the trees. One result of moving functionality out of implementation-specific menus into a common group is that information about implementation is less prominant, but it would be a serious mistake to conclude from that that this side effect is a goal.

There will always be the plug-in browser if someone wants to find out more about a plug-in / script.

I'm not going to say that there isn't a place for the plug-in browser, but this is not the place for it. There are very legitimate reasons that everyday users need to be aware of how a menu item is implemented. Some of these reasons are differences we can paper over or eliminate, such as the fact that "repeat" repeats the last non-core menu item ran, not the last run menu item. Some issues, such as knowing which bindings need to be installed to run your favorite script, cannot. There are several more examples I could list for both categories, but I will be brief, since you are intellegent enough to come up with them by yourself.

Since there are good reasons that users should be familiar with how each menu item is implemented, it needs to be information that is well presented. Having such information unobtrusively placed in the UI is the only way this can be achieved. It is simply not reasonable to bury this information in the plug-in browser, where the user has to wade through irrelevant and likely-to-be uninteresting information for every single menu entry.

For menu items that pop up dialogs, some ui element in the dialog would be a good location; perl-fu already does this. However, there are some plug-ins, like Gradient Map, that don't show a dialog, so unless you want to show a dialog like this:

--[Gradient Map]----------------- | Gradient Map is written in C. |
| Since it's a plug-in you can |
| use the repeat command to |
| run it again. |
|-------------------------------|
| [Ok] |
---------------------------------

the most reasonable place to stick that info is in an icon in the menu.

Futhermore, the fact that this particular suggestion -- icons by the menu items -- has been made by and most likely independantly thought up by several people should be enough in of itself to show that there is some merit to it.

We should try to improve this browser instead of cluttering the menus with such icons.

I don't think that adding such icons would be so bad, since after all, there are icons in other spots in the menus already. Even if doing so did make the menus a bit less attractive, the added useful information would more than balance it out. Our goal is to have a program that is useful and usable, not one that makes the centerfold of Awesome-Looking Programs Monthly. (Of course, it would be excellent if the editors of said magazine used GIMP to edit their content, and we don't want them to barf too much over looking at it in the meantime.)

Rockwalrus

Sven Neumann wrote:

Good idea, but please move the two new menus out of the toolbox. I'd like the toolbox menu to go away completely. If we can get rid of Xtns, we are almost there.

FWIW, I have two plugins that plonk themselves in the Xtns menu, so if it goes, they'll need somewhere to live. Both of them create dialogs that are not attached to any particular image.

* DBP (David's Batch Processor) - loads its own list of files, and processes them all.

* File Sequencer - allows the user to select any loaded image, and if the filename contains a number, save the current image and load the next (or previously) numbered image into the same window with a single button press.

On Tue, 21 Jun 2005, Akkana Peck wrote:

Date: Tue, 21 Jun 2005 17:38:36 -0700 From: Akkana Peck
To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] Integrated Scripting

Nathan Summers writes:

On 6/21/05, Carol Spears wrote:

different levels of artificial intelligence; are there opinions of ways to rearrange the Xtns portion of the menu system?

Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know.

Agreed.

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,

I'm irked that we have both Dialogs and Dialogues (I prefer generic English) and I would like to see it replaced with a term that doesn't require extra localisation work and yes I wouldn't be averse to slapping the slightly inappropriate "Windows" label on it (benefit of consistency with other software) but Palettes or even Docks which actualy describes the type of dialogs might be better.

File->Dialogs doesn't make a new image. I'm with Carol, most of the stuff in Xtns makes a new image, and should be grouped together accordingly.

Right. If it were up to me, I'd split Xtns into two menus:

1. Development (or something similar): all the entries that have to do with mechanics of the languages (including C). It would look like:

Mozilla uses a De_bug menu which is hidden in release builds and something similar (like Developement as you suggested) might be a good approach as these tools are mostly used for development and debugging of scripts.

Module Manager
Plug-in Browser
Procedure Browser
Unit Editor
--------
Script-Fu Console...
Refresh Script-Fu
Start Script-Fu Server...
--------
Python-Fu Console...
Python-Fu Browser...

I think the Procedure browsers have been unified and I think we are arleady down to just one Procedure browser.

Python-Fu does not require a Refresh. Does Tiny-Fu require manual refresh?

It is my understanding you set the Units and do not often need to change them. For a long time I have thought the Unit Editor would make an approrpriate section of the Preferences dialog.

2. All the things that actually make new images. I don't know what to call this menu. Xtns or Misc or Generate (because it generates

One of the minor complaints about Xtns is it being an abbreviation. This makes it harder to translate and difficult to understand not just for begninners but for anyone who may be using the GIMP in English but not have English as their first language. Space will always need to be considered for langauges with longer labels so there is little point trying to pick short words rather than picking the most approrpriate words.

new images) or Create or New Images or ?? This would include all the submenus that are currently under Script-Fu, without any reference to the word "Script-Fu". Any Python scripts (or C plugins or anything else) that gets added would merge into these menus too.

The logo browser suggested by Sven may provide an alternative way to clean things up.
http://bugzilla.gnome.org/show_bug.cgi?id=158980

A Dialog/Palette devoted entirely to Scripts (similar to what Adobe does to hide away their Actions) might work but hiding away the scripts like that isn't the best solution either.

There was some suggestion on IRC that not all the items in the Xtns->Script-Fu submenus create new images. I haven't gone through them yet to look for counterexamples; if there are some, maybe they should go somewhere else. Likewise, if there are items in Filters which create a new image rather than working on the current one (I don't know of any) then they should move here.

All of the pattern scripts could be moved to the current image and they would be more useful there, the following bugs attempt to address that: http://bugzilla.gnome.org/show_bug.cgi?id=145145 http://bugzilla.gnome.org/show_bug.cgi?id=145146

(I never got around to finishing Truchoid exactly as I wanted but I should be able to make a quick fix to complete moving all the scripts)

Logos>
Make Brush>
Patterns>

(as I tried to explain above only a little work is needed to finally moves these pattern out of the toolbox)

Web Page Themes>
-----------
Custom Gradient...
Font Map...
Round Button...
Simple Bevelled Button...
Sphere...

Thoughts?

More later probably ...

- Alan H.

Alan Horkan wrote:

Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know.

I don't have a problem with that either. But as someone pointed out, we need a place to put the menu entries that allow a user or developer to start a language specific server, start the language specific console mode, as well as refresh the list of scripts.

Right. If it were up to me, I'd split Xtns into two menus:

1. Development (or something similar): all the entries that have to do with mechanics of the languages (including C). It would look like:

Mozilla uses a De_bug menu which is hidden in release builds and something similar (like Developement as you suggested) might be a good approach as these tools are mostly used for development and debugging of scripts.

Using a menu only available in a development release may be ok for items only useful during true development. Putting menu items useful for developing/debugging scripts in a release only build would prevent would cause problems for those users who decide to write their own scripts. Just remember how some users when asking how to do something are told that GIMP doesn't have a menu item for what they want to do but they could create a script. Hiding the menu entries might be appropriate once we have implemented a macro recording ability sometime in the future.

Python-Fu does not require a Refresh. Does Tiny-Fu require manual refresh?

I am not sure what you mean by "require manual refresh". Script-Fu and Tiny-Fu both allow you to refresh the scripts. This only needs to be done if a new script is added and you want to use it right away without having to restart GIMP. Since Script-Fu and Tiny-Fu read all scripts in to memory, a refresh is needed if a script is altered.

2. All the things that actually make new images. I don't know what to call this menu. Xtns or Misc or Generate (because it generates

One of the minor complaints about Xtns is it being an abbreviation.

Another possibility might be to call it "Extras".

There was some suggestion on IRC that not all the items in the Xtns->Script-Fu submenus create new images. I haven't gone through them yet to look for counterexamples

I would need to review the list but the first one that comes to mind are the entries under "Make Brush".

Sven Neumann wrote:
> The idea of the menu reorganization is to hide the language from the

user because the user shouldn't have to care what language a filter is written in. Adding a language specific icon is contradicting this effort. There will always be the plug-in browser if someone wants to find out more about a plug-in / script. We should try to improve this browser instead of cluttering the menus with such icons.

A better browser would be useful. Most users won't (and shouldn't) care, or even need to know, whether a given menu item is a core function, a compiled plug-in, or a script.

On the other hand, it is nice to know that a given menu item is implemented via a script since a user who generally likes what that script does but wants to tweak it or see how it does what it does can easily track down the script file. Some mechanism to map menu entries to information about the entries (including implementation details such as the scripting language used) would be useful. By knowing something was a script it should make it easier to find the file to fix/modify/inspect it.

Hi,

Alan Horkan writes:

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,

I'm irked that we have both Dialogs and Dialogues

Sorry, would you mind to explain that? We only have a menu called Dialogs. Everything else is a translated menu entry.

and I would like to see it replaced with a term that doesn't require extra localisation work and yes I wouldn't be averse to slapping the slightly inappropriate "Windows" label on it (benefit of consistency with other software) but Palettes or even Docks which actualy describes the type of dialogs might be better.

Windows is usually used for a list of opened windows. So if we used that we would use a term that is consistently used in other applications for something completely different. And we should actually consider to add a Windows menu that lists all open GIMP windows.

Python-Fu Console...
Python-Fu Browser...

I think the Procedure browsers have been unified and I think we are arleady down to just one Procedure browser.

No, that hasn't happened yet.

Sven

On Thu, 23 Jun 2005, Sven Neumann wrote:

Date: Thu, 23 Jun 2005 00:14:55 +0200 From: Sven Neumann
To: Alan Horkan
Cc: The GNU Image Manipulation Program
Subject: Re: [Gimp-developer] Integrated Scripting

Hi,

Alan Horkan writes:

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,

I'm irked that we have both Dialogs and Dialogues

Sorry, would you mind to explain that? We only have a menu called Dialogs. Everything else is a translated menu entry.

It is ugly little localisation issue that I wish was not an issue at all. I should probably take it up with the en-GB translation team but if the menu item used a word that was the same in both American and British English my problem would go away.

Seeing the most recent version of the gimp with the word Dialogs localised to "Dialogues" looks really really weird and disturbing. I've always thought of "Dialogs" (American spelling) as the computer kind and "Dialogues" (British spelling) as the conversation kind. Software manufacturers so rarely bother to fully localise computer terminology I have grown to think of the American way of spelling things to refer to the computer terminology. I wish I could find other examples of using local spellings to have a subtely different meaning but off the top of my head I cannot think of any non computing related examples (analogue, dialogue, programme, favourites, etc) but maybe you can think of examples of German words that have ambiguous meanings depending on which German speaking country they come from. I hope that makes some sense.

and I would like to see it replaced with a term that doesn't require extra localisation work and yes I wouldn't be averse to slapping the slightly inappropriate "Windows" label on it (benefit of consistency with other software) but Palettes or even Docks which actualy describes the type of dialogs might be better.

Windows is usually used for a list of opened windows.

Photoshop is a bit weird I admit but the Windows menu is where it puts the menu items to control what Palettes are shown. The list of Open Windows is also included in there somewhere, and also an option to "save workspace" which will make sure window positions are remembered and a few other bits and peices (like maybe Close All, but I dont have convenient access to Photoshop so I'm really not sure what is in there).

So if we used that we would use a term that is consistently used in other applications for something completely different.

In theory the View menu would be the place to put menu items to control what windows/dialogs are shown or not shown but in this case it is not at all pratical. It may not be consistent in the general sense but graphics applications do what is consistent with Photoshop for better or worse. The menus are being reorganised anyway and this would be one less thing for them to complain about, so if ever there was an appropriate time for me to mention it I think this is it.

And we should actually consider to add a Windows menu that lists all open GIMP windows.

Listing all the open window list might help reduce the requests for a tabbed interface to the gimp many of which seem to be due to difficulties in managing lots of open windows.

Sincerely

Alan Horkan

Inkscape http://inkscape.org Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/

On 6/23/05, Alan Horkan wrote:

On Thu, 23 Jun 2005, Sven Neumann wrote:

Alan Horkan writes:

and I would like to see it replaced with a term that doesn't require extra localisation work and yes I wouldn't be averse to slapping the slightly inappropriate "Windows" label on it (benefit of consistency with other software) but Palettes or even Docks which actualy describes the type of dialogs might be better.

Windows is usually used for a list of opened windows.

Photoshop is a bit weird I admit but the Windows menu is where it puts the menu items to control what Palettes are shown. The list of Open Windows is also included in there somewhere, and also an option to "save workspace" which will make sure window positions are remembered and a few other bits and peices (like maybe Close All, but I dont have convenient access to Photoshop so I'm really not sure what is in there).

I've used plenty of applications where the Windows menu does double-duty, with the kinds of windows that can be opened, followed by a separator, followed by the current open windows. Come to think of it, I'd say the only apps that I've used that don't do it that way are ones were all the windows are the same kind, anyway.

So if we used that we would use a term that is consistently used in other applications for something completely different.

In theory the View menu would be the place to put menu items to control what windows/dialogs are shown or not shown but in this case it is not at all pratical.

At least to me, the View menu is for stuff that affects this particular view of this particular image, not dialogs and windows unrelated to it.

And we should actually consider to add a Windows menu that lists all open GIMP windows.

Listing all the open window list might help reduce the requests for a tabbed interface to the gimp many of which seem to be due to difficulties in managing lots of open windows.

That would be a nice feature to have, but I don't think it would be a complete substitution for tabs.

Rockwalrus