Re: Porting to GTK+ 3

[Brandon Lewis <brandon collabora co uk>]

On Tue, 2010-06-15 at 10:47 +0100, Damon Chaplin wrote:
> On Sun, 2010-06-13 at 15:26 +0200, Murray Cumming wrote: 
> > On Fri, 2010-06-11 at 09:19 +0100, Damon Chaplin wrote:
> 
> > Shall we start a branch for this?
> 
> We could start a branch. I've removed most of the model/view split in my
> code here.
> 
> The problem is agreeing on what should be in any new API...

I wouldn't mind having a discussion about that. I think it's really
great that you can apply arbitrary transformations to goocanvas items,
but to be honest I don't use that feature very often. In pitivi we use
GooCanvas to maintain a hierarchy of mostly-rectangular objects, and I
find that are some really simple, but common, use cases which GooCanvas
doesn't address very well.

1) For example it's unnecessarily complicated to create a
general-purpose text object with a background shape whose size depends
on the text itself.

2) It's also unnecessarily complicated to create a text object which
does not draw outside fixed rectangular bounds. You have to resort to
using the clipping path property, which is extremely awkward not at all
efficient. Or you can define a custom canvas item, which is even more
complicated.

3) It's unnecessarily difficult to keep different kinds of objects
aligned to each other. At the core of this issue is that you are forced
to use the transform API as the only interface common to all items, but
you get no notification from an item when its bounds are changed through
this interface. If you watch specific properties for changes, you have
to special case each type of item because there's no common property
interface.

3) There's no facility within GooCanvas itself for handling text-input.
Often I use GooCanvasText items to proxy for a text property somewhere
else, but to allow for editing that text I have to bring up an external
dialog. It would be really slick to have an editable text object that
displays a cursor responds to keyboard events.

4) It's really hard to draw gdk shapes onto a canvas, or to create
canvas items that resemble GTK widgets. So far I've had to override the
expose method and use gdk routines directly. It'd be nice to have a box
primitives that draws a box in into the canvas using the gtk theme
routines, with a given state and shadow type. This would allow one to
create canvas items that resembled the appearance of existing widgets
(including buttons, sliders, etc).

> 
> 
> > > The only small API change request is the get_bounds() function
> > > signature. And I still don't really think that is worth doing.
> > 
> > This seems fairly harmless. May I apply it?
> > https://bugzilla.gnome.org/show_bug.cgi?id=556145
> > "Move child API into GooCanvasContainer"
> 
> I'm tempted to allow all items to have children, since sometimes this
> can be handy, to quickly add things like drag handles. (QGraphicsView
> allows this, I think.) I'm not sure yet though.

I really, really, really want this. Please please please please please
(with a cherry on top).

> 
> 
> > And I still believe that this is the right thing to do (The goocanvasmm
> > API already does this):
> > https://bugzilla.gnome.org/show_bug.cgi?id=555097#c33
> > "Common interface to position and resize items"
> 
> I still don't really like this. If you want to add those properties to your
> own items you're welcome, but I'm not sure about forcing everyone to do that.
> 
> Plus we already have the transformation matrix which provides a common
> interface to position items.
> 

I think you're putting the needs of people writing custom canvas items
over the needs of the majority who merely want to create objects that
are compositions of graphics primitives. Moreover, I don't really see
why it would be more difficult for the author of a custom item to handle
x, y, width, and height, properties since they have to write a paint
method as a function of rectangular bounds anyways.

Moreover, as is pointed out in the bug report, the transform API is not
equivalent to the x, y, width, and height properties. Setting scale can
have an adverse effect on rendering of borders and text. In other words,
the transformation API provides an important but distinct functionality.

Having a common interface to set the native position and size of objects
is useful, and I don't think it really matters what the shape is. I find
it rather annoying that some items (like GooCanvasEllipse) provide an
alternative but equivalent interface -- because it means re-writing
application code to change presentation -- while other elements, such as
GooCanvasText, don't give you this control at all (forcing akward usage
of th clipping path property, or even worse having to write ac custom
item). Even for more complicated cases, such as GooCanvasPolyLine, they
could still exist as read-only attributes, or they could be interpreted
as a rectangular clipping region (with -1 defaulting to 'native size').

--Brandon.