I've been learning to use Gnome::Canvas for some time now The gnome canvas demo app is very useful, but documentation or tutorials are scarce.
There are some things that puzzle me though, and I apologise for hi-jacking your thread :-) Does anyone have any idea how to: 1. Access the items on a canvas after they've been created? 2. Delete items on a canvas after they've been created? These things are not obvious to me and I really need that functionality (my app runs out of memory otherwise). I'll look more closely at cairo in the meantime. Thanks , Johan On 05/11/06, Peter Lund <[EMAIL PROTECTED]> wrote: > On Sun, 2006-11-05 at 02:07 -0600, Chris Horlick wrote: > > > That is the overview the question that i have is about the overall > > approach to this project. I am thinking of using a GtkImage to display a > > GdkPixbuf which actually holds the contents of the > > workspace(icons,lines,nodes...). The Gtkimage is being displayed inside > > of a GtkDrawingArea, which catches events from the user. > > It's probably better to either use one of the canvases or use Cairo. > > There are several different canvases floating around in the GTK+/Gnome > universe -- they take care of handling input/selection events, redraw, > scrolling, and to a certain extent also accessibility. > > The theory is that you just say that you want an icon widget or a label > widget or whatever at position (x,y) and the canvas takes care of the > rest. Some of the canvases can also handle arbitrary Bézier drawing > (would be nice for the connections between the icons) with antialiasing. > > I personally think, however, that it is much easier to implement it > without a canvas, and do the event handling/scrolling/drawing oneself, > just like you are intending to do. > > If you go that route you will be VERY pleased with cairo -- you can do > antialiased drawing, Bézier paths, alpha blending, rotated and masked > images, etc... It is surprisingly easy to write something that looks > gorgeous. > > If you are (very) lucky it will even be accelerated on today's > hardware/software. > > On the other hand, using a pixbuf will also work and it will probably be > faster to implement because you already know the concepts involved. > > > First i would like to know if this is the correct approach according to > > the official GTK way. I am curious how to add one of my icons to the > > back pixbuf. Also, what are my options to actually allow the user to > > move the icons. Currently i am looking at using my own set of functions > > that check to see if the user clicked one of the icons already in the > > workspace then take appropriate action. > > That's how you do it (unless you use one of the canvases). > > As you can probably guess, I kinda like Cairo, but maybe you should wait > a bit before using it. I don't know. It depends on your ambition, > skill level, learning speed, and on how much time you are willing to > spend. > > If you use Cairo, the best way to handle the mouse seems to me to be: > > 0) have a high-level data structure that describes the layout. > > 1) have a hit test data structure that describes the "hot" areas in the > window in window coordinates. Each area points to an icon (or perhaps a > line) or something else that's interesting. > > 2) the mouse event handler(s) throws coordinates into the data structure > in one end and sees what comes out the other end (nothing or a > prioritized list of icons, perhaps). > > 3) the data structure starts out being empty. It gets filled in by the > expose handler. This means that there is always a one-to-one > correspondence between what's on the screen and what the "hot" areas are > (or as close as one can get). The expose handler has to know how to go > from the high-level data structure to window coordinates anyway. > > You can optimize the updating of the hit test data structure later, if > necessary. The hit test data structure can be a simple list of > rectangles or a simple tree or (if you get fancy) an R*-tree. I'd go > for the simple list... > > This strategy decouples the high-level data structure from the mundane > details of the layout, it ensures that knowledge of how to translate > between the high-level data structure and the coordinates is in one > place, it ensures that the mouse handler doesn't have to know anything > about the high-level data structure, and it makes it easy to add extra > little doodahs to your window (such as transparent overlays with extra > information about whatever is closest to the mouse, animations and size > changes when the mouse is over an icon, fish eye lenses, etc.). > > http://cairographics.org/ > http://cairographics.org/samples/ > > (note that these samples change the coordinate system before drawing: > "The user space is the unit square ( (0,0) - (1, 1) ), this user space > is initialized byt [sic] the snippet_normalize function, which also sets > a line_width of 0.04. The snippets are meant to be short, and easy to > understand" -- you probably don't want to do that.) > > http://macslow.thepimp.net/?page_id=23 > > (if you try macslow's code you probably won't get the proper transparent > windows effect because that requires using a compositing window manager > -- but the screen shots are beautiful) > > http://gnomejournal.org/article/34/writing-a-widget-using-cairo-and-gtk28 > http://gnomejournal.org/article/36/writing-a-widget-using-cairo-and-gtk28-part-2 > > (how to build a relatively simple widget from scratch that draws with > cairo -- implemented in C) > > http://www.pygtk.org/articles/cairo-pygtk-widgets/cairo-pygtk-widgets.htm > http://www.pygtk.org/articles/cairo-pygtk-widgets/cairo-pygtk-widgets2.htm > (the same widget example, this time in Python) > > If you decide to use cairo AND you create your own widget AND you want > to implement scrolling, please call for help on the list again. There > are some non-obvious things to handle there. Actually, scrolling > involves a lot of non-intuitive stuff in GTK+ in any case, unless you > are just using prebuilt widgets. > > -Peter > > _______________________________________________ > 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
