Am 01.03.2012 14:53, schrieb kirilla@xxxxxxxxxx:
1 mar 2012 kl. 12:12 skrev Stephan Aßmus: ...My very first mail on the subject was in reply to an idea for the implementation of the proposed changes to the menu system. So yes, the menu system can be changed. The implementation idea was to just iterate the menu items and list the matches.I meant the idea I shared more as a user experience thing and less of an implementation. "Matches" doesn't have to be literal, or limited to the domain of the menu items.
Yes, exactly. But my additional argument is that if the only data source are the menu item names, then the feature is not very useful. I would like the project proposal to anticipate that.
I am trying to tell you why that is utterly useless, unless more things are changed besides the menu system. So I am arguing to *at least* prepare these other changes as well, so that the UI change, even if it is implemented before updating apps, is at least *capable* of becoming more useful in the future. Once more and more apps make use of the new infrastructure that I am proposing.Yes, menu search is of limited usefulness without making apps more rich in metadata and having this available to the system. There's nothing about rich metadata, e.g. help system information, that can't be combined with the user experience that I proposed. One just needs to decide on format, location and ownership of this metadata, e.g. internal or external to the apps, or a combination of both. - internal data, hardcoded (e.g. shortcut keys, presently) - semi-internal data, dynamic (e.g. translated strings, presently) - external data, e.g. a file with app metadata suitable to multiple purposes - or a combination of static and dynamic, internal and external. Ideally the implementation would make the same information available both internally (to the app) and externally (to the system, other apps) so that we don't paint ourselves into a corner, and all options remain open for different ways to make cross-application features. E.g. a global HUD and a menu search function could share the same data sources, but for the HUD it would be vital for it to have access to the full set of domains (apps, data, what else?) and then limit oneself expressly to a certain scope, whereas a menu search function would have a scope to begin with.
Exactly. I am just saying that it really /needs/ these additional data sources to be useful. I wouldn't like an implementation that doesn't already take those into account, so that there is at least a motivation to actually update apps and provide the additional data, which of course requires the API infrastructure in the first place. And that should be part of the project.
Best regards, -Stephan