save file as - file selection dialog - 0.9.18

Vroni · 11-12-2019, 06:24 AM

Hi,

when i save a file to make use of it in another book everything seems to be fine. But the filedialog remains open - unusable, uncloseable. I need to close sigil to get rif of it.

Sigil 0.9.18 / macOS Mojave 10.14.6

PS I dont expect it to be fixed in 0.9.18 - maybe its still present in the new version. It hides underneatrh all other windows, you ned to close/minimize the others to be aware.

KevinH · 11-12-2019, 07:36 AM

That is a bug in Mojave with Qt. I can not recreate it on my High Sierra dev box. We could change away from using the MacOS native file dialog box with Qt, as it seems to be better behaved, has a title bar that tells you what to look for, etc, It just does not look like the normal Mac one.

Are you in the very latest version of Mojave itself?

Vroni · 11-12-2019, 08:38 AM

10.14.6 is the latest Mojace version, next one is Catalina

KevinH · 11-12-2019, 09:56 AM

Hmm ...

Does it happen everytime or only when you cover/hide the dialog with another window before ever hitting OKAY or CANCEL?

I know Qt has issues with native backingstore on macOS going away when a window is even briefly completely hidden or minimized. Basically Mojave changed things so that when hidden the native widget backing widget is deleted which has to be caught by Qt and recreated when unhidden. No idea why macOS made that change in Mojave as it is not typical for how widgets work in most gui systems.

Please let me know what you find out. If it is backingstore related, then changing to non-native file dialogs probably will not help.

KevinH

KevinH · 11-12-2019, 10:07 AM

Tried everything I could to recreate what you are seeing on macOS HighSierra and it is rock solid under my testing.

So a step by step sequence to recreate this issue might be helpful.

Thanks,

KevinH

odamizu · 11-12-2019, 08:20 PM

I have been able to reproduce this on High Sierra with both 0.9.18 and 0.9.991

right-click on single file and select Save As
close Sigil window and everything looks fine (i.e., all windows are gone)
click on Sigil icon in Dock or open new epub (with right-click or double-click)
Save As dialog box re-appears and the only way to get rid of it is to quit Sigil

KevinH · 11-12-2019, 10:42 PM

Yes it is a modal dialog and by closing the Window that generated the modal dialog you went around its modal behaviour. Notice how you can not move the main Sigil window to cover the file dialog box or bring it to the foreground, indicating that this dialog must be dismissed first. The correct approach is to hit cancel in a modal dialog first (that is why it was made modal) then close the Window which is its parent if that is what you want to do. When you forcibly close its parent first, you leave it an orphan and Sigil is still running in the background but now without a main window.

FWIW, I am not sure this behaviour is what this issue was about. Yes, Qt should have prevented you from closing the Window without dismissing the dialog first but Qt has never handled that well on macOS.

odamizu · 11-12-2019, 11:40 PM

I think I did not explain thoroughly:

right-click on single file and select Save As (including following through with the actual Save As, including inputting desired filename, file-location (I chose Desktop, but I don't think this matters), and hitting Save button — the file saves and dialog box closes
close Sigil window and everything looks fine (i.e., all windows are gone and your newly saved file is in the location you chose)
click on Sigil icon in Dock or open new epub (with right-click or double-click)
Save As dialog box re-appears (even though the Save As has already been completed in the first step above) and the only way to get rid of it is to quit Sigil

asleyam · 11-13-2019, 12:11 AM

I went through those steps several times in Mohave 10.14.6 with sigil 0.9.18 and did not have that issue. No save as pop up dialog box after sigil window closed and another epub opened. The steps included keeping dialog box on top, as well as behind other windows and apps. I use a trackpad with the iMac to control backing and forwarding of windows, as well as using several desktops. I tried various permutations and still not been able to recreate that issue. Very odd.

I did some further testing with 0.9.991 in an external ssd mohave clone, an external ssd Catalina installation, in a 2013 retina MacBook Pro (tried them all both in dark and light mode, with and without my qt styles pref files) and still could not recreate the save as persistent save as problem.

odamizu · 11-13-2019, 01:06 AM

Interesting. I am able to reproduce Vroni's issue consistently on High Sierra using 0.9.18 and 0.9.991, and I just reproduced it on Catalina using 0.9.991, though it happens less consistently. So perhaps it's something peculiar to my and Vroni's set-up?

In any case, saving a single file is not something I ever do, so this is not an issue for me. Was just trying to help investigate

Vroni · 11-13-2019, 03:52 AM

Thanks odamizu, thats the way it works on mojave as well. Its not a big issue, but as it can be reprduced in the new beta there might be a chance to get rif of it.

By the way can i install the beta in parallel to my existing 0.9.18?

KevinH · 11-13-2019, 08:07 AM

I will try to recreate it on my dev box (High Sierra). This is probably a Qt issue so .... we may not be able to get an immediate fix so ...

Exactly how are you closing that Window? Are you hitting the red button on the titlebar, or actually using AppleKey+Q or using the File->Close/Quit button?

Does how you close impact the issue? Does this happen if the epub itself has been modified causing the "are you sure" message?

KevinH

KevinH · 11-13-2019, 09:34 AM

I simply can not recreate this at all on my macOS HighSierra machine with either Sigil-0.9.18 nor Sigil-0.9.991.

I tried using the AppleKey+Q and by hitting the red close window button.

So I need someone who can recreate this to tell me how they are closing the Window?

Thanks,

KevinH

Vroni · 11-13-2019, 01:49 PM

Its lokie odamizu gas described: the file selection box is processed complete, with "save file" , the file is present and ok, the file selector dialog closed itself.

Now i close the sigil main window cliucking on the red dot in the upper left corner. I double click another epub in finder and it is opened. This is the time when the file selector box from the previous session comes up again, evrything is not selectable/deactivated.

The only thing the file selector is acting on if you hover the green dot, it turns from grey to green, but without any action when you click on it.

The red/yellow dot do not show this behaviourm the stay grey even when i hover the mouse over them.

I can get rid of the file selector dialog only by closing sigil from the dock by choosing "quit".

This remnant dialog box does not prohibit a new file as from the second epub, so for me its only a minor defect. At least, i have as many of these remnants as i choosed a new epub from finder and did a save as.

Vroni

KevinH · 11-13-2019, 03:01 PM

That is exactly what I have been trying but I can not get it to happen on my machine at all.
I am almost positive this must be a Qt bug specific to macOS but I simply can not get what you describe to happen.

Is this only with a particular epub, or after long editing sessions? Is there any rhyme or reason as to when it happens? I am pretty stuck here if I can not recreate it.

11-12-2019, 06:24 AM	#1
Vroni Banned Posts: 168 Karma: 10010 Join Date: Oct 2018 Device: Tolino/PRS 650/Tablet	save file as - file selection dialog - 0.9.18 Hi, when i save a file to make use of it in another book everything seems to be fine. But the filedialog remains open - unusable, uncloseable. I need to close sigil to get rif of it. Sigil 0.9.18 / macOS Mojave 10.14.6 PS I dont expect it to be fixed in 0.9.18 - maybe its still present in the new version. It hides underneatrh all other windows, you ned to close/minimize the others to be aware. Attached Thumbnails

11-12-2019, 08:20 PM	#6
odamizu just an egg Posts: 1,586 Karma: 4300000 Join Date: Mar 2015 Device: Kindle, iOS	I have been able to reproduce this on High Sierra with both 0.9.18 and 0.9.991 right-click on single file and select Save As close Sigil window and everything looks fine (i.e., all windows are gone) click on Sigil icon in Dock or open new epub (with right-click or double-click) Save As dialog box re-appears and the only way to get rid of it is to quit Sigil

11-12-2019, 11:40 PM	#8
odamizu just an egg Posts: 1,586 Karma: 4300000 Join Date: Mar 2015 Device: Kindle, iOS	I think I did not explain thoroughly: right-click on single file and select Save As (including following through with the actual Save As, including inputting desired filename, file-location (I chose Desktop, but I don't think this matters), and hitting Save button — the file saves and dialog box closes close Sigil window and everything looks fine (i.e., all windows are gone and your newly saved file is in the location you chose) click on Sigil icon in Dock or open new epub (with right-click or double-click) Save As dialog box re-appears (even though the Save As has already been completed in the first step above) and the only way to get rid of it is to quit Sigil

11-13-2019, 12:11 AM	#9
asleyam Enthusiast Posts: 35 Karma: 14720 Join Date: Mar 2016 Device: kindle voyage, Kobo Forma, Kobo Aura One	I went through those steps several times in Mohave 10.14.6 with sigil 0.9.18 and did not have that issue. No save as pop up dialog box after sigil window closed and another epub opened. The steps included keeping dialog box on top, as well as behind other windows and apps. I use a trackpad with the iMac to control backing and forwarding of windows, as well as using several desktops. I tried various permutations and still not been able to recreate that issue. Very odd. I did some further testing with 0.9.991 in an external ssd mohave clone, an external ssd Catalina installation, in a 2013 retina MacBook Pro (tried them all both in dark and light mode, with and without my qt styles pref files) and still could not recreate the save as persistent save as problem. Last edited by asleyam; 11-13-2019 at 11:22 PM. Reason: more test result

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
File dialog in KDE Plasma 5 on Linux	firus	Devices	9	08-05-2017 12:26 AM
Linux - calibre 2.0 file dialog hang and workaround	Adoby	Calibre	0	08-22-2014 03:25 PM
File Open dialog causes Calibre 64bit to crash	glypto	Calibre	4	01-10-2014 04:51 AM
File/Folder Dialog errors	Remnant	Devices	4	09-26-2013 11:11 PM
File selection widget	BartZorn	Sigil	8	01-25-2013 02:41 AM

11-12-2019, 07:36 AM	#2
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	That is a bug in Mojave with Qt. I can not recreate it on my High Sierra dev box. We could change away from using the MacOS native file dialog box with Qt, as it seems to be better behaved, has a title bar that tells you what to look for, etc, It just does not look like the normal Mac one. Are you in the very latest version of Mojave itself?

11-12-2019, 08:38 AM	#3
Vroni Banned Posts: 168 Karma: 10010 Join Date: Oct 2018 Device: Tolino/PRS 650/Tablet	10.14.6 is the latest Mojace version, next one is Catalina

11-12-2019, 09:56 AM	#4
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Hmm ... Does it happen everytime or only when you cover/hide the dialog with another window before ever hitting OKAY or CANCEL? I know Qt has issues with native backingstore on macOS going away when a window is even briefly completely hidden or minimized. Basically Mojave changed things so that when hidden the native widget backing widget is deleted which has to be caught by Qt and recreated when unhidden. No idea why macOS made that change in Mojave as it is not typical for how widgets work in most gui systems. Please let me know what you find out. If it is backingstore related, then changing to non-native file dialogs probably will not help. KevinH

11-12-2019, 10:07 AM	#5
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Tried everything I could to recreate what you are seeing on macOS HighSierra and it is rock solid under my testing. So a step by step sequence to recreate this issue might be helpful. Thanks, KevinH

11-12-2019, 10:42 PM	#7
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Yes it is a modal dialog and by closing the Window that generated the modal dialog you went around its modal behaviour. Notice how you can not move the main Sigil window to cover the file dialog box or bring it to the foreground, indicating that this dialog must be dismissed first. The correct approach is to hit cancel in a modal dialog first (that is why it was made modal) then close the Window which is its parent if that is what you want to do. When you forcibly close its parent first, you leave it an orphan and Sigil is still running in the background but now without a main window. FWIW, I am not sure this behaviour is what this issue was about. Yes, Qt should have prevented you from closing the Window without dismissing the dialog first but Qt has never handled that well on macOS.

11-13-2019, 01:06 AM	#10
odamizu just an egg Posts: 1,586 Karma: 4300000 Join Date: Mar 2015 Device: Kindle, iOS	Interesting. I am able to reproduce Vroni's issue consistently on High Sierra using 0.9.18 and 0.9.991, and I just reproduced it on Catalina using 0.9.991, though it happens less consistently. So perhaps it's something peculiar to my and Vroni's set-up? In any case, saving a single file is not something I ever do, so this is not an issue for me. Was just trying to help investigate

11-13-2019, 03:52 AM	#11
Vroni Banned Posts: 168 Karma: 10010 Join Date: Oct 2018 Device: Tolino/PRS 650/Tablet	Thanks odamizu, thats the way it works on mojave as well. Its not a big issue, but as it can be reprduced in the new beta there might be a chance to get rif of it. By the way can i install the beta in parallel to my existing 0.9.18?

11-13-2019, 08:07 AM	#12
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	I will try to recreate it on my dev box (High Sierra). This is probably a Qt issue so .... we may not be able to get an immediate fix so ... Exactly how are you closing that Window? Are you hitting the red button on the titlebar, or actually using AppleKey+Q or using the File->Close/Quit button? Does how you close impact the issue? Does this happen if the epub itself has been modified causing the "are you sure" message? KevinH

11-13-2019, 09:34 AM	#13
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	I simply can not recreate this at all on my macOS HighSierra machine with either Sigil-0.9.18 nor Sigil-0.9.991. I tried using the AppleKey+Q and by hitting the red close window button. So I need someone who can recreate this to tell me how they are closing the Window? Thanks, KevinH

11-13-2019, 01:49 PM	#14
Vroni Banned Posts: 168 Karma: 10010 Join Date: Oct 2018 Device: Tolino/PRS 650/Tablet	Its lokie odamizu gas described: the file selection box is processed complete, with "save file" , the file is present and ok, the file selector dialog closed itself. Now i close the sigil main window cliucking on the red dot in the upper left corner. I double click another epub in finder and it is opened. This is the time when the file selector box from the previous session comes up again, evrything is not selectable/deactivated. The only thing the file selector is acting on if you hover the green dot, it turns from grey to green, but without any action when you click on it. The red/yellow dot do not show this behaviourm the stay grey even when i hover the mouse over them. I can get rid of the file selector dialog only by closing sigil from the dock by choosing "quit". This remnant dialog box does not prohibit a new file as from the second epub, so for me its only a minor defect. At least, i have as many of these remnants as i choosed a new epub from finder and did a save as. Vroni

Advert

Advert

11-13-2019, 03:01 PM	#15
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	That is exactly what I have been trying but I can not get it to happen on my machine at all. I am almost positive this must be a Qt bug specific to macOS but I simply can not get what you describe to happen. Is this only with a particular epub, or after long editing sessions? Is there any rhyme or reason as to when it happens? I am pretty stuck here if I can not recreate it.