Re: canvas, cairo and/or pixbufs? (was Re: Application Approach)
- From: "Johan Kohler" <johan kohler gmail com>
- To: "Peter Lund" <firefly vax64 dk>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: canvas, cairo and/or pixbufs? (was Re: Application Approach)
- Date: Sun, 5 Nov 2006 18:36:56 +0200
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
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.
On 05/11/06, Peter Lund <firefly vax64 dk> 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
If you are (very) lucky it will even be accelerated on today's
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
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.).
(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.)
(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)
(how to build a relatively simple widget from scratch that draws with
cairo -- implemented in C)
(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.
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
] [Thread Prev