Don Hopkins wrote:
Good point! That should be possible, I think. The PieItem objects are
not widgets, just objects that are called with a context to draw
themselves with, so just the PieMenu and PieMenuDrawingArea classes
would have to be reworked a bit. It's the mouse tracking and grabbing
stuff that would be different. There should be a way to factor that
stuff out so the same class can draw into its own window or a cairo
context owned by another window. Presumably it would have to hook into
some kind of cairo context based drawing handler, so it knew when to
draw itself, instead of responding to window expose events.
With my own custom controls I've taken a very simple approach where I
added a render_to_cairo() function on each one that takes a cairo
context and an x&y co-ordinate as arguments.
And what
about handing mouse events inside a cairo context and grabbing the
cursor from your application during popup? That's always where the
rubber meets the road.
*nod*
Can get heap big ugly very quickly.
There is consensus on using cairo to render a gtk widget, but when
rendering a widget onto a cairo surface one is still pretty much on
one's own.
In my own case I wanted to take advantage of Cairo's transformation
capabilities in order to implement a zoomable user interface.
Ended up with a CairoCanvasLike derived from gtk.DrawingArea which acts
as a container for my own 'native-cairo' widgets [1], with my canvas
taking over window management duties such as event-forwarding, clipping,
coordinate transformation and redraw handling.
[1] Kind of stupid considering that we already have gtk widgets that are
already being rendered by cairo but I could never bring myself to
implementing a pixbufblit strategy for rendering gtk widgets such as the
experimental cairofirefox uses :-P
- antoine
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
