Dave, I appreciate your point about preferences. But where does this leave the discussion?
Stéphane at least engaged, even if I didn't understand the logic ("Fine-tuning of Morph position"). You don't like my solution, but offer no alternative nor even address the validity of my complaint.
Even if I don't gain this fix, I'd like to learn something from y'all. I'm evaluating other solutions like whatever happened to that preference which would put the halos *within* the morph's bounds rather than outside..? Oh, maybe it was #haloEnclosesFullBounds except that currently appears to do nothing. Could I fix that to toggle halos being inset rather than outset? At least then the morph would be under the hand for 'pick-up' and 'duplicate'..
On Sat, Mar 31, 2012 at 12:52 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Mar 31, 2012 at 11:16:18AM -0500, Chris Muller wrote:
As far as I am concerned, this change would completely break my code. I am strongly opposed to it.
Ok that's fine. The way it is now breaks my code, so perhaps a preference can resolve our differences.
Eeek! Please avoid adding another preference if at all possible. If different behavior is needed, surely there must be some way to achieve it without breaking backward compatibility. Preferences are great for tailoring look and feel and such, but not for specifying fundamental behavior that affects various subsystems in different ways.
question: "why is my foo window acting wierd?" answer: "it must by the freeble preference, try setting it the other way" question: "ok, foo is working now, but what's up this other window, it's acting wierd now" answer: "oh yes of course, you should set freeble back the other way if you want to do that" question: "huh?!?"
Dave