Sigil-2.3.0 Released

[KevinH]

Is there any size or scaling difference between the Sigil MainWindow when it has no menubar to the version you recover by minimizing and restoring it to bring the menubar back/ Perhaps a larger or smaller scaling? Or maybe an small positional offset?

It does sound as if anything that will cause the MainWindow to be redrawn will work to return the menu bar. So something is causing a refesh/update signal to get lost when the KVM switch is thrown.

By any chance is your linux box set to use a single top menubar (like the macOS does)? Some KDE and GNome desktops can be set that way.

As to why the menu bar goes away at all, probably has to do with detecting changes in how different OS's use different monitor resolutions/refresh rates on the exact same monitor when connected to the switch.

So you might try syncing the Linux driver resolution and refresh rate, and scaling to **exactly match*** those used by Windows and see if the issue goes away.

I have no idea how the Qt software or Windows monitors for changes in these settings *not* caused by manually setting those values in the control panel (ie how it detects the KVM switch was thrown)

The KVM switch must be responsible for telling the Monitor to autosync and then alerting the OS somehow.

[KevinH]

Wow, the number of display issues with KVM switches is huge:

google: KVM switch issues

And I even found one that causes missing menus:

google: kvm switch missing menu

https://forum.blackmagicdesign.com/v...?f=21&t=166728

And from reading up on them it seems the KVM switch most often the culprit in how it emulates to the OS that the monitor is still connected.

[un_pogaz]

Little bug report:
The top-left window is gradually reduced at each open/close cycle (1 pixel).
This bug appeared when switching to the Qt theme.
Windows, version 2.3.0

[theducks]

The days of the simple rotary A - B VGA switch are long gone.
(there were 3 pins in the VGA connector, that the smarter switches maintained, even when switched away)

With Computers doing active Auto-detect (allows add or remover Keyboard or Mice or other USB devices), it detects the instant change.

As with anything AUTO, MURPHY still rules.

You should see what happens when you want to use your TV as an extra Monitor.

[KevinH]

Originally Posted by un_pogaz

Little bug report:
The top-left window is gradually reduced at each open/close cycle (1 pixel).
This bug appeared when switching to the Qt theme.
Windows, version 2.3.0

From your Screenshot, it looks as if you have the Table of Contents on top of BookBrowser. And that the issue is that the Table Of Contents Window is shrinking?

Is that correct? How exactly are you "opening and closing" it? Is it with the View menu, or drag and drop or ...? What exactly do you mean by "switching to Qt theme"? Are you refering to dark mode theme?

The QDockwidgets do not remember their own sizes, their sizes are stored only when closing Sigil itself and restored on opening Sigil itself. Otherwize hiding and showing QDockwidget windows negotiates their own sizes.

[KevinH]

Originally Posted by un_pogaz

Little bug report:
The top-left window is gradually reduced at each open/close cycle (1 pixel).
This bug appeared when switching to the Qt theme.
Windows, version 2.3.0

Okay, I just tested this on macOS, and with the Table of Contents on top and BookBrowser open underneath both docked on the left (as your screencap shows), I am able to hide and view the Table of Contents repeatedly and nothing moves or shrinks. But this is with MacOS.

[DiapDealer]

Originally Posted by un_pogaz

Little bug report:
The top-left window is gradually reduced at each open/close cycle (1 pixel).
This bug appeared when switching to the Qt theme.
Windows, version 2.3.0

Never mind: Kevin already asked ... "what exactly do you mean by 'when switching to the Qt theme' "?

Until we find out exactly what steps are being taken, I can verify that on Windows (using either dark theme [or light theme]), the ToC widget (placed upper left, above Book Browser) is not shrinking for me when:

opening/closing Sigil
minimizing/restoring Sigil
opening/hiding ToC with View menu

[DiapDealer]

OK. The "one pixel" thing is not really accurate for me, but I can confirm that the ToC widget (when configured on top left above Book Browser) does continuously shrink when closing/reopening Sigil when Sigil IS MAXIMIZED. I don't often run programs maximized these days, so I didn't notice at first. It seems to only shrink so far and then stop (in my testing). But it's definitely not remembering its geometry when maximized and closing/opening sigil. The theme has no effect on this issue.

P.S. It could be Book Browser growing for all I know!

[DiapDealer]

In general: stacked (not tabbed) dockwidgets are not remembering their heights when Sigil is maximized on Windows (until some sort of minimal height is achieved on the topmost widget). I've not attempted more than two stacked (not tabbed) widgets at this point.

It looks like they've gained a lot of ground on the historical qt geometry issues when apps are maximized, but there are still a few minor things not quite there yet.

We're not going back to the mess of spaghetti code we used to deal with maximized geometry saves/restores pre-2.3!

[KevinH]

I just tried this on MacOS (using Maximized not Full Screen) with the Table of Contents on the top left above BookBrowser, and it behaves even worse than windows ... it forgets I even moved the Table Of Contents to the top left and returns it back to be tabbed with Preview.

This only happens if Sigil's MainWindow is Maximized. If it is even just one pixel smaller in dimension than Maximized, all works as expected.

So this is a Qt6 bug in saving or restoring state that happens only when Sigil is Maximized.

Not sure we can do anything about it but create a Qt bug report, which will be ignored most likely since it is something so minor.

[KevinH]

Okay, at least on macOS there is a race between the restoreState (which happens on first show) and the restoreGeometry (which must happen first!) because the call to showMaximized or showFullScreen sometimes forced the MainWindow to be activated/shown before we even had a chance to read in the state to be restored.

I have just fixed this by moving the reading the state in earlier so it is ready to be restored before any race can happen.

This fixes the moved Table of Contents bug when Maximized on macOS.

I have high hopes this "fix" will also fix this off by 1 or more thing for Windows too.

[un_pogaz]

Okay, you found it, sorry for not being as clear as I thought.


About "switching to Qt theme":

In version 2.1.0 (and earlier), Sigil used Windows 10's native rendering system, which gave the UI a very square and flate appearance, since 2.2.0 Sigil use the Qt's integrated rendering system that was round and with relief. Image for exemple.
It was unspecified in the changelog and surprising, but unimportant.

So, the appearance of almost every element has changed (Tab, Text field, checkbox...) in some subtle way. I didn't notice the shrinking bug until just now, and given the significant change in the "switching to Qt theme" occured on 2.2.0, I assumed that this was the cause and that I hadn't noticed the problem until later.
...
And after testing, no, my bad again. The shrinking bug is specific to 2.3.0

[DiapDealer]

Originally Posted by un_pogaz

About "switching to Qt theme":

In version 2.1.0 (and earlier), Sigil used Windows 10's native rendering system, which gave the UI a very square and flate appearance, since 2.2.0 Sigil use the Qt's integrated rendering system that was round and with relief. Image for exemple.
It was unspecified in the changelog and surprising, but unimportant.

For the record: Sigil never used Windows native rendering system. It was always a Qt style. That style changed to Qt's Fusion in Sigil 2.2.0 in order to accommodate On the fly dark/light theme switching.

[DiapDealer]

Originally Posted by KevinH

Okay, at least on macOS there is a race between the restoreState (which happens on first show) and the restoreGeometry (which must happen first!) because the call to showMaximized or showFullScreen sometimes forced the MainWindow to be activated/shown before we even had a chance to read in the state to be restored.

I have just fixed this by moving the reading the state in earlier so it is ready to be restored before any race can happen.

This fixes the moved Table of Contents bug when Maximized on macOS.

I have high hopes this "fix" will also fix this off by 1 or more thing for Windows too.

I need to check this on Windows. I forgot about it while debugging the other crash!

[KevinH]

Originally Posted by DiapDealer

I need to check this on Windows. I forgot about it while debugging the other crash!

This is why I am also testing commenting out showMaximized and showFullScreen to prevent the possibility of two different paths during startup.

It might help this case too.