Re: Modal dialog alternatives?
Re: Modal dialog alternatives?
- Subject: Re: Modal dialog alternatives?
- From: m <email@hidden>
- Date: Thu, 16 Jun 2005 14:31:43 -0700
On Jun 16, 2005, at 9:16 AM, Andy Bettis wrote:
The point I was trying to make is that guidelines used to be
suggestions for how to improve your UI, which could be disregarded
if you had a good reason for doing things differently.
They still are. But my point is that if you want to swim upstream,
you should expect some difficulty. Apple is correct to focus on
making what's in the guidelines easy to do, not on making everything
that is conceivable easy to do. If you disagree, you should file a bug.
Are you surprised that Cocoa doesn't go out of its way to support
things that are proscribed by Apple's Guidelines?
I'm surprised that something that's already in place (for alerts,
etc.) isn't finished off properly in accordance with the API
documentation. This stuff isn't rocket science.
You might also be surprised that the inability to nest modal gets
very little mention here. Draw your own conclusions. Perhaps you
truly have a unique situation which cannot be solved any other way...
BTW, which API are you referring to? NSAlert for example doesn't
support nested alerts does it?
But anyway...
As I understand it, you are using modal dialogs to implement the
"detail" part of a "master-detail" type of interface and this is
leading inevitably to nested modal dialogs. Yes?
Consider implementing your "master-detail" interface in a single
window like so:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaBindings/Tasks/masterdetail.html#//apple_ref/doc/uid/
20002090-119367>
That would solve your problem and give you a cleaner interface to
boot.
This is just a modeless dialog stuck to the bottom of the window,
as I've explained elsewhere.
The details matter (I guess that's kind of a pun, sorry). The master-
detail design clearly associates the editor with the doc. The
modeless design suffers from a potential document<->editor disconnect
in the mind of the user.
Your other objections as far I was able to understand them are:
1) Real estate: There need not be any real estate compromise if
nothing is being edited (shrink the editor down when not editing). In
any case the benefits probably outweigh the costs.
2) Document state that is transiently invalid: I don't understand
this. You can enforce document consistency by only changing the
document once the edit is validated. Am I missing something key here?
Cheers,
_murat
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden