The roadmap for GIMP was discussed shortly. We would like to get GIMP 2.4 out soon. The plan is to finish what has been started in the development branch. This should be doable over the summer.

When is expected string freeze for translators to happen?

Jakub

On 6/6/05, Sven Neumann wrote:

Hi,

Sven Neumann writes:

Rearranging the core menus is a matter of editing a couple of XML files.

I should probably add that this is primarily meant as a way to easily edit the menu structure with the goal of getting these changes accepted in the GIMP development tree. I don't like the idea of seeing forks of the menu structure since this will make documentation difficult to say the least. It will also break mnemonics. Mnemonics are defined in the menu labels and their translations and a lot of effort has gone into avoiding collisions. Moving menus around will finally make string changes necessary which is something that you cannot do with the GtkUiManager XML files.

The possibility to easily rearrange the menus is nice to have but should be used with care.

It seems to be wanted by enough of our users that we should give it some serious thought, though.

Rockwalrus

One thought, if the complexity is worth it: when the menus are rearranged, GIMP could also provide a way of calling up the standard organized menus on the fly, or even make a way for alternate menus to be selectable and customizable at runtime, persistence could be an option.

_-T

____________________

On Tuesday 07 June 2005 07:26, Sven Neumann wrote:

Leon Brooks writes:

I'd like to see "menu themes" so that a frustrated refugee from other graphics programs (not just PS) can load a theme and have menus arranged like their other system, but have not yet looked to see how hard that is.

Rearranging the core menus is a matter of editing a couple of XML files.

Excellent! I have RDP access to a W2k3 server with much software available, so I'll see about cobbling up some menus compatible with what I have to hand.

I think that rather than disturb the existing GIMP development structure for now, I'll offer the alternate layouts separately at least for a few months and see what eventuates.

How hard is it at the moment for a user to select alternate menu layouts on the fly?

Cheers; Leon

On Mon, 6 Jun 2005, Sven Neumann wrote:

Date: Mon, 06 Jun 2005 00:24:47 +0200 From: Sven Neumann
To: gimp-developer@lists.xcf.berkeley.edu Cc: gegl-developer@lists.xcf.berkeley.edu Subject: [Gimp-developer] The GUADEC meeting

Hi,

now that GUADEC is over and everyone's back home, you will probably want to know what has been happening related to GIMP at this year's GUADEC in Stuttgart. Let me try to give a short summary of the GIMP meeting we had on Monday.

The menu reorganisation effort was raised. It seems that Akkana's proposal is widely accepted.

I wasn't previously aware of this proposal (no mention of it in the wiki and I thought I was on the bug CC list but apparently not) but I eventually found a patch by Akkana which I assume is the one to which you are referring.
bug report on menu reorganistion:
http://bugzilla.gnome.org/show_bug.cgi?id=116145 Patch by Akkanna to get things started: http://bugzilla.gnome.org/attachment.cgi?id=46852&action=view

The proposed patch can be improved but it is a good start. If Akkana or someone else has time and motivation to continute to work on this, then the patch can be committed right away.

The patch is a substantial improvement, an excellent start by Akkanna.

It will be a big improvement to have things grouped by what they do rather than how they do it. I think it is worth mentioning though that Adobe Photoshop didn't even attempt this and instead they copped out and buried their scripts in a seperate Actions dialog, so it may be difficult to keep things managable as people want to add more and more extensions (but I still think the patch is a very good and necessary first step). http://wiki.gimp.org/gimp/GimpMenuReorganization

I was thinking fo doing something similar for the python plugins (and making sure to add ellipses where needed). However some of the python plugins duplicate existing functionality so putting two Clothify plugins beside each other would only confuse users. I see Akkanna tackled this by marking the Script-Fu unsharp as "Unsharp 2" but if people have idea on how to tackle this duplication of functionality I would be interested to hear it. (I must say when it comes to learning to port scripts to python I found it very helpful to have similar examples written in a different language) plugin written . One possible way to disambiguate similar plugins might be to give them different menu icons but expect you can probably come up with something better than that.

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

On Tuesday 07 June 2005 09:53, Alan Horkan wrote:

I was thinking fo doing something similar for the python plugins (and making sure to add ellipses where needed). However some of the python plugins duplicate existing functionality so putting two Clothify plugins beside each other would only confuse users. I see Akkanna tackled this by marking the Script-Fu unsharp as "Unsharp 2" but if people have idea on how to tackle this duplication of functionality I would be interested to hear it. (I must say when it comes to learning to port scripts to python I found it very helpful to have similar examples written in a different language) plugin written . One possible way to disambiguate similar plugins might be to give them different menu icons but expect you can probably come up with something better than that.

I always saidthat tehere should be some way to identificate a menu entry. Not only there will be up to four (C, script-fu, Python-fu, tiny-fu) equivalent entries on a row, as you point out - but I think one has the right to know how each menu entry got there.

Today it already happens with stuff like 'filter all layers', installed with Gimp-GAP - one can't know where it came from.

People suggested that an icon before menu entries would cause to much hassle to the UI - and I agree. I suggested them that right-clicking on a menu item would bring some information about it. (Like: the package where it came from, what language it is written in, and maybe even accept a new shortcut for that item, without having to enable "dynamic shortcuts")

Regards,

JS ->

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

Alan Horkan writes:

I was thinking fo doing something similar for the python plugins (and

It was my intention to include python-fu as well. I must have missed it because python-fu didn't get built in the tree I was using (it's there now). I need to make an updated patch anyway, to include placeholders, so I'll merge in the python scripts (there don't seem to be very many of them) at the same time.

Nobody's commented on any of the other questions I asked in the bug, like whether it would be a good idea to fold the short Glass Effects menu into Light Effects, or moving Enhance up to where it's just under Blur, or whether there's a reasonable place for Show Image Structure since it's now the only item in Utils. I'll go ahead and move Enhance since no one objected; maybe I'll try to come up with some place to stick Show Image Structure.

(The bug is http://bugzilla.gnome.org/show_bug.cgi?id=116145 if anyone wants to comment there or read the questions in more detail.)

making sure to add ellipses where needed). However some of the python plugins duplicate existing functionality so putting two Clothify plugins beside each other would only confuse users. I see Akkanna tackled this by marking the Script-Fu unsharp as "Unsharp 2" but if people have idea on how to tackle this duplication of functionality I would be interested to

I'd be interested too. I don't like "Unsharp Mask 2" but strings like "Unsharp Mask (script-fu)" are likely to make the menus too long. Anyone have a better idea?

Joao S. O. Bueno Calligaris writes:

People suggested that an icon before menu entries would cause to much hassle to the UI - and I agree.

Probably. It would be a nice idea but probably isn't worthwhile if it doesn't plug in easily to the current menu code.

I do like the idea of being able to find out where a particular menu item comes from.

I suggested them that right-clicking on a menu item would bring some information about it. (Like: the package where it came from, what language it is written in, and maybe even accept a new shortcut for that item, without having to enable "dynamic shortcuts")

The problem with that is that many people still use right-click to get the menus (you have to, if you want tear-offs, so I find I get in the habit of using right-click most of the time instead of left clicking in the menubar), and once I'm in a context menu which I brought up by right-click, I expect right-click to continue to work to invoke submenus and menu items. If that changed and suddenly right-click did something else, and probably dismissed the menu at the same time, it would take quite a while to relearn those habits (and would make gimp's context menus inconsistent with most other apps).

I could see using a modifier key, e.g. control-click on a menu item, or even mouse over a menu item and hit some key (f12 for help? ctrl-i for info?) Except of course then you couldn't rebind that key any more as a keyboard shortcut, so that's probably not a good idea either.

And neither a modifier-click nor a help key over the menu is very discoverable. Tooltips would be discoverable, but they'd get in the way as you explore the menu system.

...Akkana

On Tue, 7 Jun 2005, Joao S. O. Bueno Calligaris wrote:

Date: Tue, 7 Jun 2005 10:39:30 -0300 From: Joao S. O. Bueno Calligaris
To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting]

written . One possible way to disambiguate similar plugins might be to give them different menu icons but expect you can probably come up with something better than that.

I always saidthat tehere should be some way to identificate a menu entry. Not only there will be up to four (C, script-fu, Python-fu, tiny-fu) equivalent entries on a row, as you point out - but I think one has the right to know how each menu entry got there.

'kay, menu icons clearly aren't the best idea.

I suggested them that right-clicking on a menu item would bring some information about it. (Like: the package where it came from, what language it is written in, and maybe even accept a new shortcut for that item, without having to enable "dynamic shortcuts")

I really like the idea of providing information about menu items but not the proposed implementation. The way many other Gnome and GTK give the information applications do is to show a description of a menu item in the status bar. Perhaps the existing short description/summary/blurb in most plugins could potentially be repurposed for this, what do you think?

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

On Tue, 7 Jun 2005, Akkana Peck wrote:

Date: Tue, 7 Jun 2005 10:20:21 -0700 From: Akkana Peck
To: The GNU Image Manipulation Program
Subject: Re: Akkana Menu patch [was Re: [Gimp-developer] The GUADEC meeting]

Alan Horkan writes:

I was thinking fo doing something similar for the python plugins (and

It was my intention to include python-fu as well. I must have missed

Excellent. If you could add the ellipses (...) too I'd appreciate it.

Nobody's commented on any of the other questions I asked in the bug,

I'd like to get your changes in as it is so difficult to get everyone to agree and then start to make more changes as we can get some sense of what changes are uncontraversial and people are happy with.

like whether it would be a good idea to fold the short Glass Effects menu into Light Effects,

go for it

(it is probably worth mentioning though that Photoshop puts Lens under Distorts and now it the time to consider incorporating things from Gimpshop)

or moving Enhance up to where it's just under Blur, or whether there's a reasonable place for Show Image Structure since it's now the only item in Utils.

I thought it had been changed already but abbreviations like Utils and Decor should be avoided.

I'll go ahead and move Enhance since no one objected; maybe I'll try to come up with some place to stick Show Image Structure.

I'm really not sure, I think that might require a rethink of what categories are needed to accomodate third party plugins and scripts. (I'd be tempted to dumpt it beside Colour Cube analysis because I use both for similar puroposes but I know that isn't a good answer).

(The bug is http://bugzilla.gnome.org/show_bug.cgi?id=116145 if anyone wants to comment there or read the questions in more detail.)

I'd be interested too. I don't like "Unsharp Mask 2" but strings like "Unsharp Mask (script-fu)" are likely to make the menus too long. Anyone have a better idea?

I didn't want to mention it earlier but as you intend making another patch I should mention you used _U as the mnemonic for both Unsharps.

A lot of my opinions have been added to the Wiki page but it doesn't lend itself to discussion or otherwise sorting out which ideas people really want, I suppose I should try and catch people on IRC sometime this week and thrash out which other ideas people feel strongly about rather than cluttering the list with too many little details and slowly churning through them one by one.

Sincerely

Alan Horkan

Inkscape http://inkscape.org Abiword http://www.abisource.com

"Joao S. O. Bueno Calligaris" writes:

I always saidthat tehere should be some way to identificate a menu entry. Not only there will be up to four (C, script-fu, Python-fu, tiny-fu) equivalent entries on a row, as you point out -

but I think

one has the right to know how each menu entry got there.

Today it already happens with stuff like 'filter all layers', installed with Gimp-GAP - one can't know where it came from.

People suggested that an icon before menu entries would

cause to much

hassle to the UI - and I agree. I suggested them that

right-clicking

on a menu item would bring some information about it. (Like: the package where it came from, what language it is written in,

and maybe

even accept a new shortcut for that item, without having to enable "dynamic shortcuts")

Right-clicking menus is afaik not supported by GTK+ and it would also be very hard to discover. I'd say the Plug-In Browser should be rewritten, probably in the core, to become a Menu Browser. It should be possible to bind it to a function key that can be invoked with a menu-item focused (as you can do with F1 to get help). Such a menu browser would also help to locate menu entries and it could offer a way to change the keyboard shortcut also.

And of course, not everyone has a right mouse button... or do new Macs have more than one button?

On Thursday, June 9, 2005, 1:48:29, Phil Lello wrote:

And of course, not everyone has a right mouse button... or do new Macs have more than one button?

They don't (but they work just fine if you connect a normal USB mouse - which is what most Mac users I know do).

Alan Horkan wrote:

I really like the idea of providing information about menu items but not

the proposed implementation. The way many other Gnome and GTK give the information applications do is to show a description of a menu item in the status bar. Perhaps the existing short description/summary/blurb in most plugins could potentially be repurposed for this, what do you think?

Most users will invoke items from the menu and won't care what carries out the action (ie. plug-in, or script) so I don't feel the menus should provide any such information. What would be useful is for the Procedural Browser to include the menu path as is currently done in the plug-in browser. While working on Script-Fu/Tiny-Fu scripts I often use the browser to determine which PDB call I need to use for a given task. I sometimes want to execute that function from a menu so I can verify the function has the effect I am after. Its a real pain when I have to go searching through the menus to track down the menu equivalent of a PDB function for items I don't (or seldom) use.

To provide some indication as to the origin of a plug-in or script listed in one of the browsers without cluttering the browser window it could be done via a word (or two?) in brackets at the end of the line which indcates the type of the entry. After Temporary Procedure or GIMP Plug-in you could have (in brackets) Core, Perl, Python, Script-Fu, or Tiny-Fu (for example). For plug-ins written in C adding a word in brackets at the end could be skipped. It may only be useful for items registered by scripting plug-ins.

On Thu, 9 Jun 2005, Phil Lello wrote:

Date: Thu, 9 Jun 2005 00:48:29 +0100 From: Phil Lello
To: gimp-developer@lists.xcf.berkeley.edu Subject: RE: [Gimp-developer] Re: Akanna Menu patch

And of course, not everyone has a right mouse button... or do new Macs have more than one button?

Rather than picking on Apple for choosing a single button mouse (which I actually like for reasons not worth going into again) point is not all pen and tablet devices have a convenient equivalent to right click which I think you will agree is more relevant to the gimp.

- Alan

On Thu, 9 Jun 2005, Kevin Cozens wrote:

Date: Thu, 09 Jun 2005 17:57:50 -0400 From: Kevin Cozens
To: gimp-devel
Subject: Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting]

Alan Horkan wrote:

I really like the idea of providing information about menu items but not

the proposed implementation. The way many other Gnome and GTK give the information applications do is to show a description of a menu item in the status bar. Perhaps the existing short description/summary/blurb in most plugins could potentially be repurposed for this, what do you think?

Most users will invoke items from the menu and won't care what carries out the action (ie. plug-in, or script) so I don't feel the menus should provide any such information.

If all else fails trial and error is an adequate way to learn more about what the various scripts and plugins do.

What would be useful is for the Procedural Browser to include the menu path as is currently done in the plug-in browser.

This would be somewhat helpful but ..

While working on Script-Fu/Tiny-Fu scripts I often use the browser to determine which PDB call I need to use for a given task.

What I do sometimes is leave an image open and then in the Script-Fu Console to find it value I use
(gimp-image-list)
and then pass that to the functions I want to try out.

The proposed Logo/script browser[1] in bug 158980 might be able to make this process even easier and apply a function to a current image.

(I made a really awful attempt at this using the Python based PDB Browser and by passing dummy values to get plugins to pop up)

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

[1] Full Link to bug 158980 http://bugzilla.gnome.org/show_bug.cgi?id=158980

On 6/11/05, Sven Neumann wrote:

Sorry, but GIMP also doesn't know what language the procedure is written in. Such a framework would first have to be added and I don't see it as particularily useful.

It's a great solution for the real world problem of :

"Run the Foo plugin." "I don't have the Foo plugin."
"Oh crap, what package is it in?"

Rockwalrus

On 6/12/05, Sven Neumann wrote:

Nathan Summers writes:

Sorry, but GIMP also doesn't know what language the procedure is written in. Such a framework would first have to be added and I don't see it as particularily useful.

It's a great solution for the real world problem of :

"Run the Foo plugin." "I don't have the Foo plugin."
"Oh crap, what package is it in?"

I see that problem but the suggested solution doesn't help with it. What the user really wants to know is how to get that particular plug-in/script. Telling the user what language it is written in, is not going to solve that problem.

Given that in the Real World, the vast majority of the scripts people have installed came in the same package as the scripting language itself, this solves a major part of the problem. On the other hand, if we are adding a field-of-origin, it's trivial to make it specify not just language but a URL or somesuch for how to get it.

Rockwalrus