Re: scrollbar display options



>> 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]