Re: "What's this"

[Sasha_Vasko osca state mo us]

> Sasha_Vasko osca state mo us writes:
> > Clients should not be bothered with displaying help, unless you want to
> > bloat all of them with basically identical help rendering code.
>
> The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue.
>

wait a sec. Are we disscussing "what's this" feature applicable only to
toolkits ? If so then I retract all my proposals.

I thought that you wanted to be able to get help not only on toolkit
windows
but universally on any object on the desktop. I don't think that any
sane window manager is going to implement its own hyperlinked help
browser - the best you can count on is popping up mozilla or term with
man page/faqs displayed in it. What that brings you to is that user may get
all kinds of help systems from different desktop objects - from GTK apps -
one,
from QT apps - another and completely different from something else,
and nothing at all from most other things. All of those things will
have different look and feel, which is not nice. If you really want to
implement global help system, you have to think about signle app, that can
display help for both GTK/Qt as well as the rest of the world.


If all you need is internal toolkit help browser - then why bother with
standard? I don't think it will make any sense at all for window manager
to implement "What's it" button which will work only in GTK/QT, and
will not work correctly even on its own interface elements.

Besides do you actually see all the apps linked as dynamically only
from now onwards? Cos if you link it statically - you do get bloat issue.

> There are two problems with the approach you mention:
>
>  - people want something higher-level than text in the help,
>    e.g. a simple HTML-like subset with links, etc.

It's not difficult to implement help browser that would intelligently
distinguish between help available in HTML, XML, man pages or any other
format. And in fact man pages could be displayed as a hyperlinked text, and
are
very nice in that way.

>
>  - help needs to work within a client even if no "help manager" app is
>    running; i.e. the client needs a fallback implementation in any
>    case, it can't rely on a desktop runtime environment being active.
>    So you can't eliminate the toolkit code in any case. (And Qt
>    already has this code, anyhow.)

Well, if globally active help system is not running - then this entire
disscussion is not applicable anyways - each client will have to rely
upon itself entirely.

The interesting implication is that you do not really need window manager
involvement at all - you click on desktop icon/menu item-> that will launch
help app -> help app grabs pointer and waits for a click -> then it
traverses window tree in order to find out any parent window with wm hints
set.
etc. etc. etc.

> man pages certainly aren't the kind of help we're discussing here;
> what's this help is just a paragraph on the specific widget that's
> been clicked. Sort of longer tooltips, maybe with embedded links to
> the full documentation for the app.

It still has to be a paragraph out of complete set of docs - and as such I
do not see much difficulty in displaying particular topic out of HTML file,
or even a man page for that matter.


Anyways I just proposed the way it could be implemented using
standard X approach. I don't seem to see any other alternative proposals,
except for Michael Roger's one , which is basically the same as what I
proposed, only with messages instead of selection( which is not good
for 2-way communications).


So what is this exactly we are arguing about ? What is your alternative?

>
> Havoc