[haiku-development] Re: Yet another Task for GSoC: HUD
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 01 Mar 2012 12:12:08 +0100
Hi,
Am 01.03.2012 11:16, schrieb "Jürgen Wall":
In a perfect world we wouldn't discuss things anymore ;)
:-\ We are discussing how things should be, are we not? So I am just
referring to my imagination of a perfect world regarding the problem at
hand.
If every application worked this way, both the proposed "menu command
search" feature as well as built-in quick-help and even reliable
scripting would work across all applications. That would be just great.
The menu command search makes only sense in combination with a help system,
which will never gain priority right?
What have any priorities to do with it? Priorities are completely
irrelevant, it depends on someone being interested and motivated to do
the work anyway. This is independent of the proposal being included in
the list of GSoC ideas, but if it is, it should at least be thought
through, which is what I am trying to help with.
I am not saying that the "menu command search" can only be implemented
after rewriting most apps. But I am arguing that the feature is only
usefull once most apps are rewritten with it in mind.
How could one have that in mind without the means to test it?
A relies on B and B relies on A -> Deadlock!
Huh? Whoever implements the new API better also writes a test
application. A model after which to then change other apps. I see no
deadlock here.
And it doesn't
make sense to implement the UI without at least adding the API for
applications to declare their supported commands this way. Otherwise
it's pretty useless as it doesn't even provide a motivation to update
any apps.
Somehow I fail to make my point being understood...
This proposal describes an extension to the implementation of menus,
which in my opinion should not require any changes in applications or the API.
It's based on the idea that menus can be searched, like you do when you search
for a chapter in a pdf, even if it has a table of contents.
You are stating the obvious, but maybe you don't understand what I am
telling you. 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 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.
The integration of quick-help is desirable - sure, but may be done as a second
step.
I am just describing how implementing the new infrastructure will *also*
make a unified help system *possible*. Nowhere did I say it needs to be
implemented before or even at the same time.
Furthermore this feature makes the shortcuts of applications discoverable.
No it completely does not. Unless you consider typing in random words
that may or may not match the names of menu items (or the limited global
dictionary perhaps) more efficient than just reading the menus.
Best regards,
-Stephan
Other related posts:
