Re: UI modal oddity

[David Stanaway <david stanaway net>]

On Mon, 2005-03-07 at 16:07 -0700, Andreas J. Guelzow wrote:
> On Mon, 2005-07-03 at 16:59 -0600, David Stanaway wrote:
> > I was doing some work with multiple work books open and came across this
> > gotcha, but I wanted to check if this is normal or a bug before
> > bugzillering it.
> >
> > When having multiple workbooks open, in one workbook, File:Open/Save
> > As...  leave the dialog open and get distracted with some other
> > application. Come back to gnumeric and try and interact with another
> > workbook (Having forgotten that there is a modal Open/Save As... dialog
> > still open), it appears that gnumeric is frozen although all
> > re-rendering damaged areas still takes place. There is no indication
> > that gnumeric is waiting for a modal dialog to be finished with.
> >
> > Should 
> > a) The Open/Save As... dialog be modal for the workbook it was called
> > from
> > b) ... for the whole application
> > c) The Open/Save As... dialog should not be modal
> >
> > I think it should be a, but it is actually b.
> >
> > This is experienced with 1.4.1 in debian/sarge.
>
> Why shouldn't it be (c)? The open dialog should surely by (c). For the
> save as dialog (a) may be justifiably, but I don't see why it needs to
> be modal at all.


For save, it should certainly be (a), as otherwise there is some
ambiguity as to what exactly you are saving when you actually write the
file if you have made changes since you opened the save as dialog.
What happens if we are using case (a), and via gnumeric scripting you
make changes to the workbook which has a save pending, but from another
unfrozen workbook? Should this be permitted, or should it give some
error in the script?

For open, I don't see why it should be modal at all.


-- 
David Stanaway <david stanaway net>