Subject: Re: List Dialog compromise
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Thu Nov 23 2000 - 16:34:11 CST
On Thu, 23 Nov 2000, Thomas Fletcher wrote:
> >
> > 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.
>
This is exactly what Mike thought should happen during a discussion on IRC
yesterday and I agree with him. We think it should be possible to maintain
a list state per view as series of private classes addressed by our view
pointer. When a view goes away all modeless dialogs are notified
automatically by the Modeless framework and we can delete the list state
class.
> 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 agree.
> > 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.
I agree this is annoying which why I suggested the checkbox.
>
> > 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".
>
It seems that Mike has been successful. I guess its up to Sam. If decided
to debug the dialog, I'll go along quietly.
Martin
This archive was generated by hypermail 2b25 : Thu Nov 23 2000 - 16:34:26 CST