Re: A Proposal (why we should have setBold(true))


Subject: Re: A Proposal (why we should have setBold(true))
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed May 31 2000 - 20:29:43 CDT


On Wed, 31 May 2000, Eric W. Sink wrote:

>
> >Then there is the modelessizing of find/replace, spelling, options and I
> >want to add a new feature that would be great for preparing
> >transperencies. A dialog (modeless of course!) with 8 or more
> >user-definable colours selected by radio buttons. Put the dialog next the
> >window and change colours on the fly. Makes producing coloured
> >transperencies a snap! Another non-MS word feature :-)
>
> I'm curious -- which dialogs *should* be modeless?
>
> :-)

All those that make the user experience better and don't break Abiword
:-). The obvious easy candidates are find/replace, spelling, goto-line
and (maybe) Tabs. There is a clear benefit in getting the context for
spelling and having a dialog to tell you the spelling for the squiligy
line as it appears would be useful. Also think it would be useful to be
able to modify some text having been found with the find dialog then press
the next button to find the next occurance.

In the case for "Colours" (I guess we should have En-au text strings :-)
the whole point is to able to change the colour of the text with an easy
mouse movement and click.

>
> I'm cautiously glad that we now have support for modeless dialogs.
>
> Glad? Because most good apps have some dialogs which are modeless,
> and the inability to have them would be a Bad Thing.
>
> Cautious? Because I know that modeless dialogs can open up big
> cans of worms. Modeless dialogs increase the complexity of the
> app. The number of things that can go wrong when a dialog is
> modeless is much higher. The rest of the app requires more
> attention to detail. When a modeless dialog is up, which parts
> of the underlying app are actually active and usable? The answer
> is usually different for each app and for each dialog.
>
> I *like* modal dialogs. They're simple to implement, and they
> correspond to a style of behavior which is very predictable for
> the user.
>

They have their places for sure but in many cases they interfere with
the users experience.

I think Modeless dialogs are great for immediately showing the effects of
a change of state on a document. I'd like to make the Tab dialog modeless
so a user can immediately see the effects of a tab change and adjust them
accordingly. However if this leads to instability in the app then clearly
this will not be used.

> So, when I saw that modeless dialog support had been added, I was
> pleased to have the new capability. When I saw that support starting
> to get used, I was glad. But now it seems to be getting used all
> over the place, and I'm ready to ask:
>
> Where are we going with this?
>

Abiword is a very well designed app that is naturally asynchronous. As
long as the dialog does things which can be done through a View command
it is no different than typing through the keyboard. I think that if we're
smart it will not lead to problems.

> Am I the only one who believes that lots of dialogs still deserve
> to be modal?

Sure some do. Some don't. We are hopefully smart enough which ones should
and should not be.



This archive was generated by hypermail 2b25 : Wed May 31 2000 - 20:30:14 CDT