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
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
Filter functions and client side windowing
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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkTreeView in VBox
Hi, I have also faced a similar situation in which case i need to pack a treeview inside a VBox. I would not mind the treeview apis not working but the packing is something i am looking to keep. The scrolling of the VBox works fine for smaller sizes of the TreeView. But when the treeview consists of elements greater than a certain number of elements (450) in my case, the scrolling goes awry between adjustment values 16000 and 27000 (sounds strange, i know.). Please help. Any suggestion is welcome. Thank you for your time. Kristian Rietveld wrote: On Thu, Jan 7, 2010 at 1:24 PM, Amol Kulkarni amolgkulka...@gmail.com wrote: Is it possible to add GtkTreeView inside VBox and then add that VBox to ScrolledWindow using gtk_scrolled_window_add_with_viewport(sw,vbox). Is this expected/supported use case or am i doing something wrong here? Thanks for your time. No, it's not a supported use case. GtkTreeView and other scrolling widgets such as GtkIconView are meant to be placed directly in a GtkScrolledWindow. Not doing so will, for example, break scroll commands given by GtkTreeView itself, since it is not directly connected to the GtkScrolledWindow anymore. Such scroll commands are given when you are setting a cursor on a row and want to make that row visible, automatic scrolling during drag selection, or by the application programmer using the gtk_tree_view_scroll_to_cell() and related functions, etc. Another reason why this is a bad idea is memory usage, although I cannot tell for sure whether this still holds for GTK+ 2.18 and later. For earlier versions of GTK+ a large X window has to be allocated if you are placing a GtkTreeView with a large number of rows in a VBox or similar container. regards, -kris. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
