Subject: Re: List Dialog compromise
From: Thomas Fletcher (thomasf@qnx.com)
Date: Thu Nov 23 2000 - 09:30:27 CST
On Fri, 24 Nov 2000, Martin Sevior wrote:
>
>
> On Thu, 23 Nov 2000, Thomas Fletcher wrote:
> > What I would suggest is that we allow list creation, but
> > not customization. This means that we will be able to leave
> > the toolbar list buttons enabled, but disable the List
> > Dialog in the "Bullets and numbering" menu option. This
> > means people will be able to create simple numbered and
> > bulleted lists ... they just won't be able to customize
> > them yet. I think that is an acceptable compromise. It
> > is similar to the fact that you could create tab stops
> > but not have a dialog to customize the values.
> >
> > Other voices in the crowd ... what do you have to say
> > about this?
>
> How about this? We implement a check box labelled
>
> X Update dialog from Document.
>
> The check box turns off as soon as you change something in the dialog.
> This prevents changes to the dialog contents from the document. If
> you allow "Update from the document" you immediately see the current list
> in the type/position(s) in the preview.
While a nice idea ... I don't think that it is a good user experience
or intuitive. What needs to happen, needs to happen as part of the
post 0.7.12 overhaul of the internals.
When the dialog is initialized the first time for any View then
we need to maintain a state "per view". While the user has not
modified anything, then our "Apply" button should not be enabled.
When the user makes a change to the dialog, we have to note the
changes in the XP code and enable the "Apply" button. If the user
then switches to a new document we will either revert to the
user modified state of the dialog (if changed) ... enabling the
"Apply" button ... or if we have no state information then we
will populate the dialog for the first time and disable the
"Apply" button.
In essence there are two states, per view, that have to be
maintained: 1) Unmodified dialog 2) User modified dialog
but change not applied. In the case of 1) we can take
the information from the document. In the case of 2 then
we will have to pull it out of internal storage from the
dialog. Note that once the user applies a change, we are
back in state 1). I would not expect that if the user
opens two documents; opens a list dialog focused on one,
modifies the entries but does not commit; changes
focus to the next document makes a change to the list
dialog and commits; then closes the list dialog that
the list dialog upon its next invocation would remember
_anything_ (ie everything starts clean again). If you
think about this in the context of single document it
works "as expected", in the context of multiple documents
it is "sane/pleasing behaviour".
> I think the modeless dialog is really cool and I'd like to get feedback
> from users on it. It really is a different way of doing things from MS
> Word. If we design it right it might be substantially better.
Absolutely ... but it MUST be done right. Right now whenever
I loose focus on the window (I have focus follows mouse) and
come back I loose any non-commited changes to the dialog, even
when I only have one document open. This annoys me to no end,
but requires substantial re-working of the dialog internals I've
been putting off for post 0.7.12.
> On the other hand if the Windows dialog proves too hard maybe we should
> look to disable it for windows for 0.7.12.
This is my vote ... then I can get to work and we can make
the world a better place for 0.7.13 with the "way cool list dialog".
Thomas
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf
This archive was generated by hypermail 2b25 : Thu Nov 23 2000 - 09:29:03 CST