On Mon, 16 Oct 2000, John Levon wrote:
> On Mon, 16 Oct 2000, Allan Rae wrote:
>
> > So the question is:
> >
> > Do you _really_ need to disable the various fields when the dialog is
> > readonly or will disable OK and Apply suffice?
> >
> > Remember that when switching to a readonly buffer, toggling readonly on or
> > opening a readonly file the user gets a message dialog saying "Document is
> > readonly -- you won't be able to change anything" or something to that
> > effect. So the user has already been warned that they can't expect to do
> > much to the document.
> >
> > The only cases I can think of that need to have objects disabled are where
> > a particular objects callback can cause some change to the document (such
> > as the documentclass combo in FormDocument¹) but that can sometimes be
> > blocked in the callback by checking the readonly status either of the
> > buffer directly or of the bc_. In the documentclass case it needs to be
> > disabled.
> >
> > Allan.
> >
>
> IMHO this argument sounds like you are arguing from an ease of
> implementation rather than an ease of use point of view.
No. I'm saying if someone wants to start playing around with document
settings etc. on a readonly document they are more than likely going to
toggle-readonly (which should be added to the menues as either Edit or
Document->Toggle_Read_Only) so they can make their changes. In which case
letting them fiddle about with the dialogs and have those changes
available once they switch is a reasonable thing I think.
> I think things should be always disabled if they cannot be changed,
> unless they are simply view-type things - this should be an invariant
> across the UI.
Then this is something we should decide.
There is support for this in ButtonController but for the problem Jürgen
describes we need to extend the RadioButtonGroup so that it can activate
different groups of objects based on a particular radio button input.
We should also try to make it so we can add RadioButtonGroups to the
button controller so that the button controller can tell the RBG we are
entering or leaving a read-only state. Then it will be the RBG's job to
deactivate everything it controls and remember which radio button should
be enabled upon return to a read-write state.
So does everyone agree with John (and I assume Jürgen) that we should
deactivate everything in a dialog when the document is read-only?
Allan. (ARRae)
