--without-toolkit-scroll-bars at runtime?

--without-toolkit-scroll-bars at runtime?

[David Kastrup]

Hello folks,

how difficult would it be to make "--without-toolkit-scroll-bars" a
runtime instead of or in addition to being a compile-time option?

Background: for serious use, the "modern" scroll-bars (everything
Post-Athena) are deficient.  You can't switch between back- and
forward motion without moving the mouse, you can't control the scroll
amount to get just the right window start for getting a
block/function/loop fully on-screen.  Something which, by the way, is
also hard to do by keyboard given Emacs' recenter policies.

Now recompiling Emacs for maximal productivity is a better option than
not being able to do this at all, but it does not lend itself to the
"sysadmin has weird settings that he does not enforce unto his users
unless they ask for it" scenario that is quite common.

Since this is not just a how-things-look, but quite a definite
usability question, being able to deviate from the toolkit default
without recompiling would be nice to have.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: --without-toolkit-scroll-bars at runtime?

[Stefan Monnier]

> how difficult would it be to make "--without-toolkit-scroll-bars" a
> runtime instead of or in addition to being a compile-time option?

I had started to look into it at some point.  It's probably not too
difficult, but still a fair bit of work.  Doesn't look like it's worth
the trouble.

A more interesting direction (to me anyway) would be to change the
toolkit's behavior.  Xaw3d (by default) behaves just liek Xaw so you get the
3d look while keeping the flexibility.  Sadly RedHat's Xaw3d is not using
the default, instead it's compiled with -DARROW_SCROLLBAR to get the dumber
behavior (and little arrows at the end), I can't remember what Debian does.
It wouldn't be too hard to make the Xaw3d behavior changeable at runtime
with Xresoucres.  Hopefully someone will make that change.

Similarly, it would be good to provide a Gtk "theme" that gives Xaw-like
behavior (or some other: there used to be a variety of useful behaviors in
various scrollbars, such as the one used in the Smalltalk machine, ...).
But I doubt it can currently be done with just a theme.

> forward motion without moving the mouse, you can't control the scroll
> amount to get just the right window start for getting a
> block/function/loop fully on-screen.  Something which, by the way, is
> also hard to do by keyboard given Emacs' recenter policies.

I use C-0 C-l and it's worked fine so far.  But I admit I've never tried it
with images in the buffer.  In any case, it *should* work, so if it doesn't
we should try and fix it.


        Stefan

Re: --without-toolkit-scroll-bars at runtime?

[Richard Stallman]

    how difficult would it be to make "--without-toolkit-scroll-bars" a
    runtime instead of or in addition to being a compile-time option?

It would be quite hard, and I don't want to do it.

Re: --without-toolkit-scroll-bars at runtime?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     how difficult would it be to make "--without-toolkit-scroll-bars" a
>     runtime instead of or in addition to being a compile-time option?
>
> It would be quite hard, and I don't want to do it.

Well, then I should probably get back to nagging GTK+ people about
their scrollbars.  I did several times in the past, but nothing came
of it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: --without-toolkit-scroll-bars at runtime?

[Miles Bader]

On Mon, 21 Mar 2005 11:28:57 -0500, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Similarly, it would be good to provide a Gtk "theme" that gives Xaw-like
> behavior (or some other: there used to be a variety of useful behaviors in
> various scrollbars, such as the one used in the Smalltalk machine, ...).
> But I doubt it can currently be done with just a theme.

Just having the more sensible mouse-click bindings (mouse-1 = forward
by N% anywhere in the scrollbar, mouse-2 = opposite) would be a
tremendous improvement.  Does GTK filter-out all the useful
information before handing scroll clicks to Emacs?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: --without-toolkit-scroll-bars at runtime?

[Ehud Karni]

On Mon, 21 Mar 2005 02:36:08 +0100, David Kastrup <dak@gnu.org> wrote:
>                                          you can't control the scroll
> amount to get just the right window start for getting a
> block/function/loop fully on-screen.  Something which, by the way, is
> also hard to do by keyboard given Emacs' recenter policies.

May be the following commands can help you achieve this.

(defun line-to-top (arg)
  "move current line to top of window"
    (interactive "p")
    (recenter (1- arg))
    (middle-window))

(defun line-to-bottom (arg)
  "move current line to bottom of window"
    (interactive "p")
    (recenter (- (window-height) (1+ arg)))
    (middle-window))

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

Re: --without-toolkit-scroll-bars at runtime?

[Jan D.]

> On Mon, 21 Mar 2005 11:28:57 -0500, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>> Similarly, it would be good to provide a Gtk "theme" that gives 
>> Xaw-like
>> behavior (or some other: there used to be a variety of useful 
>> behaviors in
>> various scrollbars, such as the one used in the Smalltalk machine, 
>> ...).
>> But I doubt it can currently be done with just a theme.
>
> Just having the more sensible mouse-click bindings (mouse-1 = forward
> by N% anywhere in the scrollbar, mouse-2 = opposite) would be a
> tremendous improvement.  Does GTK filter-out all the useful
> information before handing scroll clicks to Emacs?

Yes, the behaviour on different buttons is hard coded, no configuration 
possible.  A possible approach is to intercept mouse events and handle 
them in Emacs rather than passing them to the scroll bar.  This may be 
desirable for other reasons also (overscrolling).

	Jan D.