Re: scrollbar display options

[Havoc Pennington <hp redhat com>]

"Timothy M. Shead" <tshead k-3d com> writes: 
> Sorry, but the "father knows best" approach is less than ideal - it
> presumes that the designers of a library can forsee all its possible
> uses and plan for them which, thanks to human ingenuity, is never true.
>   I've noted many postings to this list regarding the size of
> scrollbars, usually because the application is being used with alternate
> input devices such as a touchscreen in a kiosk or a stylus device.  I
> happen to be working on the user interface for wearable computers for
> use outdoors, and I can tell you that getting people to understand that
> the user interface can't just be a smaller version of a desktop
> application is tough ... my point being that there *are* legitimate
> reasons to generate user interfaces that have a non-standard appearance.
>   I understand that the goal of preventing further fragmentation of the
> appearance of the Linux desktop is a good one ... but by imposing
> policies that prevent GTK+ from being used with anything other than a
> mouse on a desktop, you only *increase* fragmentation when developers of
> embedded and other specialized applications are driven to other toolkits.
> 

A couple points:

 a) Yes the toolkit should allow the programmer to set things, but 
    it's also valid to always put the "caveat: don't do this for 
    general desktop apps" in mails discussing how to do it.

    In general for GTK 2 we have given up on trying to keep people
    from doing evil things, for the reason you give, and also because
    people do the evil things wrong which makes them
    extra-deluxe-evil; by putting something like gtk_window_maximize()
    or gtk_window_modify_fg() in the toolkit, at least we have the
    best possible implementation of the evil, instead of some 
    non-working hack thing with nasty side effects.
 
 b) Ideally, we could handle embedded and specialized apps 
    without hardcoding, e.g. with gtkrc. Because on an 
    embedded device you have the same consistency issue
    as with the desktop, it's just that the defaults should 
    be different, or that you're trying to make the toolkit
    do something it wasn't intended for.

    So while hardcoding may be required to push the toolkit
    into this environment, the hardcoding is still a hack to 
    work around stuff that ideally would get resolved on the 
    toolkit level (and we are willing to do that, btw, given 
    the right kind of information). On a handheld, hardcoding 
    is still going to break themes, accessibility, app consistency,
    and so on. It's just that one judges the tradeoff worth it 
    since there's no real alternative.

Havoc