From: Brian G. <bri...@ea...> - 2012-10-19 00:46:08
|
On Oct 18, 2012, at 3:19 PM, Simon Geard wrote: > On 18/10/12 16:39, Brian Griffin wrote: >> On Oct 18, 2012, at 8:27 AM, simon wrote: >> >>> On 18/10/2012 14:34, Peter Spjuth wrote: >>>> On Thu, Oct 18, 2012 at 1:20 AM, Simon Geard<si...@wh...> wrote: >>>>> I've updated the TIP to include an option to specify how the coordinates >>>>> should be interpreted >>>>> so that the change is explicit. >>>> Please make it "-option value" style since all other options have that format. >>>> I.e. >>>> -somename bbox >>>> -somename chord >>>> (I can't think of a name for the option for the moment) >>> As well as creation I'm also concerned with the action of itemcget. If I >>> adopt the "-option value" style then itemcget ... -somename would return >>> either 'bbox' or 'chord' which is information about how the arc was >>> created whereas it should be returning information about the arc itself. >>> >>> For a canvas '.c' with an arc item 'a1', created using either -bbox or >>> -chord, I'd like the following behaviour: >>> >>> $c itemcget a1 -chord to return the start/end points of the chord >>> $c itemcget a1 -bbox to be a synonym for '$c coords a1' >>> $c itemcget a1 -height to return the height >>> $c itemcget a1 -start to return the start angle >>> $c itemcget a1 -extent to return the span angle >>> >>>> /Peter >>>> (I could even imagine a third value for such an option for cx/cy/rx/ry >>>> based positioning) >>> There are many options for arc creation methods. My intention here is to >>> add a simple one to tk in such a way that other people aren't inhibited >>> from extending it further in the future as well. That is why I'd like >>> -start and -extent to be invalid if -chord is used and -height to be >>> invalid if -bbox is used. >> If you want to start conditional-izing a bunch of properties, then I agree with Joe English that this requires a new item type. I wouldn't want to have to start putting conditional tests in my code to check for the legality of some options based on other options; that gets really messy really fast. Conditional code based on an item type is already the standard pattern here. >> >> -Brian >> > I don't think I understand your objection here. All I'm proposing is > that to use the new construction the user would use e.g. > > $c create arc $x1 $y1 $x2 $y2 -chord -height $h -style arc > > Where is the conditional-izing? What tests would you have to put in your > code? The user knowns what they want to create so they use the > appropriate syntax. There are times I have to write code that does introspection, for example, to passivate a whole window and reconstruct it later. To dump a canvas and reconstruct it later will require additional conditional code to reproduce the arcs under this proposal, rather then a simple dump and replay. The documentation too will require additional if-then-else description that just wouldn't be necessary given a new item type. -Brian |