Re: ANNOUNCE : HelpViewer 0.1

[Andreas Heppel]

On 2003-01-22 13:26:53 +0100 Tobias <ibotty@web.de> wrote:

<snipped stuff we agree on :) >
>> - 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.
s/panel/ui element/

> 
>> 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] )
With short I mean more than what a tooltip provides, but less than the help for 
the whole app. As Björn already mentioned : "What can I do in the current 
context?" That's why openstep needs a panel for this.
> 
> 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.
This can nicely be done using tooltips. Thus, I don't understand why openstep 
introduced the below mentioned API to open a (modal) panel. This overhead makes 
only sense if you use a separate help file containing more than a short 
sentence.

> 
>> 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 )
> 
I didn't want to say we need to introduce another API. I think we can use the 
current API to trigger from within GNUstep an external application (HelpViewer) 
or open a buit-in panel if there is no 'help application'.
Once more I'd like to point out that I want to be able to reach the rest of the 
app's help from this context help panel. In the case of Windoze this was not 
possible, and I remember that I usually got pissed that I couldn't just link 
(as developer) or lookup (as user) different topics. 

>> 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 '?'
c) We could use a key, e.g. F1. I would prefer this to a menu entry (less mouse 
moves necessary).

Cheers,
Andreas

-- 
Andreas Heppel

Mail: aheppel at web dot de
Home: http://www.andreasheppel.de

Check out GSburn.app - the CD burning frontend for GNUstep
http://gsburn.sourceforge.net