[haiku-development] Re: Yet another Task for GSoC: HUD
- From: Ryan Leavengood <leavengood@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 1 Mar 2012 12:12:35 -0500
On Thu, Mar 1, 2012 at 11:00 AM, Stephan Aßmus <superstippi@xxxxxx> wrote:
>
> Yes. I think fundamentally, there needs to be infratructure (an API) for
> applications to declare their available functions. And declaring a function
> should include declaring associated keywords and a short description.
> Perhaps even two levels of description, one usable as tool tip, the other a
> bit more verbose.
I suppose this is most likely an addition to BMenuItem, or would you
want something more flexible?
BMenuItem newItem = new BMenuItem(B_TRANSLATE("New"),
BMessage(MSG_NEW_DOCUMENT), 'N');
newItem->SetHelpText(B_TRANSLATE("Open a new document in a new window"));
Maybe with a second optional argument to SetHelpText which has a
longer description. And maybe a new constructor which takes these
could be added as well.
> Now, what we do with this declared information is separate from this API. It
> may be used to implement a global help system, it may be used to improve
> scripting, and of course the proposed menu search feature. The API should be
> written with as much possible features in mind, and then the menu search
> system should already make use of it, even though at first the only actual
> data source are the menu item names themselves.
Yes this all makes sense. Since it is possible to have actions which
are not in menu items we probably need more of a concept of a
BCommand, which would also be useful for undo/redo. Then BCommands
could be associated with BMenuItems and whatever else and the help
text would be in the BCommand. But that seems like a pretty extensive
API change for R1.
--
Regards,
Ryan
Other related posts:
