Reworked the popup dialog to work as a fallback for systems with no native dialogs.

• Improved text in dialog with Pawel's suggestions
• Added a method in GHOST to declare if a system supports native dialogs
• Use said method to decide which dialog to call
• Some comment/code cleanups

Works in Linux, anyone can help me test in Windows/Mac?

@Diego Gangl (januz), could you update the patch? (Didn't test, but guess it won't apply to current master)
Would be an interesting project for 2.8.

@Julian Eisel (Severin) Rebased, looking forward to 2.8!
Code is a little ugly in places, since I was way over my head with GHOST and blocks. Feel free to commandeer.

Thinking about this... Maybe I'm missing something, but can't we just open a regular window and draw into it? Why does it need to be a dialog window from the OS?

Things might get a bit more complicated then since we couldn't use our regular screen/area/region system as it is, but probably it's worth implementing a pretty basic system to draw our own dialog boxes (I'm actually tempted to try ;D).

@Julian Eisel (Severin), the issue with using multiple windows is it will push us to have better multi-window handling. Eg, prevent the dialog from going behind the main window. X11 window types for dialog/transient windows... for other platforms too.

Just seems like it will push us in the direction of having overlapping windows which then need to be managed - would rather avoid this if it's not essential.

Of course there is an argument that we *should* have better multi-window handling. Just pointing out this adds work for us - for quite a small gain.

I understand an actual window would be better than the internal popups for this, however the most important part of this patch is preventing Blender from closing with unsaved changes (exiting is aborted if the popup is closed). If putting this in a window is too much work (and complexity), I'd consider staying on the popup route.

Since this seems to be moving forward i'll pile on from a platform perspective, but the ui team should have the final say on this (so wait for them before changing anything) @Julian Eisel (Severin) *poke*?

arc doesn't seem to want to apply this patch, so i'm working off the screenshot... i'm pretty sure on windows the 'native' dialog would be used so points 1+2 are not an issue, still it might be worth looking into what the ui guidelines for kde/gnome have to say about the subject.

1. All dialogs with questions on windows have the buttons bottom right aligned in the dialog.
2. The order of the buttons in any app is always yes/no/cancel (i think this applies to kde as well) people instinctively know the order from muscle memory, I'd really prefer if we'd stick to this.
3. All applications ask not 'X has unsaved changes, do you really want to quit' but 'do you want to save changes to X? yes/no/cancel' once more muscle memory which I highly suggest we follow.

In D566#70923, @Ray Molenkamp (LazyDodo) wrote:

arc doesn't seem to want to apply this patch, so i'm working off the screenshot...

Sorry, I haven't rebased this patch in 2.5 years :P I'll get to that soon.

In D566#70923, @Ray Molenkamp (LazyDodo) wrote:

still it might be worth looking into what the ui guidelines for kde/gnome have to say about the subject.

KDE's HIG doesn't say much about dialogs. Gnome's mentions that cancel should go first (from the left) and be an imperative verb.

In D566#70923, @Ray Molenkamp (LazyDodo) wrote:

1. All dialogs with questions on windows have the buttons bottom right aligned in the dialog.
2. The order of the buttons in any app is always yes/no/cancel (i think this applies to kde as well) people instinctively know the order from muscle memory, I'd really prefer if we'd stick to this.
3. All applications ask not 'X has unsaved changes, do you really want to quit' but 'do you want to save changes to X? yes/no/cancel' once more muscle memory which I highly suggest we follow.

"Do you want to save changes" sounds way better, however I would keep the buttons' texts as verbs. I think it's an improvement over the old yes/no/cancel (and both KDE and Gnome use them). About order and alignment: Gnome, Kde and Elementary have three different opinions on this. I wouldn't mind aligning them to the right with the KDE order, but I'd rather wait to hear comments from the UI team.

@Campbell Barton (campbellbarton) thanks for the inlines, I'll get to them soon.

I still haven't been able to make this work through a macro. It fails even when making a macro through Python in a 2.79 build, the exit op is never called after save. However if I change the first op to something non-modal (like opengl rendering), then quit actually gets called. Looking around other macros in code, it seems the modal op is always the last one and not the first.

@Campbell Barton (campbellbarton) looks like this is a limitation of macros, or maybe a bug?

Really great progress. How possible is it to override the "Do you want to override the so and so file" pop up when we save?
Why do we need a confirmation dialogue for saving something we, out of our own will, want? I mean is no accident when someone intuitively
presses "Save" because they are about to close the laptop, or the library is about to close doors, or the bus has just arrived....
Those are some of the common day to day situations in wich a "do you want to overwrite..so and so" dialogue would prevent the entire
chain of events to happen (from saving correctly without damaging the file while laptop is going to sleep, and it won´t because there´s a dialogue waiting for confirmation).

Could we please also do something about the DELETE button dialogue? I´m pretty sure that UNDO is standard by now, and that Blender is more code-stable now
on Undoing things if they are deleted "by accident".

Is it possible to send these as a checkbox somewhere to user preference windows to override and make those "SAVE" and "DELETE" commands execute at once, with no additional dialogues?
Thanks.
Ps: Please don´t delete this post, if it´s misplaced please send it to the appropiate topic post. I apologize for the incovenience.

@Campbell Barton (campbellbarton) thanks for the free rebase/cleanup :)
@David (activemotionpictures) There's some ongoing debate about that at T37422, this patch is for the confirmation dialog on linux only

Looked into making operator macros support this (see patch P607 which does work) however this is a bad hack, the macro system would need to be moved into the operator API for this to work properly - since currently a wrapper operator is used to execute macros - which causes problems with the file selector and is more of a problem to resolve then I'd expected.

For now, suggest to add an exit option to the save operator (instead of having multiple operators).
The option can be hidden from users with PROP_HIDDEN.