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
