Save dialogs not modal

[humdinger]

This is hrev41272.

I think save dialogs used to be modal, i.e. after it's invoked, you can't change the to-be-saved document. Which makes sense, I think.
Well, you can now... Tried with Pe, StyledEdit, I-O-M and WonderBrush, so I guess the underlying Tracker is to blame.

[X512]

This is not bug, this is feature. MS Windows modal dialogs is terrible and there are no reason to mimic it.

[anevilyak]

Working as designed, file panels are non-modal by default, the app has to explicitly choose to make them so. This has been the case going back to BeOS.

[humdinger]

OK. Then I probably remember it wrong. I just noticed it, because I was working with I-O-M, wanted to save, got the save dialog, but somehow lost focus on it. I accidentally and unknowingly deleted a shape in the I-O-M document, then got back to the save dialog and saved the now maimed file...
I can see an advantage of having only the save dialog modal. Normally, you invoke the save dialog to save the current state of the document, implying that it cannot change until it is "save".

Maybe it's no big deal, it's just that I got bitten by it at least this one time. Thankfully I don't use FFM, or I'd have much more focus casualties... :)

[anevilyak]

Replying to humdinger:

I can see an advantage of having only the save dialog modal. Normally, you invoke the save dialog to save the current state of the document, implying that it cannot change until it is "save".

Nothing prevents one from making it modal, it's simply not the default. Whether it makes sense or not is really something that has to be decided on an app-by-app basis anyhow though, i.e. Vision uses a save dialog to let you pick where to save a file someone sends you, but nothing about that action is modifiable by going back and typing into the chat, so it's made non-modal so you can move it out of the way and deal with it when you're ready. Making it universally modal is therefore not the right answer either, though making the one in I-O-M modal might make sense.

[humdinger]

Fair point.

[bonefish]

Replying to humdinger:

I can see an advantage of having only the save dialog modal. Normally, you invoke the save dialog to save the current state of the document, implying that it cannot change until it is "save".

Unfortunately making the dialog modal prevents the user not only from changing the document's state. Ubiquitous use of modal dialogs is definitely one of the top items on my Windows user-unfriendliness list (beaten by "mouse wheel affecting the focused widget", but competing with the "scroll bar from hell"). I find myself relatively often in the situation that I need some information from the document while playing with a modal dialog. In the save dialog case that information is ususally a name, date,... that shall contribute to the file name.

I don't use Icon-O-Matic, so I don't really care, but from your description the dialog didn't seem to be the main factor leading to the data loss. It's rather hard to protect the users from themselves (without introducing serious annoyances) and I don't think making dialogs modal would help a lot with that. I'd be more in favor of "allow them to mess up, but also give them the tools to easily recover from it" (e.g. an automatic, persistent undo/version history).

[humdinger]

I ran out of points - esp. those fair ones are in such a demand. Maybe you could share with Rene? :P

I-O-M's undo history is very nice, BTW. It's still there after saving, so you can undo accidents until you close the document. I dislike apps that silently purge the history after saving.