Re: Scroll bars.

[Gary V Vaughan <garyv aethos co uk>]

On Mon, Jan 26, 1998 at 01:15:45PM -0500, raster@redhat.com wrote:
> And this is all the more reason for themes. Let the user configure his
> apps how he/she/it likes them. users can select laft/right scrollbar,
> top/bottom scrollbar, arrows, no arrows, etc. etc. etc. Then there is
> no argument anymore. It's a user preference. Let's not get religious
> about "I like next style" or "I like win95 style" or " I like mac style"
> or "I like xaw style". In the end everyone likes something different.

I couldn't agree more.  Something I have always had a hankering for, and which
I have yet to see, would be for the widget set itself to be pluggable.  That
is, a "scroll-bar" (for example) can be any old loadable module which exports
a published API and accepts a published set of signals.  That way as part of
a theme (or perhaps in addition to =)O| ), a programmer can write their own
scroll-bar widget and have all of the apps which use the widget set use
_their_ own scroll-bar rather than the default.  This is more than just
putting a bitmap in the trough and how wide the slider is... I could
actually choose whether I want arrows at either end, or together, or not at
all etc.

Yes I know this gives us enough rope to hang ourselves, but provided a theme
is written to allow the theme user to override a theme's peculiar widgets, I
believe this would engender some real innovation in ui design, allowing
programmers to experiment with a small part of an interface in their
day-to-day use without needing to hack gtk (or learn how the whole thing
interacts).

> That, in my humble opinion, is a really good reason to discuss and get
> some theme framework desgined and documented, that gives a full scope 
> of options for the user to modify at their leisure, and thus will allow
> the programmers to start work on this, instead of waiting for some
> desgin to materialize. If this isn't done now, sometime in the future
> we will have springup projects like gtk-next gtk-macos gtk-E etc., with
> each having different bugs, incompatabilites etc. We need to have a
> framework in place that allows easy expansion and modification by users
> via a gui. Whole sets of gui configs can be packaged together in themes.

...which reminds me, my point was, that a gui _config_ is inherently limited by
the design of the widget set (no matter how good), it might be interesting
to consider the possibility of _overriding_ parts of a widget set and see what
bubbles up to the top.

Cheers,
		Gary V Vaughan
-- 
{#include #.signature#}
WARNING:  Cannot find '.signature' template file