From: simon <si...@wh...> - 2012-12-06 12:55:04
|
On 06/12/2012 01:00, Joe English wrote: > Simon Geard wrote: >> Joe English wrote: >>> [...] >>> On top of that, "-height" has magic behavior in that it cannot >>> be read and cannot be set to zero. (This magic behavior was >>> apparently proposed in order to address problems related to >>> introspection. Alas, it only exacerbates those problems.) >> True, but the intention is that it is a creation parameter and not part >> of the dataset that defines the arc. I don't understand the how >> introspection problems are exacerbated, [...] > You now have two different kinds of "arc" items in which > the coordinate list and other options mean different things, > and since [$c itemcget $arc -height] always returns 0, > there is no way for application code to tell the two apart, They aren't two different kinds of "arc" - they are the same. It is true that on creation the coordinate list is used differently if -height is specified, but the underlying geometric object that is created is the same. Why should it be necessary to distinguish between them? > For example, it would not be possible to write a general-purpose > routine that converted [canvas] widget contents to SVG. Why not? Any code that converted a canvas widget to SVG would be completely unaffected by this change. > In fact, even the code in the Example section of the TIP, > which purports to serialize and deserialize arc items, > will not work with the TIP as currently specified. If that is the case then the wording of the TIP is wrong and I'd be grateful if you you point out where so that I can update it. I have posted an example that demonstrates serialization so support for it is practical and not theoretical. Simon |