On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName <lightningismyname@xxxxxxxxx> 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 _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
