Re: scrollbar display options
- From: Paul Davis <pbd Op Net>
- To: Drazen Kacar <dave arsdigita com>
- Cc: gtk-list gnome org
- Subject: Re: scrollbar display options
- Date: Sat, 28 Apr 2001 08:52:42 -0400
>> The positional indicators would be quite unnecessary if the scrollbar
>> had the functionality that a click anyway in its length moved to that
>> position. Some scrollbars (perhaps even GTK+'s) work this way.
>
>The widget is a slider (not a scrollbar) and a click moves the slider
>to the left or to the right, but only for a predefined number of units,
>not to the position at which you clicked.
Right, this is what I meant. I should have called it a slider. Anyway,
some sliders (and scrollbars) work the way I described. That seems to
me to be the correct method of doing what you were trying to accomplish.
>However, that is not supposed to be the main purpose of the indicators. At
>first I had the application without them, but then I noticed that it's
>hard to see how much I'm off from the center or the edges. So (for me,
>at least) the indicators are mostly indicators, not controls. Making them
>clickable was just an added bonus, because slider widget didn't have that
>functionality, I think. In the original audiocontrol utility they are not
>clickable.
Just because they may be intended as purely visual aids doesn't change
the principle: don't try to aggregate distinct widgets to accomplish
such a thing.
>> As a general principle of design-with-themes-in-mind, don't ever try
>> to aggregate distinct widgets into a "whole" simply by placement. If
>> you want a scrollbar with tick marks under it, you need a new widget
>> type. Likewise, if you want a widget thats like the spinbutton, but
>> puts the arrows in different places, don't try to use a GtkEntry plus
>> two GtkArrows - this may come out wrong with certain themes. You need
>> a new widget that ensures the placement because of its internal design.
>
>OK, that looks like a sensible advice, but can I do it with GTK? There are
>theme engines (all with NeXT-ish look, I think) which are implemented by
>changing GTK functions with their own. As far as I understand the
>situation, this is not supported, but it currently "works", up to a point,
>at least. In case I create a widget which is a combination of scrollbar
>and something else and the user wants to have a theme with NeXT-like
>scrollbars, would the scrollbar in my widget have NeXT look?
As long as you implement the widget correctly, yes, it will. If you
try to take short-cuts, then it might not.
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]