acquaman/acquaman — comment on commit 31ff85688af0647a9b1433a53c2f5bd03b020428
File:  line 0
By markboots:

You scoundrel ; )

Actually, I may or may not have done the exact same thing when I built AMImportController and AMScanDatabaseImportController. It does break our separation between non-gui library classes and UI classes, but since nobody in the world is currently using Acquaman in a non-windowed environment, I think we can let it slide for now.

To resolve this, we could make a "get immediate answer from user" class that uses GUI mechanisms when available, and a command-line prompt when unavailable... But I guess the ideal would be to change the design of the controller so it doesn't need to ask questions mid-way through a process (which would be more amenable to using it as a library in a non-interactive setting). But sometimes (like you mentioned) this is difficult, complicated, and error prone...

So I'm cool with the inclusion of QMessageBox for now in some limited non-GUI classes when there's no other (clean) way. I think it's important, though, to make sure that this message box could only pop up during definitely user-driven operations that can be interrupted. (For example, creating and loading an AMScan object can be done in the background to be accessed by AMExternalScanDataSource, to generate thumbnails, maybe in the future by a non-GUI analysis program, etc. It wouldn't be cool for anything in that process to interrupt with a QMessageBox.)