Re: Ideas for new API



On Mon, 2010-06-21 at 11:32 +0100, 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.)

Yeah, i don't think the model/view split makes a whole lot of sense. I
have never used it. If you're really applying the MVC pattern, you do
not derive your models a specific UI library.

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

In agreement there.

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

Already mentioned that I would like to see this. I would additionally
like to see an option for shapes to "shrink wrap" around child objects,
in which case the width and height properties would be interpreted as
minimum values.

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

Oh that would be nice :) It oftent happens that I draw the lines thicker
in for hit testing than the way they actually appear.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]