[Qt-interest] QFileDialog: native + sheet (Window modal) not possible?

[Oliver.Knoll at comit.ch]

On 2011-01-27 Nikos Nikos Chantziaras wrote:

>>  ...
>> At least on Mac OS X then it works as expected! :)
>> 
>> Thanks for confirming this! I will eagerly try this out myself
>> tonight. :)

Just for the record: I tried the same code on Mac and Linux: on Mac the dialogs are indeed sheets by default and on both platforms the *native* dialog is used, as expected.

So it seems that only on Windows (XP - don't know about Windows 7?) the Qt file dialog is used when doing QFileDialog *fd = new QFileDialog(...).

> 
> Btw, you can also use sheets with application-modal dialogs.  Example:
> 
>    QFileDialog diag(this); 
>    diag.setWindowModality(Qt::WindowModal);
>    diag.exec();
> exec() makes the dialog modal, but it's still a sheet.  

Hmmm, I remember I tried something similar, I even set the "Sheet" property explicitly, but I think it only worked the first time when calling the file dialog. The 2nd time it appeared as "application modal" again, and NOT as sheet anymore. But I quickly gave up that approach, since according to  http://doc.trolltech.com/qq/QtQuarterly30.pdf that is not really supported anyway. And sheets should never be application modal according to the Apple User Interface Guidelines (but in your case that works, since you only have one document window anyway ;)

> I actually use
> this because my application is not multi-document based and exec() is
> simpler to use than open() since it blocks.

Yes, exec() is definitively much easier to use than open(). I am currently trying to implement the following scenario in my (multi-window) application (for each document there is a separate main window). When I quit the application I check the modified state of the documents. If it is modified I want to ask the user the usual "Cancel, Quit, Save" question, and if the user decides to save I might still ask with a file dialog for a proper file to store in. So two non-blocking dialogs in a row, think about that!

My first primitive approach is to have a slot for each possible state (e.g. "Quit when modified" -> "Do save?" (slot) -> "Choose file path" (slot) -> "Really quit"). Which is really a pain and much more complicated than with the exec() approach. Off course I cannot (easily) re-use those slots in the following scenario: "Open new document" -> "Save previous document?" (slot) -> "Choose filepath" (slot)" -> "Open new document" (slot)" -> "Read from chosen file path" etc. etc.

With my previous approach I had one single method called "proceedWithModifiedDocument" which was blocking and could hence be re-used from every possible place, e.g. when opening a new document (and closing the previous one first), closing the application, ... but now since I need to somehow determine the next step in the non-blocking case I somehow need a slot for each possible state that the application can be in, doh!

Anyway, apparently that is the way to go (http://labs.qt.nokia.com/2010/02/23/unpredictable-exec/), and the reason to open a new mainwindow now for each new document is exactly as to minimize the usage of these "slot chains". So the only real "painful" scenario is the first mentioned example, when having to quit the application with a modified document which has never been saved before.

Even the simple example in http://doc.qt.nokia.com/qq/qq18-macfeatures.html#newwindowtypes becomes somewhat more complicated, with an additional state variable "reallyQuit". Needless to say that in that example they use an application modal (and blocking with exec()) file dialog when saving the file.

Anyone else did this with the open() approach? What best practise would you recommend, having a "stack" with the slot on top to be executed first (some kind of stack state machine)?

Cheers, Oliver 
--
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22