Re: Decorating scales



On Tue, Jan 6, 2009 at 10:29 AM, Matthias Clasen
<matthias clasen gmail com> wrote:
> On Tue, Jan 6, 2009 at 12:55 AM, Tristan Van Berkom <tvb gnome org> wrote:
>> On Tue, Jan 6, 2009 at 12:41 AM, Yu Feng <rainwoodman gmail com> wrote:
>>> Hi,
>>>
>>> If GtkRange were a gtk container perhaps using gtk_container_xxx with
>>> child_properties will be an alternative. GtkContainer also has bettern
>>> granularity - the programmers can modify/remove each marker
>>> individually.
>>>
>>> Unfortunately it isn't a Container.
>>
>> Oh yeah, time for those GContainer/GContainable interfaces, nudge nudge ;-)
>
> One way this _could_ be done is to restrict the GtkScale api to just
> add undecorated marks, and then have a special-purpose
> "DecoratedScale" container that would have one slot for a scale, and
> then allow to add other children to decorate the scale, using child
> properties for the position and the value. The container would then
> use the
> scale marks api to add the marks at the positions/values which its
> children request,
> and position the child widgets next to the marks.
>
> Not sure the minor benefits justify the effort, though...
>

In my most heavy usage of sliders, I was blessed to be working in
a kiosk like fixed resolution environment - making it very easy to draw
the marks in a background image on the slider itself.

I can see this work will be essential for mixers in dynamic/resizable
interfaces.

I found this on google quickly:
  http://cfbstaff.cfbisd.edu/paciottib/Video_Production/vpimages/6Mackie_BIG.jpg

Note at the bottom the slider marks, its important to mark greater and
lesser marks
(i.e. 0%/50%/100% are usually bigger marks than 11% or 72%...), we may also need
to draw marks thinner when they are more crowded.

Some requirements we had:
 - allow the knob to be an rgba pixbuf (we would just composite it when it
   changed position in the trough, could we achieve nice round-edged sliders
   with a child widget knob ? that would be ideal I think, it could
implement a knob
   iface to update user feedback from the slider value)
 - clamp values according to other values, i.e. volume_min <
volume_value < volume_max
   (the slider would adjust its value if needed when its max or min
was changed, doing this
   from inside the slider code allowed us to prevent visual glitches)
(this min/max clamping
   would be an interesting future addition alongside Andrew's ideas)

With this in mind, I think its may be a bad idea to have child widgets
on ticks, could
be memory intensive when using lots of ticks for no real reason, what
might be useful on the other hand is:
 a.) do provide an icon api to allow custom images to be drawn, its
easy and straightforward.
 b.) export a tick-expose-event signal in which the base
implementation would draw the tick
      in its area using the icon or text or mark, but allow the user
to draw it on the slider's behalf
      (the slider would emit the signal inside ->expose() ofcourse for
all the ticks).

Now it would be really nice to have a knob child, I'm quite sure it
can be done by introducing a container
iface in gobject and using GContainer everywhere inside of gtk+
instead of GtkContainer, and making
GtkContainer implement GContainer, allowing us to make any widget we
want be a container in the
future, also allowing us to use the api with child properties outside
gtk+... all that without breaking
any apis... am I wrong ?

Anyway, thats alot too much to ask for gnome 2.26 ;-)

Well these are some of my thoughts on sliders, hope this was helpful :)

Cheers,
               -Tristan

Another note:

We should also be able to distinguish in the api whether or not a mark
induces a behavioral snap,
with lots of active marks, you probably only want a few of them to
snap-to-value.
(the snap is a tricky thing, on touchscreens we needed to ensure the
close values to the center
mark were also selectable somehow, I think we only ever snapped to the
value if the "slide" initiated
outside the snap threshold, allowing you afterwards to select (mark_value -1)).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]