Re: Adding a new type of NSButton
Re: Adding a new type of NSButton
- Subject: Re: Adding a new type of NSButton
- From: Andy Lee <email@hidden>
- Date: Thu, 26 Jun 2008 10:51:24 -0400
On Jun 26, 2008, at 9:29 AM, I. Savant wrote:
I'm envisioning a scenario where, even if there are a dozen such
buttons, they probably all connect to an action in the same controller
I agree in the hundred-buttons/one-action case it's clearly the path
of least resistance to add a line or two to the action method. But I
didn't know if that was the OP's case, which is why I tried to find
out what he was actually doing.
(By the way, I'm glad Hamish mentioned those buttons on web pages that
dim when you click them so you won't click them again. Other than
that, the only example I could think of for this kind of one-way
button was a bubble-wrap game where every bubble is implemented as a
button.)
Imagine I had never seen radio buttons but figured out that I needed
that functionality for one window in one app. I might simply put
logic in my action method to turn off the previously selected radio
button when a different one is selected. I might decide not to
engineer a control that does this for me, but not for MVC reasons --
more for reasons of premature generality.
(or if they don't, it's easy to make them do so, to funnel all this
special behavior through one action that maybe calls others as
necessary).
How would the central action decide what other action to call? A
switch statement?
Personally, I wouldn't subclass NSButton for just one button or
even, say, four buttons.
It would just feel like going against the grain somehow;
subclassing controls should
be pretty rare.
This is why - I agree 100% here. Additionally, I *love* simplicity
and elegance. I think it is complicated and quite inelegant to make a
custom control in the scenario I mentioned.
It would only be a very slightly custom control -- a couple of lines
of code -- using existing behaviors for drawing, actions, and
enabledness. As much as we'd prefer not to, we do sometimes subclass
other UI classes, often with one-line overrides like -isOpaque or -
canBecomeKeyWindow where there isn't a setter to set that behavior.
I'd put this in that category, and not in the category of, say, a
skinnable figure-8-shaped 3D slider.
--Andy
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden