Re: A New Keyhole Type!

Hendrik Schober <[email protected]> wrote:
> White Wolf <[email protected]> wrote:
> > [...]
> > > Our Open and Save dialogs are still modal.
> >=20
> > I can see no technical reason why they should be [...]
>=20
>   I can. Suppose they were modeless. Suppose a=20
>   user opened the "Save as" dialog. Suppose they=20
>   then open the "Open" dialog, open a document,=20
>   and then go back to the "Save" dialog and hit=20
>   "OK". What is going to get saved?

What is in the open window.  Or nothing, if that save as...
dialog is designed that way.

> Who is writing the code that assures this?

Anyone who writes the system.  On the focus being received
(not on the OK button) the dialog can check if it should
warn the user about changes or not.

> Who is testing?

Testers.

> And,  worst, who is going to explain this to the users?=20

The software and its help file, just like anything else.

> > > Unconditionally saying modal dialogs are "bad" and putting
> > > the epithet, "keyhole," on them seems pedantically
> > > disconnected from reality to me.
> >=20
> > I am still waiting for convincing arguments.=20
Preferrably facts and
> > figures, because I do not think that I am such an
important or
> > influential person that my work experiences or ethical
standards would
> > change facts.
>=20
>   Sigh. I looked at OE, because that's what I'm=20
>   using for writing this mail.

OE is a 10 years old design, not maintained anymore for
years.  I would not try to draw any conclusions about it.

> In the first menu
>   item, "Print" seems to be modal. I agree with=20
>   this decision for the same reasons as I agree=20
>   with making "Save" modal.

I do not see any sound technical reason why they *must* be
modal.

> Another prominent one=20
>   is the account dialog. (Whatever it's called in=20
>   non-German versions; I mean the one you manage=20
>   your email accounts with.) I wouldn't want to=20
>   try to change account settings while users are=20
>   allowed to hit the "Receive" buttons.

And why not?  Because that dialog is *not* built properly,
it is *not* communicating with the rest of the system using
messages, but it is fiddling with the data structures
directly.  Bad design.  A simple observer would solve the
issues of distributing changes to the interested parties,
and a simple copy-before-start (or copy-on-write) would
ensure that nobody will change the data once a send/receive
tasklist-item started to use it.  I mean that data, what it
started to use.

> And, again,=20
>   neither would I want to explain the logic that I
>   I settled for.=20

It is your decision.  It is the customers decision which
software they will buy.  On built on "economical excuses",
or one built for usability.

>   Of course, there's dialogs that seem to be modal=20
>   without a good reason. I don't know whether there=20
>   is a real reason they're modal or not, but I am=20
>   sure that many of them could be rewritten to be=20
>   modeless without too much hassle.

Depending how bad the design is.

> However, I have=20
>   to agree with Frank, that simply dismissing the=20
>   whole idea of modal dialogs is throwing out the=20
>   baby with the bathtub.=20

I don't think that anybody wants to dismiss them. :-)  There
can be cases, when they are mandatory; and there can be
cases, when they are an acceptable choice.  Let's just think
about the print-dialog.  In MS-Office programs it is no
excuse that the document needs to be duplicated if someone
edits it during printing: they *can* already do that with
the background printing!  So why is the print dialog modal...?

Attila=0A=0A_______________________________________________________________=
________=0A[freemail] extra 1GB-os postafi=F3kkal, =D6nnek m=E1r van? http:=
//freemail.hu=0A=0A