On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName
<lightningismyn...@gmail.com> 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 :)

Gimp-developer mailing list

Reply via email to