discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANNOUNCE : HelpViewer 0.1


From: Tobias
Subject: Re: ANNOUNCE : HelpViewer 0.1
Date: Wed, 22 Jan 2003 13:26:53 +0100
User-agent: KMail/1.5

Am Mittwoch, 22. Januar 2003 11:57 schrieb Andreas Heppel:
> I suggest we stop to discuss on what context sensitive help is, how it
> should look like and things like that. I get the impression that we are
> just discussing names for different levels of help. To me it looks like we
> all know what we want, but only name it differently. Let me resume a couple
> of points I think we all more or less agree on:
think you are right. we should get a common naming convention asap.


> - There is something we call tooltips, which is a very short description of
> a control. This pops up automatically some time after the mouse cursor
> starts to hover over an UI element and goes away automatically, too.
thats it.

> - We need an application help being displayed when the user chooses the
> 'Help' menu. This text is an overall description of the app and how it
> works and is displayed in a more sophisticated viewer being able to index,
> search, follow links etc. This currently is supplied by Nicolas'
> HelpViewer. 
i agree.

> - We want some 'context help' being a relatively short description of what
> the user can do in an exact situation, e.g. what is a certain panel used
> for. 
yes, i may agree on that, if s/panel/widget/
see below.

> To me it makes no sense to have some kind of enhanced tooltips being
> displayed in a separate panel (like in Windoze, I don't know KDE).
in kde its a big tooltip
> I want
> this help to be displayed in viewer with exact the same functions as
> described above: follow links to topics, search for keywords etc (which is
> what the Windoze context help does not provide). Thus, I vote for using
> HelpViewer for the context help because it provides (or at least will do
> so) all this.
i think, if this (context help) should be a short description, 
i vote against using helpviewer, but for a tooltip.
btw: thats like late openstep seemed to do too ( [1] )

what you suggest is to (wait for a new application to launch, and) display 
help, about what to do in the whole *situation*.
but i think context help is something to describe one specific widget of this 
situation. such a short help should be displayed instantly and be short.

> The question left is how to make HelpViewer  display only a certain,
> context sensitive portion of the help file. IMO, we must clarify two points
> here: 1. the API by which HelpViewer is triggered and
and yet another api to be defined...

we allready have a openstep api for context help.
we could do it, as described in [1]
( context help automatically out of a localized rtf file )

> 2. how to make context help available to the user, i.e. what will the user
> have to press, click, point to to get context help?
in kde, you have 
a) a window manager hint, 
that is not official backed by icccm or ewmh atm, dont know if it will.
b) a menu entry in help->whats this?
both will change your cursor and display a '?'

i like both.


references:
1  http://www.toodarkpark.org/computers/objc/AppKit/Classes/NSHelpManager.html

> Andreas
cheers
~ibotty





reply via email to

[Prev in Thread] Current Thread [Next in Thread]