[haiku-development] Re: Yet another Task for GSoC: HUD

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 01 Mar 2012 17:05:30 +0100

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

Other related posts: