Re: Ideas for new API

[Richard Gipps <rgipps netspace net au>]

Damon,
            I have used the model/view option when creating my own 
GooCanvas Classes (models/views) because I thought it may be useful in 
the future rather than because I specifically needed a model/view split. 
If this functionality is removed will writing custom GooCanvas items 
still be fairly straight forward?

When you say change the item XXX_new() functions do you mean get rid of 
them so that one has to use g_object_new( ) or do you have another 
cunning plan?

Richard.

item XXX_new() functions?


On 21/06/10 20:32, Damon Chaplin wrote:
> 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
>
>
> _______________________________________________
> goocanvas-list mailing list
> goocanvas-list gnome org
> http://mail.gnome.org/mailman/listinfo/goocanvas-list
>
>