Ideas for new API

[Damon Chaplin <damon karuna eclipse co uk>]

Here are some of the things I've been thinking about possibly changing
for any new GooCanvas API. I'd like to simplify it, getting rid of any
complicated stuff that isn't particularly useful. But I might add one or
two features if they are very useful and fairly easy to do.

Possible big API changes:

o Get rid of the model/view option.
   The model/view stuff made the code overly complicated. It would
   still be possible to use the canvas as a view if needed. (Though
   you will need to write your own canvas items and models.)

o Get rid of the interfaces, and use regular classes instead.
   Using interfaces is a bit fiddly, and not that useful. They are
   a bit slower as well.

o Get rid of cascading style properties.
   The code for these is a bit complicated, and they're not that
   useful. We'd replace them with simple GooCanvasStyle objects.

o Allow all items to have children.
   This is a handy feature that I would have liked a few times.

I've actually done most of the work for the first 3, though I'm not 100%
decided on them. (They didn't require many changes to the demo code,
so most GooCanvas code would be easy to port. Unless you actually used
the model/view stuff or interfaces or cascading style properties!)


Possible smaller API changes:

o Add a tolerance setting for line widths, so clicking on narrow
  lines can be made easier.

o Add an "unscaled-line-width" where the line width doesn't grow
  as the canvas is scaled. (Though it should probably shrink if
  the canvas is shrunk.)

o Change the item XXX_new() functions? Bindings people often
   complain about them. (Could mean lots of porting work though.)

o Use GInitiallyUnowned as the base class.
   That is the normal thing now, though I don't think it makes a
   huge difference with GooCanvas.


Thoughts?

Damon