Re: Tooltips inside a TreeView.
Nicolas Cormier wrote: Hi all, I was wondering if it's possible to do row specific tooltips. Thanks in advance. It is not so easy, but it can be done. I'd recommend looking at gaim's (http://gaim.sf.net) sources: see file gtkblist.c, starting at the motion-notify-event he sets up in a TreeView (don't remember the name of the function right now). -- I used to be Snow White, but I drifted. -- Mae West Eduardo M KALINOWSKI [EMAIL PROTECTED] http://move.to/hpkb ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkExpander label widgets (using buttons as)
I have a GtkExpander and I set its label widget to an hbox to which I added a label and 2 buttons. They all display nicely, but the buttons don't work properly. When I click on them it activates the expander instead of the buttons themselves. Actually, a couple of the button's top and bottom rows of pixles will respond to mouse clicks, but none of the center area does. Is this supposed to work? Thanks, David ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Efficient use of GDK Graphic contexts
I'm building a form designer application and need to draw a grab border around widgets when the user selects them. This part seems straight forward and I've already got the border drawing working from the expose event. My question is how do do this in an efficient manner since GCs seem to be tied to windows. Currently I'm just building and destroying a new GC each time the expose() event fires. I know this isn't efficient at all, and I only did it this was to test that I could actually draw a border. GCs are tied to windows, so it would seem I'll need a GC for each widget on my form or can I have one GC and use it for all the widgets? I guess I'm asking what sort of overhead is involved in: 1) Creating a GC 2) Destroying a GC 3) Switching the window a GC is connected to 4) Memory overhead of each GC Thanks for any help or suggestions. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkExpander label widgets (using buttons as)
David Caldwell wrote: I have a GtkExpander and I set its label widget to an hbox to which I added a label and 2 buttons. They all display nicely, but the buttons don't work properly. When I click on them it activates the expander instead of the buttons themselves. Actually, a couple of the button's top and bottom rows of pixles will respond to mouse clicks, but none of the center area does. Is this supposed to work? I would think so... actually; when I try out your described setup in the glade3 builder; it definitly worsforme, I wonder if that is only due to the gui builder environment. Can you reproduce this misbehaviour in a brief code segment and post it ? maybe I (or someone else for that matter) can tell you if something is wrong with your code or maybe we can better pinpoint a bug in GTK+ that way. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: cairo surface from GdkPixmap
On Fri, 2005-09-23 at 14:21 +0200, Alexander Larsson wrote: I'm trying to draw a GdkPixmap to a window with a transformation. I can do this using: surface = cairo_xlib_surface_create (gdk_x11_drawable_get_xdisplay (widget-window), gdk_x11_drawable_get_xid (pixmap), gdk_x11_visual_get_xvisual (gdk_drawable_get_visual (widget-window)), width, height); cairo_set_source_surface (cr, surface, 0, 0); I see that we have: void gdk_cairo_set_source_pixbuf (cairo_t *cr, GdkPixbuf*pixbuf, doublepixbuf_x, doublepixbuf_y); But no gdk_cairo_set_source_drawable(). In fact, _gdk_drawable_ref_cairo_surface() which does exactly what I want is a private function. What is the reason for this? The lack of gdk_cairo_set_source_drawable() is basically I didn't need it, so I didn't get around to adding it.. It makes sense and there aren't any issues with it. gdk_drawable_ref_cairo_surface() is a little more sticky. There are two things about it that are tricky: - It's ref_cairo_surface() not get_cairo_surface(). We don't have a lot of precedent for referencing accessors, but you really want to keep this one referencing. Surfaces are not necessarily lightweight ... they can cache pixel data, and we don't want to keep them around when not needed. From C, we have the established naming convention of ref() for this, but what we haven't established yet is that language bindings should rename such functions back to _get() [or should they?] - The behavior in begin_paint()/end_paint() is unexpected ... if you _ref_cairo_surface() with that pair, you get a surface pointing to the backing pixmap. If you draw to it after the end_paint(), then it will be safe (the cairo surface is finished) but nothing will appear. Now that there is cairo_xlib_surface_set_drawable() this could be fixed for X, but not for Win32. So it's probably better to just document the current behavior. Anyways, neither thing is a real stop-objection, but they made me want to leave things private rather than rushing ref_cairo_surface() out to the world when I was first adding the stuff. gdk_cairo_create() and the hypothetical gdk_drawable_set_source_cairo() have considerably less gotcha to them. Regards, Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
