Re: "What's this"

[Sasha_Vasko osca state mo us]

> >Seems likely that's not really an issue the protocol would need to
> >address - there would be some way to say "enter whatsthis mode" and
> >the window manager or panel or whatever could provide a button that
> >did that.
>
> How about this:
>
> When the help button is pressed, the help client (could be the WM or a
> panel applet) grabs the pointer and installs a ? cursor. When the user
> clicks on an item, the help client sends a client message to the clicked
> window and releases the pointer. Clients that don't understand the
> message will ignore it; clients that understand it can display help.

Clients should not be bothered with displaying help, unless you want to
bloat all of them with basically identical help rendering code. Much
cleaner
approach would be for single help app. It would query client about context
of
the mouse click ( basically send it message like: <subwindow_id,pointer_
x,pointer_y>)
on which client should respond with meaningfull text data identifying what
help
should be displayed - something like <application_class,topic,subtopic>.
help app then goes and at all known to it locations for this particular
information.
In case client does not support/respond to thins protocol - then help app
simply
falls back to using res_name, res_class from client's hints, and goes
looking
for the man page for this client.
X selections would be a good way to implement such a protocol.
Compliant clients should acqure ownership of the selection on its top level
window
something like _NET_HELP. help app then sends them request, passing
parameters along
in its target property _NET_HELP_REQUEST, created on its own window. And
client
should respond to it, by placing click context description info into this
target
property.
If client is not an owner of selection _NET_HELP or if it does not respond
within
reasonable timeout - help app goes on and displays help based on clients
Class hints.

Something along this lines.


> This could be a top-level help window, or one of those popup
> explanations that Windows uses, which don't disappear until you click on
> something. (Grab the pointer and use redirect override on the tooltip
> window?)
>
> This mechanism could be tied into the existing KDE help system (Qt would
> detect the client messages and invoke the existing mechanism), so a
> panel applet or WM could trigger the context-sensitive help attached to
> KDE widgets.
>
> Michael
>


Regards
Sasha Vasko