[haiku-development] Re: Yet another Task for GSoC: HUD
- From: "x-otic@xxxxxxx" <x-otic@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 27 Feb 2012 22:21:44 +0100
[...]
Ignoring any implementation details for the moment... This feature
makes no sense, if it requires the user to memorize the names of menu
items. *If* that were the case, it would be much quicker to memorize
the keyboard shortcut instead.
On the other hand, if this feature is about finding and discovering
features burried in menus (nice!), then it *must* be based on
something more than just menu item names. For a given search string,
the user should be presented with a list of the menu items that *may*
be what the user means. Preferably sorted by relevance, however this
is obtained.
So this feature could only work, if there is a lot more information
about a menu item declared programmatically, then just the name of the
item. At the moment, we don't even have tool tips for menu items.
*All* Haiku applications would have to be changed to declare this
additional context information for each and every menu item. And of
course in all available languages.
This feature provably makes absolutely no sense at all, if it were
just based on menu item names with some scripting to extract them from
the running application.
Ok, I agree to some extend. If one wants to find something like
'settings' , 'properties' or 'options' of an application in the simple
scenario one would have to type it in exactly,
however there could also be sets of related words, such that by typing
'settings' for example the search would come up with match of 'options'.
And, those sets won't have to application specific in most cases since
common wording is used mostly, right?
That means a global database containing sets of words with similar
meaning could drive this search well.
Regards,
Juergen
Other related posts:
