New modes for GtkProgressBar
Hi All, I have been working on a gtk+ based project in which we had to design some customised UI widget using GTK+. As part of that project, we have created two new modes of appearence and operation for the GtkProgressBar widget. I have attached the screen shots of both of those modes with this mail. Please provide feedback as to how useful these would be to incorporate into the default gtkprogressbar widget code. First mode would be an activity mode which could be used for showing ongoing indeterminate activity The second mode could be used for any situation where a sort of seekbar is required (video playback progress etc.) Thanks in advance Rhi -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning Maverick ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Filter functions and client side windowing
Hi guys, Gentle reminder. Any help on this any help at all would be really useful Thanks On Fri, Oct 21, 2011 at 2:08 PM, Rhishikesh rhishike...@gmail.com wrote: Hi I have been using the GdkFilterFunction mechanism in my library for snooping and processing certain events coming from the Xserver. My code involves the correct detection of the corresponding gdk-window on which the XEvent originated. Since the migration to client side windowing, that mechanism has changed and so every XEvent is reported only on the single Xwindow. I would like to know if there is a method or api which can give me the appropriate gdkwindow in the filter function. Sorry to be posting this question so late considering that the client side windowing was introduced ages ago. But i would really like to know if somebody has faced a similar situation and how it can resolved. Thanks Rhi -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning Maverick -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning Maverick ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: New modes for GtkProgressBar
Le lundi 31 octobre 2011 à 15:54 +0530, Rhishikesh a écrit : First mode would be an activity mode which could be used for showing ongoing indeterminate activity ...and wouldn't you use a GtkSpinner for this? ;-) Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: New modes for GtkProgressBar
On Mon, 2011-10-31 at 17:44 +0100, Milan Bouchet-Valat wrote: Le lundi 31 octobre 2011 à 15:54 +0530, Rhishikesh a écrit : First mode would be an activity mode which could be used for showing ongoing indeterminate activity ...and wouldn't you use a GtkSpinner for this? ;-) Or the activity mode of GtkProgressBar, if you want to switch that progress bar to a determinate progress. See gtk_progress_bar_pulse(). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
New modes for GtkProgressBar
Hi All, I have been working on a gtk+ based project in which we had to design some customised UI widget using GTK+. As part of that project, we have created two new modes of appearence and operation for the GtkProgressBar widget. I have attached the screen shots of both of those modes with this mail. Please provide feedback as to how useful these would be to incorporate into the default gtkprogressbar widget code. First mode would be an activity mode which could be used for showing ongoing indeterminate activity The second mode could be used for any situation where a sort of seekbar is required (video playback progress etc.) Thanks in advance Rhi -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning Maverick attachment: progress_bar_activity.pngattachment: progress_bar_knob_mode.png___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New modes for GtkProgressBar
Le lundi 31 octobre 2011 à 15:54 +0530, Rhishikesh a écrit : First mode would be an activity mode which could be used for showing ongoing indeterminate activity ...and wouldn't you use a GtkSpinner for this? ;-) Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New modes for GtkProgressBar
On Mon, 2011-10-31 at 17:44 +0100, Milan Bouchet-Valat wrote: Le lundi 31 octobre 2011 à 15:54 +0530, Rhishikesh a écrit : First mode would be an activity mode which could be used for showing ongoing indeterminate activity ...and wouldn't you use a GtkSpinner for this? ;-) Or the activity mode of GtkProgressBar, if you want to switch that progress bar to a determinate progress. See gtk_progress_bar_pulse(). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
A GTK+ hackfest opportunity
Hey all, we had a pretty successful GTK+ hackfest in 2010 that really helped us getting GTK+ 3 out the door. It would be great to repeat this experience, and an opportunity for this has opened up recently: There is a possibility that we could do a GTK+ hackfest in Brno, Czech, in February 2012. This would be in connection with the 'Developer Conference' that is happening February 17-18th 2012 at Masaryk University, Brno This event is strongly supported and coordinated by the Red Hat engineering offices in Brno. The hackfest can be longer than these two days, e.g. February 17-21 would be possible. We already have 2 other GNOME hackfest prospects for this weekend, one by the docs team (https://live.gnome.org/Hackfests/BrnoDocs2012) and one by the accessibility team. We are still investigating the details about room availability during and after the conference, but it should be possible to accomodate 10-12 GTK+ people. Possible topics for the GTK+ hackfest that I would like to see on the agenda: - a11y (use the synergy with the accessibility team next room) - clutter (review whats happened on the clutter side, and plan next steps - for this, we'd really need some clutter folk to attend...) - touch (I hope to move the 'kinetic scrolling' patches before the hackfest, but there's plenty of other touch and input-related things to discuss - this topic would really benefit from carlos' presence...) - platform support (in particular if we can get some of the Win32 and OS X people to attend) I think this should be sufficient for an initial announcement; I'll get a wiki page up in the next few days with more details and a place to register your interest in coming. Hope to see you in Brno, Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
