gnome canvas and gtk menu questions

I'm porting an old application I wrote to gnome/gtk from tcl/tk.
(It's lavaps, see <> 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).

(If it matters, I'm running on a pretty stock Redhat 9 system, i.e.,

Canvas Questions (and Suggestions)

- I don't understand the ordering commands.
gnome_canvas_item_raise_to_top() and
gnome_canvas_item_lower_to_bottom() are clear and useful, but
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)?

(I looked at the implementation of raise/lower in the library.  They
actually have to go to some work to implement the positions stuff.
But I don't know glib/libgnomecanvas well enough to easily write the
interface I want.)

- 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-
(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?

[Again, I gave up on this and just did my own tracking of in at the
Canvas level.  But hardcoding this policy seems incorrect to me.]

- 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?)

[I got around this by not doing any binding on blobs and just doing my
own dispatching via gnome_canvas_get_item_at(), but it seems like a
shame to have to do that.]

- I miss the smoothed polygons from Tk's polygon option.

Did anyone add smoothed polygons, or should I?

(I *do* appreciate that you can actually edit the pointlist of an
existing polygon in gnomecanvas, while in Tk I always had to delete
and recreate it!)

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
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

- 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 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.

   -John Heidemann

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]