Re: [Groff] gxditview feature request

[Tadziu Hoffmann]

> > [...] but also try to remember those awful, counterintuitive
> > Mosaic mouseclick scrolls.

Hey, don't say that.  I think it's nice that xterm still uses
the athena scrollbar, in contrast to other terminal emulators.
(But then I'm also a vim user and I favor RPN calculators.)


[snip]

> but the application must "install" accelerators, e.g.
> XtInstallAccelerators(), to link a possible source hierarchy
> of the event with the destination widget that should handle
> them.  I don't think the Athena Paned widget does this
> automatically, but could be wrong.
> 
> Anyway, it seems some code changes may be required after all
> and I don't have a solution or further time to work on it but
> I thought this might be of use to anyone who has.


Some time ago Joerg also asked whether it was possible to do
"intelligent scrolling" in xditview like in gv (i.e., scrolling
by columns from top left to bottom right and then jumping to
the next page).  I haven't had much time to look into this,
but I think that implementing intelligent scrolling will
only be possible with some nontrivial changes to the xditview
source, for the very simple reason that xditview is currently
not aware of the scrolling at all -- scrolling is completely
handled by the widget code, without any feedback from xditview.

Nevertheless, with a few limitations, simple scrolling via
the keyboard within a page can be made to work.  As Ralph
has already noted, the primary difficulty lies in the fact
that the scroll commands must be given to the scrollbars,
whereas we would like to be able to keep the pointer in the
actual display area.  The athena widget set does provide a
generalized mechanism called "accelerators" for this (e.g.,
to invoke menu items from the keyboard).  Accelerators act
in most aspects like normal event translations, but there
are a few caveats involved:

  1. The accelerators must be explicitly "installed", and
     they are valid only for the particular *instance* of the
     widget.  In our case that means that if the scrollbar
     gets destroyed and then recreated, the accelerators are
     lost.  Therefore I suggest that we keep the scrollbars
     always visible.  (Otherwise you would probably need to
     keep track of resizes, guessing when scrollbars get
     created and then again installing the accelerators.
     Remember that the viewport widget currently controls
     all of this autonomously.)

  2. Events (key or button) do not get passed upward in the
     hierarchy by a widget if that widget has any translations
     for that type of event (key or button).  That means
     you may not have any key translations for the "clip",
     "viewport", or "label" widgets[*], neither in your
     .Xdefaults / app-defaults / X resource data base,
     nor in the builtin fallback resources. That means we
     have to replace the builtin app-defaults and get rid
     of or replace those translations in .Xdefaults and
     /etc/X11/app-defaults/GXditview.  [*]My idea here is to
     install the accelerators on the "paned" widget, so that
     keyboard scrolling works even with the pointer in the
     "label" field at the bottom.

Another limitation to scrolling with the keyboard is that
without using the mouse the athena scrollbars can only be made
to scroll for a full length of the scrollbar.  If you need
smaller steps, I guess the only way is by providing a dedicated
callback procedure that explicitly sets the position.

Within these limitations, making scrolling work from
the keyboard requires only small changes to the code.
I've attached a diff file for xditview.c (only one line to
be inserted) and a GXditview.ad file to replace the one in
groff/src/devices/xditview. (You may also need to get rid of
conflicting app-defaults elsewhere.)  I've also chosen some
pretty pastel colors which are much easier on the eyes than
the default black & white setup.

xditview.c.udiff
Description: Text document

GXditview.ad
Description: Text document