Hi all,

On 09.08.2010 22:51, LightningIsMyName wrote:

0. How do we want the search to work? A user can bring a search dialog up? Will the search be based on a string? A tree?

Just a quick and cheap thought:
if you're talking about search, that means i'm already using the keyboard to type in what i want to do, and then we're only one step away from a command line within GIMP.

Ubiquity is probably the best-designed example of such a command line, for firefox: http://mozillalabs.com/ubiquity/
http://jonoscript.wordpress.com/2010/01/20/retrospective-what-we-learned-from-ubiquity/

regards, yahvuu

G'Day,
I've been thinking a bit about this recently as I can never remember where anything is, and
writing script-fu's generally means I have a linear understanding of what is available.

How to access it: From some menus, I don't feel strongly about these. Help -> Menu Browser .. blah.
Anyway, the way I would use it is a shortcut. Ctrl-F would be the most logical choice.
Once a "tool wheel" is introduced (like in games), there would be a case to have it included there.

How does it look: text box at the top, results underneath. It's a popup that appears near where the cursor was when it was created. (be nice if it was a "light" popup, but anyway).

The results should just search the name of the menu. See options. It should do a case insensitive search like pdb (as the user types), including the regex.

The first item should be selected ready to go. Hit enter to select the item

So an example use for me recently would be, I'm looking for the sparkle plugin.
Ctrl-F spark . Hitting enter would close the window and call the menu.

By default each line would just contain the name of the menu: ie "Sparkle". But I think it reasonable to add an option to show where the item is: eg Sparkle (Filters -> Light and Shadow). By default the actual PDB names would not be searchable (eg plugin-sparkle), but no doubt that would be a good option, but only if the item appears in a menu.

There is no need to get complicated with tagging, and trees, and sub categories. I believe a basic implementation will show that it's power will be in the simplicity.

So what about gegl ops. My feeling is that it's a menu search, so it wouldn't be included by default. However a simple option to add this into the search would be reasonable.

Options: X Show Menu location
X Dev: Include GEGL operations
X Dev: Include PDB (internal) names

thanks for bringing this up, it's been playing on my mind recently...

Cameron

On 08/10/2010 06:51 AM, LightningIsMyName wrote:

Hello,

I recently re-read all the GSoC suggestions for 2010, and I found this interesting one about making the menus searchable: https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility

As far as I know, menus are searchable and the best example is the keyboard shortcuts dialog which has a searchbox to find the GIMP action you'd like to use. So I asked on #gimp and I was told there was a discussion on IRC about finding a more usable replacement to the plugin browser.

So, to get a formal record of this discussion, I'm starting it on the mailing list again.

Here are points which should be considered:

0. How do we want the search to work? A user can bring a search dialog up? Will the search be based on a string? A tree?

1. GEGL ops should really be integrated in the GIPM menus. As someone said, it's like the old script-fu menu - it was wrong. We don't have to force the user to remember what's a GEGL op (which will be accessed using the GEGL tool) and what's a regular plugin/script. It's a bit offtopic, but we should find a way to implement gegl plugins with a custom GUI, and register them like regular plugins in the menus. Having a search that will once point to a plugin and once activate the gegl tool, is a very bad idea...

2. We need to define a "usable" plugin browser. One of the features I'm missing the most, is a preview image. Plugins should have an option to register a preview image of their effect (probably by having the image's binary data embedded in them). This also relates to the feature request of having a logo script browser...

3. Will plugins also have a category (in addition to a menu location)? How should we organize the plugins? On one hand, it's probably a bad idea to continue having plugin authors choose their own category (or as it is now - a menu location). Since then you might find yourself with dozens of categories (like "my-site" "his-site") and typos ("artisti" and "artistic") or redefinitions ("art" vs. "artistic") may create more categories.
It's a fact - a bloated category list is good for nothing... So, should we limit the categories for plugins?

4. Another option, instead of categories and sub-categories, is tagging - like the brushes work in 2.7 (unlike categories - there are no sub-levels, and each plugin can be in many places)

Menus in GIMP should become more useful and things should become easier to find. But how? Please share your thoughts

~LightningIsMyName

On 9 August 2010 23:42, yahvuu wrote:

Hi all,

On 09.08.2010 22:51, LightningIsMyName wrote:

0. How do we want the search to work? A user can bring a search dialog up? Will the search be based on a string? A tree?

Just a quick and cheap thought:
if you're talking about search, that means i'm already using the keyboard to type in what i want to do, and then we're only one step away from a command line within GIMP.

What do you call the existing scheme and python interpreters in GIMP? I'd say that we already have this, and have had it for years.

On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName wrote:

Hello,

I recently re-read all the GSoC suggestions for 2010, and I found this interesting one about making the menus searchable: https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility

As far as I know, menus are searchable and the best example is the keyboard shortcuts dialog which has a searchbox to find the GIMP action you'd like to use.

However, that action is not immediately activateable. What I personally envision is something like the completion dialog that you can find in GTKTreeViews (for example, typing something in when the file list in a file selection dialog is focused, offers you a choice of the possible items. And upon selection from that sub-list, the file is immediately chosen.)

So I asked on #gimp and I was told there was a discussion on IRC about

finding a more usable replacement to the plugin browser.

The reason I made the description above is that the plugin browser is very limited.. you cannot activate non-plugin menu items (for example, I'd like to be able to access 'scale image' and 'scale layer' via a search -- I don't use them enough to warrant keyboard shortcuts, but enough that some acceleration is warranted. The same thing goes for virtually all GIMP-GAP operations).

So, to get a formal record of this discussion, I'm starting it on the mailing list again.

Here are points which should be considered:

0. How do we want the search to work? A user can bring a search dialog up? Will the search be based on a string? A tree?

one or more strings, per your Tags suggestion.

1. GEGL ops should really be integrated in the GIPM menus. As

What's a GIPM ? :D

someone said,
it's like the old script-fu menu - it was wrong. We don't have to force the user to remember what's a GEGL op (which will be accessed using the GEGL tool) and what's a regular plugin/script. It's a bit offtopic, but we should find a way to implement gegl plugins with a custom GUI, and register them like regular plugins in the menus. Having a search that will once point to a plugin and once activate the gegl tool, is a very bad idea...

Though we need to consider, that a GEGL op can do much more than simply be applied to the image once, destructively. If we make GEGL ops available in the menus, we should aim to do so in a way which does not trap us in a corner if, for example, we want to in the future be able to add that op into the image as a non-destructive effect on the current layer/layer group.

2. We need to define a "usable" plugin browser. One of the features I'm missing the most, is a preview image. Plugins should have an option to register a preview image of their effect (probably by having the image's binary data embedded in them). This also relates to the feature

I agree with you, but believe that we need to be more definite than that: previews should show clearly the before and after. I favor GMIC's horizontally split preview style for this -- it avoids wasting space, and instead of tiling two complete images next to each other, you get to see half of the image as it would be if it were filtered. In some cases, the vertically split style may be more appropriate.

request of

having a logo script browser...

Well, if we did what you outline here, how would Script-Fu scripts handle the necessary embedding of binary data (I don't mean to imply that they couldn't, just that I do not know exactly how well they can handle this kind of binary string literal).

4. Another option, instead of categories and sub-categories, is tagging - like the brushes work in 2.7 (unlike categories - there are no sub-levels, and each plugin can be in many places)

The current api allows this, minus the 'no sublevels' criteria, since a procedure can register in multiple menu paths.

I like the tagging concept, especially if it turns out to be a cheap solution to menu editing (If I could make my own tag, tag all the stuff I use most with it, and assign a shortcut to bring up that menu, that would really help my efficiency... Or, if I could remove the 'FILE' tag from the 'Print' menu item, I would no longer have to contend with a menu item that I never ever use. Note that if we could untag, we need a virtual 'tag' that items without a tag could belong to.. '-' or '!' possibly.)

I think we should tag, and predefine a tag set that should be adequate for most existing plugins. User tagging is important because plugin authors may not always be available or be willing to add this information. [this sort of ties into the 'Get Hot New Stuff' proposition -- it would be nice to be able to distribute the task of correct plugin tagging across users via a web interface)

Hope I've given you something to think about :)

David

On 08/09/2010 10:51 PM, LightningIsMyName wrote:

Hello,

I recently re-read all the GSoC suggestions for 2010, and I found this interesting one about making the menus searchable: https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility

0. How do we want the search to work? A user can bring a search dialog up? Will the search be based on a string? A tree?

No dialogs please.

What about a search field to the right in the menubar, accesible through a keyboard shortcut, like Firefox' Ctrl+K?

I imagine it to work like this: The user can type a string, and it will be matched against all texts associated with a filter/operation/whatever. The title, the description, the short summary etc. Typing "Dogde" should match with "Dodge". As you type, you get a list (not tree) of hits. Each hit has a preview with the effect on the image if applied. 'down, down, return' activates the second matched item, like it works in all similar UIs.

2. We need to define a "usable" plugin browser. One of the features I'm missing the most, is a preview image. Plugins should have an option to register a preview image of their effect (probably by having the image's binary data embedded in them). This also relates to the feature request of having a logo script browser...

I don't think registering a fixed preview image is good enough, it should be a preview of the effect if applied to the current image.

3. Will plugins also have a category (in addition to a menu location)? How should we organize the plugins?

With a good search mechanism, organizing plug-ins becomes less important, right? It should be possible to have descriptions good enough to avoid us from having additional tags.

Regards, Martin

On Tue, Aug 10, 2010 at 5:58 PM, LightningIsMyName wrote:

Hello,

On Tue, Aug 10, 2010 at 9:27 AM, Martin Nordholts wrote:

2. We need to define a "usable" plugin browser. One of the features I'm missing the most, is a preview image. Plugins should have an option to register a preview image of their effect (probably by having the image's binary data embedded in them). This also relates to the feature request of having a logo script browser...

I don't think registering a fixed preview image is good enough, it

Believe me, I really want a dynamic preview on the current image :-) But, it's not practical as some plugins take way too long to operate - trying to create a preview on the current image might take way too long to be any good.

Create the previews in an idle handler (ie. let the user select the operation even when the preview is not rendered, and cancel any pending preview rendering when a selection is made) We could combine this with the stored previews idea: show the stored preview with an overlay that indicates rendering of the preview for the current image is in progress...

On Tue, Aug 10, 2010 at 3:31 AM, David Gowers wrote:

On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName wrote:

Hello,

I recently re-read all the GSoC suggestions for 2010, and I found this interesting one about making the menus searchable: https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility

The reason I made the description above is that the plugin browser is very limited.. you cannot activate non-plugin menu items (for example, I'd like to be able to access 'scale image' and 'scale layer' via a search -- I don't use them enough to warrant keyboard shortcuts, but enough that some acceleration is warranted. The same thing goes for virtually all GIMP-GAP operations).

Sorry for my bad phrasing of the question - let me rephrase it: what is left other than exposing the searchbox from there?

Supporting '*' wildcards would be helpful IMO, but I agree that the shortcuts search is pretty adequate for this, when connected to activating the chosen action.

The searchbox there allows to find non-plugin actions, and these are very neatly organized under several categories. When you search, the categories are already expanded so you can see all the results, organized, right away.

That aspect is certainly good.

What I suggest, it is possible to embed binary data in script-fu scripts, but it's not easy/fun/simple. What I suggest is that as a part of the refactoring process of the plugin system, we will allow procedures to register a "sample" procedure. This procedure will be called once to generate a preview image. But this procedure is probably a bad idea (since generating the preview will take time, and this can be long...)
The other option is to ship example images with script-fu scripts and to allow them to return a pointer to that image for their preview. This sounds more reasonable to me.

Yes. However IMO, if we do that, we should not stop at previews for script-fu. We should provide a directory for general storage of these previews for any plugins. That way, it is much easier for ordinary users to provide improved previews for their most used plugins.

One of the things we should remember is that we should still have some sort of seperation between the plugin/script browser and between the general procedure browser. Because if we want things like preview for every action, it would be rather useless to have previews for internal operations such as "raise layer".

Certainly; there are actually four classes of actions: 1. actions owned by plugins, which have a menu item 2. actions owned by the GIMP core, which have a menu item (eg 'Raise layer') 3. actions owned by the GIMP core, which don't have a menu item (eg. 'Increase Aspect')
Mostly we will want to search the union of 1 and 2, IMO. And sometimes, we will want to search 3 (eg. I would use this for tweaking the color picker radius, setting the brush scale to default (=1.0))
. That is possible without any need to change current code.

I would like to point out anyway, that the PDB browser and the current keyboard shortcut dialog search, search different things... PDB browser searches PDB entries, KB shortcut dialog search searches action internal names+ user-visible names. It's definitely important to make that distinction apparent to the user, so that they don't expect to see PDB entries popping up in the action search box which is the subject of current discussion.

David

On Tue, 10 Aug 2010 08:27:59 +0200 Martin Nordholts wrote:

I don't think registering a fixed preview image is good enough, it should be a preview of the effect if applied to the current image.

Just my 2c. The problem with a preview of the current image is that it is not "controlled" and so won't necessarily show off the effect. Imagine a gaussian blur (as a simple example). If the current image is a 200px x 200px line drawing then the default settings of a blur (5px IIRC) will produce a noticeable effect in the preview. If the image being edited is a 35MPix digital photo, then it won't be obvious at all what the effect is doing in the preview. Rather than apply the default settings of the effect to the current image, why not allow the author to create the demonstration image (which will show off "real" use of the effect), but forcing it to be based on a specific image (Wilber springs to mind). That way it's using a known base image but can be tweaked to provide maximum visual effect for the preview?

Jon

On Tue, Aug 10, 2010 at 11:02 AM, Jon Senior wrote:

On Tue, 10 Aug 2010 08:27:59 +0200 Martin Nordholts wrote:

I don't think registering a fixed preview image is good enough, it should be a preview of the effect if applied to the current image.

..

to create the demonstration image (which will show off "real" use of the effect), but forcing it to be based on a specific image (Wilber springs to mind). That way it's using a known base image but can be tweaked to provide maximum visual effect for the preview?

This is how I would see something like this added for GEGL operations:

The desired end result would be to have a directory where previews of the results of gegl-operations can be found. Probably just pngs with the same name as the op it is a preview for. During the build of operations that come with GEGL a small set of illustrative images would be provided. By default if no extra work is done in the operation the default image will be used as input with default parameters. If this does not provide a good preview of the operation the op can add a string to GeglOperationClass containing the XML needed to apply the effect well to one (or more) of the sample images. These images would also be used in the GEGL documentation http://gegl.org/operations.html

On 10.08.2010 00:16, Jon Nordby wrote:

On 9 August 2010 23:42, yahvuu wrote:

Just a quick and cheap thought:
if you're talking about search, that means i'm already using the keyboard to type in what i want to do, and then we're only one step away from a command line within GIMP.

What do you call the existing scheme and python interpreters in GIMP? I'd say that we already have this, and have had it for years.

What's makes ubiquity so interesting, is that it is based on natural language (localized!), with a focus on ease of learning and reduced amount of typing. That's a different beast from a python shell.

I think it explores some interesting ideas which might also be applicable for GIMP, so here's a better link to showcase how it works: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_Tutorial

regards, yahvuu

On 08/10/2010 10:28 AM, LightningIsMyName wrote:

On Tue, Aug 10, 2010 at 9:27 AM, Martin Nordholts wrote:

2. We need to define a "usable" plugin browser. One of the features I'm missing the most, is a preview image. Plugins should have an option to register a preview image of their effect (probably by having the image's binary data embedded in them). This also relates to the feature request of having a logo script browser...

I don't think registering a fixed preview image is good enough, it

Believe me, I really want a dynamic preview on the current image :-) But, it's not practical as some plugins take way too long to operate - trying to create a preview on the current image might take way too long to be any good.

Just because some plug-ins are too slow for live preview doesn't mean we shouldn't have it for simpler plug-ins. Besides, we can have it for slow plug-ins as well, we just do the preview calculations asyncronously. And the previews will be small, so it won't take that much time even on slow plug-ins.

/ Martin

On 08/10/2010 11:57 AM, David Gowers wrote:

Create the previews in an idle handler

Just some nit-picking:
If you mean an idle handler in the event loop, that's a bad idea. We should do image processing in a separate thread to keep the UI responsive at all times. You could argue that if we always do image processing in small chunks, it won't be a problem, but that prevents us from more freely tweaking the chunk size. The bigger chunks we do at a time, the better we can use the CPU and memory caches.

IMO the current use of the main loop for image processing in GIMP needs to stop. The migration to GEGL will be a good time to fix it.

/ Martin

On Tuesday, August 10, 2010, 19:32:19, Martin Nordholts wrote:

Just because some plug-ins are too slow for live preview doesn't mean we shouldn't have it for simpler plug-ins. Besides, we can have it for slow plug-ins as well, we just do the preview calculations asyncronously. And the previews will be small, so it won't take that much time even on slow plug-ins.

I really like the way Paint Shop Pro does plug-in previews: by default, they appear in the plugin settings window (which actually has two previews side-by-side - current image, and processed image), but there's also a "Preview in image window" checkbox next to the preview, which will show the current settings on the image itself.

Also, when the preview takes too long to compute, a progress bar pops up with a Cancel button (I think this happens if the calculation is taking longer than 2 seconds). If you do a preview in the image window, and then apply the effect without changing anything, the effect isn't recalculated, but is used as-is.

Another thing that I like in PSP's plugin preview is that when you drag the preview around, it will never start recalculating the effect unless you release the mouse button - I hate it how GIMP will periodically try to update the preview while dragging it, which always causes me to end up somewhere I didn't want, and will also usually get the preview stuck in dragging mode even after I released the mouse pointer. Not updating the preview while the mouse button is held has another benefit for me: I can easily compare the before/after effect by simply tapping my mouse button. This is invaluable when cleaning scanned images, and I need to find a balance between smoothing the image too much and leaving behind too much moire.