Preferences (was: UI: "Direct manipulation" is in conflict with "Forgiveness")
Preferences (was: UI: "Direct manipulation" is in conflict with "Forgiveness")
- Subject: Preferences (was: UI: "Direct manipulation" is in conflict with "Forgiveness")
- From: Ondra Cada <email@hidden>
- Date: Thu, 19 Sep 2002 16:17:33 +0200
On Thursday, September 19, 2002, at 02:45 , Bill Cheeseman wrote:
I don't write the guidelines, I just read them....
Yeah, I don't like it either ;)
Nevertheless, what I would recommend is to prepare a preference support
framework. That could save a lot of work, and, what's most important, it
would allow a "metapreference" of user's selection "I want HI-compatible
behaviour" or "I want OK/Apply/Cancel buttons, they aren't HI-compatible,
but I like them better".
Even better it would be if such a framework was available for anyone who
wants it and thus widely used -- so that the appropriate setting would, in
-globalDomain, work for a number of applications.
Now, this is why I am writing: I *do* have such a framework. Along with
the possibility to choose whether the prefpanel is of "immediate" or
"buttoned" type it also automaticaly scans pref panes and makes a panel of
them, it allows for more complicated setups of panes of different
categories, and it allows for codeless preparation of pref panes.
The last feature can be best explained by an example: presume you need
just one string default (named "StringValue") and one BOOL default (named
"BoolValue"). So, you prepare a NIB containing a view with the appropriate
text field and checkbox. You set the textfield's tooltip to "@StringValue@
" and the checkbox' tooltip to "@BoolValue@". You save the NIB as
"@PrefPane@*" (with anything for the asterisk). And that's all.
Now, when you run the app and select Preferences, a panel is automatically
created to contain the view from the NIB (loaded lazily on-demand when
Preferences was selected first time, of course), and the framework code
makes sure that those two widgets show current state of the appropriate
defaults and allow to change them. Had you prepared more such NIBs, there
would be selectable panes in the pref panel. And, depending on other
defaults, there can be no buttons at all, or global (all panes)
Apply/OK/Cancel, and/or, if wanted, local (current pane only)
Apply/OK/Cancel.
Well, now the reason why I am not just putting the thing to Softrak and
providing an URL to download: the framework is written for YellowBox --
needs to be updated -- and depends on many other things (like an automatic
search of all bundles to be loaded into the application); that needs to be
stripped off. Alas just the very now I can't afford to do that for free.
So, I would make that a $10 shareware: is there at least, say, forty
persons here who would pay the fee? If so, I guess I can have it out at
worst in month, probably sooner.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.