Re: scrollbar display options
- From: Havoc Pennington <hp redhat com>
- To: "Timothy M. Shead" <tshead k-3d com>
- Cc: gtk-list gnome org
- Subject: Re: scrollbar display options
- Date: 28 Apr 2001 15:10:42 -0400
"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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]