Re: Decorating scales
On Tue, Jan 6, 2009 at 5:06 PM, Stefan Kost wrote: > > I would like that a lot. One thing slightly related is that I wonder if the > GtkAdjustment* could be hinted to the theme engines. E.g. for a Panorma > function > the adjustment would be -100 ... 100 or 1.0 ... 1.0. Right now most themes > draw > a filled bar from the left and not from where zero is (the middle for > panorama). Theme engines can and do poke at the widget and get the adjustment, even if that is not really a nice thing to do. The general idea of drawing scales filled in to the thumb is somewhat problematic, since there are plenty of uses for scales where that is not appropriate (like the balance slider I mentioned initially, or your panorama example). We do have style properties allowing to control different drawing of the lower/upper half of the trough (GtkRange::trough-side-details), but we are missing some way for applications to indicate if it is appropriate for a scale to be treated this way, short of gtk_rc_parse_string(). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Decorating scales
On Tue, Jan 6, 2009 at 3:40 PM, Mathias Hasselmann wrote: > Weren't the GtkCellRenderer/GtkCellLayout interfaces written exactly > for stuff like those marks? No, cell renderers are for rendering data in rectangular cells, like in tree or icon views. They are not meant to render decorations like what we have here. If you think about it, even if you added a cell renderer to the scale, you would still have to get the content of the cell from somewhere. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Decorating scales
Matthias Clasen schrieb: > Over the Christmas vacation, I spent a day adding marks to scales. The > motivation for this came from the new sound preferences capplet, which > uses a GtkHScale for balance control. Jon did a nice job of adding > Left/Right labels (see the screenshot), but what is really missing > here is an easy to hit midpoint. > > So I wrote a patch for GtkRange and GtkScale that allows to add > 'marks' to certain values. When dragging the scale over one of these > marked values, there is a little resistance that makes it easy to > select the exact value. The api also allows to > show a label or icon next to the mark. > http://bugzilla.gnome.org/attachment.cgi?id=125318&action=view shows > the > various possibilities. I would like that a lot. One thing slightly related is that I wonder if the GtkAdjustment* could be hinted to the theme engines. E.g. for a Panorma function the adjustment would be -100 ... 100 or 1.0 ... 1.0. Right now most themes draw a filled bar from the left and not from where zero is (the middle for panorama). Stefan > > I'd like to get this functionality into 2.16, if nobody objects, but > I'm not entirely sure that I have managed to come up with the best > possible api for this yet: > > > +void gtk_scale_add_mark (GtkScale*scale, > +gdouble value, > +GtkPositionType position); > +void gtk_scale_add_mark_text (GtkScale*scale, > +gdouble value, > +GtkPositionType position, > +const gchar *markup); > +void gtk_scale_add_mark_icon (GtkScale*scale, > +gdouble value, > +GtkPositionType position, > +GIcon *icon); > +void gtk_scale_clear_marks(GtkScale *scale); do we need 3 functions for adding. why not just: void gtk_scale_add_mark (GtkScale*scale, gdouble value, GtkPositionType position, const gchar *markup, GIcon *icon); and allow text, icon to be NULL. I know that this is not extensible, but right now I can't think of what else to put there. ALso some questions, is icon/text mutualy exclusive? WHat about the placement. Is it always below for hscales and right for vscale (and vice versa for RTL locales?) Stefan > > > Feedback appreciated, Matthias > > > > > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Call for talks - GNOME Devroom at FOSDEM 2009
Hello :) 2008/12/30 Christophe Fergeau : > As for the last few years, we'll have a GNOME devroom at FOSDEM (7/8 > feb in Brussels), and as always, we want *YOU* to give a talk about > the cool project you are hacking on in this devroom > [...] > Please send your talk proposals before Friday 9 January. As always, > the sooner is the better wrt organisation. This is a reminder that the deadline is in just a few days, FOSDEM is 3 weeks earlier than usual this year which is why the deadline is so close. So if you want to give a talk in the gnome devroom or the freedesktop devroom (on sunday), please get in touch with me as quickly as possible. Otherwise, your talk won't appear on the printed schedule and people might not be aware of it :-/ Thanks a lot, hope to see you there :) Christophe ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Decorating scales
Am Dienstag, den 06.01.2009, 10:29 -0500 schrieb Matthias Clasen: > On Tue, Jan 6, 2009 at 12:55 AM, Tristan Van Berkom wrote: > > On Tue, Jan 6, 2009 at 12:41 AM, Yu Feng 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... Weren't the GtkCellRenderer/GtkCellLayout interfaces written exactly for stuff like those marks? So maybe gtk_scale_add_mark_text() and gtk_scale_add_mark_icon() should be replaced by an implementation of the GtkCellLayout interface? Ciao, Mathias -- Mathias Hasselmann http://taschenorakel.de/mathias/ http://www.openismus.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Decorating scales
On Tue, 2009-01-06 at 13:07 -0500, Tristan Van Berkom wrote: > 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) Wouldn't it make more sense to just do a custom theme in the application, instead of providing a GTK+ api? Using the pixmap engine, this is pretty simple. Also, is no guarantee that a custom knob will look any good with the themes trough anyways. Benjamin signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Decorating scales
On Tue, Jan 6, 2009 at 10:29 AM, Matthias Clasen wrote: > On Tue, Jan 6, 2009 at 12:55 AM, Tristan Van Berkom wrote: >> On Tue, Jan 6, 2009 at 12:41 AM, Yu Feng 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
Re: Decorating scales
On Tue, Jan 6, 2009 at 12:55 AM, Tristan Van Berkom wrote: > On Tue, Jan 6, 2009 at 12:41 AM, Yu Feng 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... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Decorating scales
2009/1/6 Andrew Cowie : > On Tue, 2009-01-06 at 00:31 -0500, Matthias Clasen wrote: >> Over the Christmas vacation, I spent a day adding marks to scales. > > I can't speak to the implementation, but this is a lovely initiative. > I've long wished for something like this. > > ++ > > As a related matter; do you think that there would be a reasonable way > to clamp the GtkScale so that only values with marks could be selected? > [is that what you have in mind already?] I didn't plan on doing that, so far. All I was after is a little support in selecting the marked value, not making it impossible to select other values. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GdkDisplay for screensaver
[ This may not be completely related to gdk/gtk ] I m trying to implement "shutting down" screen for my system -ubuntu. while gnome-screensaver is active , on blank screen , I've to show my this shutdown screen. I used , display = gdk_display_get_default (); [using X11 ] screen = gdk_display_get_default_screen (display); gtk_window_set_screen(GTK_WINDOW(window),screen); attached the message to window , and show using "gtk_widget_show_all()". But This message screen is not coming onto my screensaver, but coming onto my Xfce-desktop, Can anyone suggest y so happening ? How to get the display currently being used by gnome-screensaver and show my widget/image onto it ? ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Decorating scales
On Tue, 2009-01-06 at 00:31 -0500, Matthias Clasen wrote:
> Over the Christmas vacation, I spent a day adding marks to scales.
I can't speak to the implementation, but this is a lovely initiative.
I've long wished for something like this.
++
As a related matter; do you think that there would be a reasonable way
to clamp the GtkScale so that only values with marks could be selected?
[is that what you have in mind already?]
Right now I have an application where I am using a using an GtkHScale to
select a minute value [as in hour:minute time] but restricting it to
0, 5, 30, 45, (and 59, since I'm not wrapping). The code I'm using is
this in a GtkRange 'value-changed' handler is something like this:
current = minute.getValue();
if ((current > 0) && (current < 8)) {
minute.setValue(0);
} else if ((current >= 8) && (current < 23)) {
minute.setValue(15);
} else if ((current >= 23) && (current < 38)) {
minute.setValue(30);
} else if ((current >= 38) && (current < 53)) {
minute.setValue(45);
} else if ((current >= 54) && (current < 60)) {
minute.setValue(59);
}
which does work but did seem a tad overbearing. {shrug}; at some point
you've just gotta write code.
I didn't think anything more of it until I saw you implementing marks,
so I figured I would ask.
Nice work.
AfC
Sydney
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
