Re: Usability of menus (search, gegl ops, ...)

Cameron Gregory <public@xxxxxxxxx> · Tue, 10 Aug 2010 08:02:53 +1000



    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 <enter> .  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

      
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

    
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer