Radio Button and Checkbox API

[Francisco Tolmasky]

I've just committed the beginnings of radio and checkbox buttons and
wanted to quickly discuss the API since it is a bit different from
Cocoa's. The main issue arrises from the fact that Cappuccino doesn't
have cells and that in Cocoa checkboxes and radio buttons are just
normal buttons with their images/alt. images set to radio/checkbox
images.

In Cappuccino we decided to stray from this for a number of reasons:

1. As stated before, we don't have cells so we can't and shouldn't
make use of NSMatrix to control the interaction between radio buttons.
2. In Cocoa, there is no reasonable way to ask a button whether it is
no a radio or checkbox -> the closest thing you can do is [[button
image] name] isEqualTo:@"NSCheckBox"], which is not the most elegant
thing in the universe.
3. In Cocoa, you can't have a checkbox or radio with an image, since
the image is already in use to show the actual checkbox/radio UI. In
other words, [myCheckBox setImage:someOptionImage] will make the
checkmark UI go away.

So, what we've done is create the CPRadio and CPCheckBox classes. This
allows us to make them separately themable from normal buttons, and
allows us to actually ask a button if its a radio/checkbox
(isKindOfClass:[CPCheckBox class]).

Creating a checkbox is easy enough:

checkbox = [[CPCheckBox alloc] initWithFrame:aFrame];

That's basically all there is to it. Radio buttons are very similar,
the key difference is the introduction of a new class CPRadioGroup,
which defines which radio buttons are part of the same group:

[myRadioButton setRadioGroup:aRadioGroup];

Every radio button receives a unique radio group by default (so if you
do nothing further, they will all behave independently), but you can
use an existing radio button's group with other buttons as so:

button1 = [[CPRadio alloc] initWithFrame:aFrame];
...
button2 = [[CPRadio alloc] initWithFrame:aFrame radioGroup:[button1
radioGroup]];
...
button3 = [[CPRadio alloc] initWithFrame:aFrame radioGroup:[button1
radioGroup]];
...etc...

Here, all the radio buttons will act "together". [[button1 radioGroup]
allRadios] returns every button that's part of this group, and
[[button1 radioGroup] selectedRadio] returns the currently selected
option.

[Andrew Burkhalter]

I've looked this over and used within my own proof-of-concept project and all works as advertised and looks quite nice.  Thanks for tackling this!

My only comments/questions are minor:

* For both radio and checkbox, the radio-bezel and radio-bezel-selected images repeat behind the entirety of the title.  Investigating the DOM, i can easily fix an instance in place by setting 'background-repeat' to 'no-repeat' as opposed to initial which is the default in a recent WebKit nightly.  Investigating a bit further, I see ThemeDescriptors.j creates a CPColor using the class method "colorWithPatternImage" which as expected sets _cssString to something that would lead to a repeated background.  Am I missing something obvious or shall I log a bug against this?

* I don't have major comments about abandoning a more Cocoa-like API, but having looked in ThemeDescriptors.j for example use and having overlooked the "Designated Initializer" comment within CPRadio.j, I'd vote for some liberal copy paste of this email to steer future users that haven't seen this post towards radioGroup usage and why it's important and why abandoning the Cocoa-way makes more sense here.  I can add a bug for this as well, if desired.

Thanks!

Andrew

[Martin Häcker]

> 1. As stated before, we don't have cells so we can't and shouldn't
> make use of NSMatrix to control the interaction between radio buttons.
> 2. In Cocoa, there is no reasonable way to ask a button whether it is
> no a radio or checkbox -> the closest thing you can do is [[button
> image] name] isEqualTo:@"NSCheckBox"], which is not the most elegant
> thing in the universe.

I didn't have time to do this myself, but I think we could have a
liberal look at what the iPhone API does as it also abandons Cells (as
far as I know).

Doing that may allow us to stay more compatible in design with cocoa -
even if we have to go other ways in implementation.

Regards,
Martin

[Emanuele Vulcano]

The iPhone has no checkboxes at all; on/off switches are used instead.
— ev

Il giorno 19/mag/2009, alle ore 10.18, Martin Häcker
<mhae...@mac.com> ha scritto: