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