Re: [gtk-list] Re: (Tricky?) questions about GTK widget hierarchy and GNOME canvas

[Paul Bunyk <paul pbunyk physics sunysb edu>]

Havoc and Federico, 

thanks alot for your replies! 

Federico Mena Quintero writes:
 > Normally you should not need this, though.  The canvas is a display
 > engine.  It is not designed to work as your primary data structure.
 > The idea is that you keep your own data structures, and they keep
 > pointers to the canvas items that form their visual representation.

I actually hoped I could play a dirty trick and use the datastructure in
Canvas as my primary work structure (with whatever special I need
simply attached to objects), now I understand that it would not
work... Well, I've typed
	typedef struct {...} CIF_Polyline; 
couple times in my life, it will not hurt to do it once more... :) 

Thanks for your comments about affine transforms, I'll keep that in
mind. 

Yours,

Paul

Federico Mena Quintero writes:
 > >  It seems that GTK API allows that, but will the widget behave as
 > >  expected (e.g., can I have two "views" of that widget on the screen
 > >  simultaneously).
 > 
 > Nope.  A widget can only have one parent.  You have to use separate
 > widgets for each page.
 > 
 > >  In my library I have cells (what they call "cell masters" in CAD) and
 > >  they can be used in definitions of other cells (each such use is a
 > >  "cell instance"). I thought about reading each cell into its own
 > >  GnomeCanvasGroup (with natural instantiating of a sub-cell's Group
 > >  within a higher-level cell). For cell editing I want to flatten a
 > >  Group one level into a Canvas (with all sub-cells/Groups visible while
 > >  only sub-Group as a whole is manipulated).
 > >  
 > >  This possibility seems to be mentioned in GnomeCanvas.h:
 > >  
 > >   * Consider a circuit editor application that uses the canvas for its schematic
 > >   * display.  Hierarchically, there would be canvas groups that contain all the
 > >   * components needed for an "adder", for example -- this includes some logic
 > >   * gates as well as wires.  You can move stuff around in a convenient way by
 > >   * doing a gnome_canvas_item_move() of the hierarchical groups -- to move an
 > >   * adder, simply move the group that represents the adder.
 > >  
 > >  BUT: Can we have several identical adders on one canvas? 
 > 
 > Yes.  They are just different canvas items.  They are separate Gtk+
 > objects, too, just like widgets; a canvas item can only have one
 > parent group.
 > 
 > >       Can we have several identical adders on several canvases?
 > 
 > Yes, but again, they have to be different objects.
 > 
 > >       Can they be rotated/mirrowed/etc. independently?
 > 
 > Yes.  Each canvas item has its own independent affine transformation.
 > 
 > Caveat:  affines and the antialiased canvas are rather broken right
 > now.  I am fixing it in the CANVAS_CLEANUP branch of gnome-libs; if
 > you would like to keep track of that work, please get that branch from
 > cvs as well.
 > 
 > >      How do I create a CanvasGroup without a parent then attach it to
 > >  whatever parent(s) it is instantiated in? 
 > 
 > You can't.  Canvas items must always have a parent.  This means you
 > must create your item hierarchy in a top-down fashion.
 > 
 > >  And, finally the last easy one: How to I walk through all objects
 > >  attached to a Canvas?
 > 
 > Eeewww.  You could walk the group->item_list structures, but that is
 > ugly.
 > 
 > Normally you should not need this, though.  The canvas is a display
 > engine.  It is not designed to work as your primary data structure.
 > The idea is that you keep your own data structures, and they keep
 > pointers to the canvas items that form their visual representation.
 > 
 >   Federico
 > 
 > -- 
 > To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null