Re: gnome canvas and gtk menu questions

[John Heidemann <johnh isi edu>]

On Thu, 19 Jun 2003 20:02:30 PDT, John Heidemann wrote: 
>I'm porting an old application I wrote to gnome/gtk from tcl/tk.
>(It's lavaps, see <http://www.isi.edu/~johnh/SOFTWARE/lavaps/> for
>details and the tcl/tk code.)  As a result, I've got some questions
>about gtk.  Some things that were easy in Tcl/Tk are now hard (or at
>least hard to me).
>...

Thanks to the folks who replied to my mail.

Here's the follow up:

>Canvas Questions (and Suggestions)
>----------------------------------
>
>- ...
>gnome_canvas_item_{lower,raise}() are not very useful because they
>work in "positions".  I don't know the relative positions of objects
>(there doesn't seem to be an API to extract your stacking order).  An
>API where you specify positions relative to some other object would be
>much more useful, IMHO.  For example, Tk's says "lower item X below
>other item Y".
>
>Should we either export an item's stacking position (to make
>gnome_canvas_item_lower useful if painful), or add APIs that allow you
>to do relative position?  (Perhaps
>gtk_canvas_item_lower_relative(GnomeCanvasItem *item_to_lower,
>GnomeCanvasItem *superior_item), where after it, item_to_lower is one
>stacking step lower than superior_item)?

No one had suggestsions, so I implemented my own relative lower.
See <http://bugzilla.gnome.org/show_bug.cgi?id=115689> for the
proposed code.

>- I was supprised that I can't do mouse tracking correctly: once I
>click in a polygon, I never get notification about entering other
>polygons.  Apparently this is a "feature" of libgnomecanvas-2.2.0.1
>(see the code in gnome-canvas.c:pick_current_time).
>
>Is it really a good idea to embed this kind of policy in a generic
>library?  Can it be made optional?

No comments, but I was able to work around it.

>- I want events (such as mouse-down/motion) to be emitted to blobs
>first (if there's a click in a blob), or to the canvas in general (if
>not).  I assumed I could use standard gtk signal ordering to do this
>handling, but calling g_signal_connect_after(canvas, "event"...)
>followed by g_signal_connect(polygon, "event"), but this doesn't work:
>I always get the canvas event triggered first, then the polygon event.
>
>Is there a way to get canvas events to trigger after canvas item
>events?  (Perhaps g_signal_connect_after only applies to what
>currently on the event stack?)

Again, no comments, but I was able to work around it.

>- I miss the smoothed polygons from Tk's polygon option.
>
>Did anyone add smoothed polygons, or should I?

[No comments.]


>General Gtk Questions (and one suggestion)
>------------------------------------------
>
>- I want to change the color of a menu item, all the time, to indicate
>something.  I tried calling gtk_widget_modify_base(menu_entry,
>GTK_STATE_NORMAL, &my_gtk_color), but that didn't change the menu
>color when the menu is first rendered.  In fact, I tried all
>combinations of gtk_widget_modify_{base,fg,bg} and
>GTK_STATE_{NORMAL,ACTIVE,PRELIGHT,SELECTED}.  The only one that caused
>any change in rendering was _base with _SELECTED, which made things
>the correct color when the mouse higlighted the menu entry.
>Unfortuantely, I want it to *always* have that color.
>
>Any suggestions about how to change the color of a single menu item?
>Is this a style/theming problem?  (I want to control just one menu
>entry.  I'm happy to let theming work for all the other parts of the
>menu.)

[see next one]

>- I also want to change the *text* of the menu item dynamically.
>Unfortunately, I don't see any API to change the label of an existing
>menu entry.  (I would guess gtk_menu_item_set_label.)
>
>Is there any API to change an existing menu entry?  (Grepping the
>documentation for gtk_menu.*set.*label didn't find anything.)  Do I
>have to delete it and recreate it (yuck!)?

I fixed both the menu color and font by directly accessing the
underlying label and setting markup text as suggested by 
Michael Meeks and John (J5) Palmieri.
This suggestion does what I want, although I'm concerned about
portability to Mac/Windows versions of Gtk that don't have a label
under their menus.

>- I want to make my canvas elastic, so that the user can resize it.
>The relevant API is gtk_window_set_resizable() or gtk_window_set_policy().
>The manual lists gtk_window_set_policy() as depricated,
>presumably because not all the 8 combations of the parameters make
>sense.  It says:
>
>	Neither of the two suggested window policies set the
>	allow_shrink parameter to TRUE. If allow_shrink is TRUE, the
>	user can shrink the window so that its children do not receive
>	their full size request; this is basically a bad thing,
>	because most widgets will look wrong if this
>	happens. Furthermore GTK+ has a tendency to re-expand the
>	window if size is recalculated for any reason. The upshot is
>	that allow_shrink should always be set to FALSE.
>
>But that's *exactly* what I want to do.  I'm happy to resize the
>embedded canvas widget.
>
>Any suggestions on what I should do?  Currently I'm just using the
>depricated gtk_window_set_policy().  I hope it doesn't go away.

[I just kept my work-around.]


Thanks to everyone involved for the quick and cogent suggestions.

   -John Heidemann