#46 single window help with history

development
closed
Eddy De Greef
Program (79)
5
2002-05-06
2002-03-07
No

This patch modifies the nedit 5.3 help system to reuse
an existing help window when following links in the
help system.

Additional windows can be created by using Btn2 to
follow the link. As already implemented in the current
help system, there are never duplicate windows for the
same help topic, that means following a link to an
existing help topic window always tops that window.
A second help window is created too (please tell your
opinions if this should be changed) if there is already
a help window and a currently not displayed help topic
is selected from the NEdit help menu, that means
windows are reused only for following links inside the
help windows and the prev/next buttons.

A simple navigation history is implemented: every help
topic window which has been reached following a link
remembers the source (and vice versa).

There are for small text only navigation buttons
(freaks are invited to create pixmaps... ;-)
<< history backward
<+ previous help topic (not affecting the history)
-> next help topic (not affecting the history)
>> history forward

Markus Schwarzenberg

Discussion

1 2 > >> (Page 1 of 2)
  • Eddy De Greef
    Eddy De Greef
    2002-03-07

    Logged In: YES
    user_id=73597

    It looks good in general.
    The buttons are confusing though: I had to read your
    description again to figure out their meaning. The symbols
    are just too cryptic (and no pixmap is going to change
    that). I suggest you spell them out:
    Back, Previous topic, Next topic, Forward.
    I'd also change the order: place Forward next to Back.
    The current order suggest that there is a relation between
    the two kinds of navigation, while there isn't one.
    Also, to keep the current form factor of the help
    windows, it's probably better to place the navigation
    buttons on a separate row.

     
  • Thorsten Haude
    Thorsten Haude
    2002-03-09

    Logged In: YES
    user_id=119143

    I got a core trying the patch. Sorry, I can't repeat it,
    all I have is the backtrace.

    http://www.vranx.de/nedit/backtrace.png

     
  • Logged In: YES
    user_id=81393

    Thanks, Eddy, for the naming and rearrangement proposals.
    They are implemented now, however we have 2x4 buttons now
    (I'm sure not everybody will like this ;-).

    I made also some small internal changes:
    - The help window gets a more expressive title now
    - The button1/button2 event handlers have gone, now there is
    an action help-hyperlink for following the links. Actually
    it's intended to make the accelerators completely user
    configurable (via $XAPPLRESDIR/NEdit), but I still have to
    figure out how to install the nedit default translations (as
    fallbacks) before the application wide resources
    ($XAPPLRESDIR/NEdit) get read in (I think something must be
    done before CreateShellWithBestVis in createHelpPanel()).
    However, this hopefully will be only a small change and it's
    already possible to add translations using other
    accelerators.
    - editres support added.

    Concerning the core dump backtrace:
    The current event handling model has gone (in the first
    version it was possible that mix <btn2> events and text
    widget actions got mixed - maybe that was the reason...)

     
  • cvs diff -c help.c (1.76) help.h(1.8) nedit.c(1.30)

     
  • Logged In: YES
    user_id=81393

    Find the 3rd version of this patch below. Now the default
    translations are set before the user defined resources are
    read, thus making the accellerators for following help
    hyperlinks completely user adjustable.

    BTW, the default translations are:
    nedit.helpForm.sw.helpText*translations: #override \ ~Meta~Ctrl~Shift<Btn1Down>:grab-focus() help-hyperlink()\n\ ~Meta~Ctrl~Shift<Btn1Up>:help-hyperlink("current",
    "process-cancel", "extend-end")\n\ ~Meta~Ctrl~Shift<Btn2Down>:process-bdrag()
    help-hyperlink()\n\ ~Meta~Ctrl~Shift<Btn2Up>:help-hyperlink("new",
    "process-cancel", "copy-to")

    For a description of help-hyperlink() see help.c.

    If no bugs are found and there are no feature requests I
    would now consider this patch as "temprorarily complete" for
    now.

    Markus Schwarzenberg

     
  • cvs diff -cvs diff -c help.c (1.76) help.h(1.8) nedit.c(1.30)

     
  • Logged In: YES
    user_id=81393

    ... in the new help_one_window_03.diff unused variables are
    removed. no other changes.

     
  • Thorsten Haude
    Thorsten Haude
    2002-03-11

    Logged In: YES
    user_id=119143

    I have to say that I don't like the look of the new two-row help window.
    1. It looks somewhat antiquated for me.
    2. Symbols, even symbols created using characters ( eg. '<<'), are faster to grok.

    Therefore:
    1. Use the two-part button row from the first patch.
    2. I think this shouts for icons. I asked a friend less graphically handicapped than I am, and he will
    create some icons till Thursday.

    (No core btw.)

     
  • Thorsten Haude
    Thorsten Haude
    2002-03-11

    Logged In: YES
    user_id=119143

    Is it Thursday already?
    http://www.ritschratsch.de/neditbuttons/

    Some comments from him:

    - the Topic buttons could also be done with a second, 'deactivated' arrow, eg. hollow.
    - the arrows in both Topics button could move on top

    Some comments from me:

    - I wouldn't use italic arrows
    - the tiny 'activated' line in the Topic buttons could be placed in the more to the middle of the tiny list
    - I like them

    - all of the above

     
  • Logged In: YES
    user_id=81393

    > 2. Symbols, even symbols created using characters
    > ( eg. > '<<'), are faster to grok.

    For me symbols aren't faster to grok. I've looked at the
    proposals: The menu up/down buttons are OK if one knows that
    they are to replace the prev/next topic buttons which
    formerly have been there. But when I see arrows left/right I
    really don't know what they mean until I have tested them
    (First I would think of something like "scroll the window to
    the left/right" or change indent or somethink like that). I
    can't see quickly that they are related to a history (But I
    must admit I'm one of the people who still haven't
    understood why commonly a spyglass is used as icon for
    "search". When I'm looking for something I never use a
    spyglass).

    Besides that, we don't have pixmaps in nedit anywhere (exept
    the icon, of course). Why should we need them here...

    However, somehow I also would like to save the additional
    row. Perhaps, when I have the time (not this week) I could
    add a compile-time switch or even a resource.

    Markus Schwarzenberg

     
  • Eddy De Greef
    Eddy De Greef
    2002-03-12

    Logged In: YES
    user_id=73597

    I agree with Markus.
    AFAIK we currently don't use pixmaps anywhere, and
    pixmaps should always come with a(n optional) tooltip
    or text below them. Moreover, we have mnemonics for about
    every button in NEdit; with pixmaps that would be difficult.

    I also have another remark wrt. the history implementation:
    when I use one of the find buttons, I can switch to another
    topic, but I cannot go back. Would it be hard to take that
    into account for the history ?

     
  • Logged In: YES
    user_id=81393

    > I also have another remark wrt. the history
    implementation:
    > when I use one of the find buttons, I can switch to
    another topic, but I cannot go back.
    > Would it be hard to take that into account for the history
    ?

    No. (I don't know why I forgot this...). See new patch
    version attached.

     
  • cvs diff -cvs diff -c help.c (1.76) help.h(1.8) nedit.c(1.30)

     
  • Thorsten Haude
    Thorsten Haude
    2002-03-12

    Logged In: YES
    user_id=119143

    Sender: schwarzenberg
    >For me symbols aren't faster to grok.
    Are you sure? Have you ever been in the USA, where you
    have to
    actually *read* road signs instead of just seeing them?

    >The menu up/down buttons are OK if one knows that they
    are to replace
    >the prev/next topic buttons which formerly have been
    there.
    Some symbols need knowledge.

    >But when I see arrows left/right I really don't know what
    they mean
    >until I have tested them
    That is the one symbol 90% of users will instantly
    recognize, because
    every browser uses the very same symbol for the very same
    functionality.

    >(First I would think of something like "scroll the window
    to the
    >left/right" or change indent or somethink like that).
    Why would you want to do that?

    >Besides that, we don't have pixmaps in nedit anywhere.
    (Uh.) So?

    >Why should we need them here...
    Well, assuming they are the better solution: Because they
    are the
    better solution.
    - - -
    Sender: edg

    >pixmaps should always come with a(n optional) tooltip or
    text below
    >them.
    Right, that is a problem. If this is the only complaint, I
    would try
    to bring them in.

    >Moreover, we have mnemonics for about every button in
    NEdit; with
    >pixmaps that would be difficult.
    Right, that is another problem. If we had pixmaps, we
    could use
    mnemonics though ('Next [T]opic').

     
  • Logged In: YES
    user_id=81393

    The new version of the patch (help_one_window_05.diff)
    contains an additional action proc "help-focus-buttons()"
    which is bound to <Key>Tab in the help text area by default
    (everybody can change this by .Xdefaults ;-). This action
    switches cursor navigation back to the buttons.

    Additionally, there are some improved comments in
    helpHyperlinkAP.

     
  • cvs diff -c help.c (1.78) help.h(1.8) nedit.c(1.31)

     
  • Eddy De Greef
    Eddy De Greef
    2002-03-18

    Logged In: YES
    user_id=73597

    Can you make that a patch against the BETA-5-3 branch ?
    (Or is it already ?)
    Thanks.

     
  • Logged In: YES
    user_id=81393

    OK, here is the same patch (help_one_window_05.diff) but
    diffed against BETA-5-3.
    The patch file is help_one_window_05-BETA-5-3.diff.

     
  • Eddy De Greef
    Eddy De Greef
    2002-03-18

    Logged In: YES
    user_id=73597

    Thank you.
    There's one problem, though: when the text pane has the
    focus, Enter and Escape are not recognized any more (both
    of them should dismiss the window, because the Dismiss
    button is highlighted when the text widget has the focus).

    I guess it's just a matter of adding additional key bindings,
    as you did for Tab.

     
  • Logged In: YES
    user_id=81393

    OK. Now (help_one_window_06-BETA-5-3) we have:
    help-button-action(<button-widget-name>).

    The required argument must have one of the following values:
    "find", "findAgain", "print", "dismiss",
    "prevTopic", "nextTopic", "histBack", "histForw"
    -- these are just the widget names of the buttons.

    Return and osfCancel are bound by default to:
    help-button-action("dismiss")

    Perhaps we should also bind Ctrl+F to
    help-button-action("find") ? ... and so on ...
    But since we still have the Alt-... accelerators I left the
    other unbound for now.

    Now the text pane gets the initial keyboard focus. I think
    that's the more expected behavior, thus people can
    immediately start navigating the help text.

    Markus Schwarzenberg

     
  • Eddy De Greef
    Eddy De Greef
    2002-03-18

    Logged In: YES
    user_id=73597

    Much better, thank you.
    One more nit: there's no visual indication as to where
    the current focus is (except for the cursor, which is
    hard to see). It would probably be better if the highlight
    thickness of the buttons was not set to 0, but to 2.
    That would also make the appearance more consistent
    with that of buttons in other dialogs. Don't you think so ?

     
1 2 > >> (Page 1 of 2)