Re: Porting to GTK+ 3

[Damon Chaplin <damon karuna eclipse co uk>]

On Tue, 2010-06-15 at 17:12 +0200, Brandon Lewis wrote:

> 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.

Yes, I agree with this, though I'm not sure how to fix it.

If we start emitting signals like "bounds-changed" I'm worried it may
have a bad effect on performance. We could check that. (If it is slow
maybe we could only emit the signal as an option.)

I also worry a bit about the update procedure getting into a muddle if
one item is changed in the middle of an update. It should handle it, I
think.


> 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.

You should be able to use "width" and "height" now, to clip to an area.


> 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.

Another reason to add a "bounds-changed" signal, I guess.


> 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.

I did think about porting GtkTextView, but the code is a nightmare!

The trick we used for the Evolution calendar was to show a GtkTextView
widget at the appropriate place to edit the text. That worked OK, I
think.


> 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).

Do you mean using the gtk_paint_XXX() functions? I'm not sure how well
that would work in general - transformations may not work, for example.

Though maybe we could figure out how to do it and include some demo code
that people could pinch if they wanted to.

Damon