On Tue, Jan 6, 2009 at 10:29 AM, Matthias Clasen <matthias.cla...@gmail.com> wrote: > On Tue, Jan 6, 2009 at 12:55 AM, Tristan Van Berkom <t...@gnome.org> wrote: >> On Tue, Jan 6, 2009 at 12:41 AM, Yu Feng <rainwood...@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)). _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
