Future Release To-Do Items

[BeckyEbook]

Windows 10.
When the SIGIL_DOUBLE_TEXTCURSOR_WIDTH environment variable is set, in addition to the width of the cursor, the sizes of the close and dock icons also change. This only happens in light mode, as in dark mode we override this with the appropriate styling from the win-dark-style.qss file

[KevinH]

@BeckyEbook,
Yes I have noticed that QDockWidget titlebar buttons seem to be broken on macOS as well but only under dark mode. This happens with or without a stylesheet used.

I tried to add the CaretStyle last to not interfere with your QProxyStyle set for dark mode.

If the pixelmetric changes for cursor width change are part of the problem (icons are okay but not positioned properly or not properly sized, I can ifdef in platform specific additions/changes to CaretStyle.cpp if you can tell me what to add for Windows.

Or alternatively, include the required stylesheet changes.

[KevinH]

@DiapDealer, @BeckyEbook

Why does Windows not use a windows style or new windows style but instead use "fusion"?

If in light mode, does the application style ever get set directly to "fusion" in our main.cpp?

If so, that style should be passed through into CaretStyle as app.style() for use with QProxyStyle.

Perhaps we need to reorganize main.cpp to explicitly set style first before passing it through any QProxyStyles?

Also, the macStyle makes dark-light theming work more fully than fusion. Perhaps a Windows specific style would do the same for Windows leaving the hard coded dark mode changes only used by Linux?

Does using a Windows style on windows and Qt allow auto dark-light theme switches without having to restart Sigil work like it does for Qt and macOS with the macOS style?

[DiapDealer]

Qt light/dark on Windows is getting better, but it's still quite the crap-shoot. Fusion is still the recommended base for style changes.

I can do some experimenting to see if going with a fully Windows/user-chosen dark mode is feasible (I'm not sure if Windows on-the-fly switches are supported yet where Qt is concerned, to be honest. The lack of a Qt api to detect theme changes). There's also differences between Windows 10 and Windows 11 behavior. We should have some options since moving to Qt6.6, but there's no guarantee that whatever dark theme is automatically chosen by Windows/Qt will be compatible with the default colors/highlighting for Code View.

Some good (and by good I mean confusing and self-contradicting!) reading on the subject here: https://www.qt.io/blog/dark-mode-on-...11-with-qt-6.5

Most Linux users rely on platform themes and qtct/kvantuum to style their Qt applications. The dark mode we currently make available to Linux (same as the Windows one) if they set an environments variable, should be considered a last resort, in my opinion

[KevinH]

Okay, I fired up and updated my Manjaro Linux Box which uses KDE Plasma as my desktop.

I then git pulled from Sigil master and rebuilt and installed it.

It seems to work just fine with no visible changes in the size or the location of the DockWidget Close or and Float Buttons with and without the double width textcursor on.

That said, the native native highlight color for showing focus is not "red" and instead appears to be a blue-green of some sort.

Update: It seems this native highlight color is chosen from palette().color(QPalette::Highlight) so we can use that instead of red. So no need for a color picker!!!

I exited from Sigil and went to the KDE SystemSettings and changed from Breath Light to Breath Dark by simply clicking on an image of the two themes (just like in macOS).

Then I started up Sigil and it fired up in dark mode just fine with no issues I could detect.

So on Manjaro Linux, all appears to just work.

I agree if we just want to move the Tweak Drag Distance to an environment variable, that will free up space for the Double Cursor Width setting with no extra changes.

@DiapDealer, if you agree, and get a free moment would you move the tweak drag distance to an environment variable and add the double width cursor (and SettingsStore stuff)?

Thanks.

[DiapDealer]

Originally Posted by KevinH

@DiapDealer, if you agree, and get a free moment would you move the tweak drag distance to an environment variable and add the double width cursor (and SettingsStore stuff)?

Will do. I might be a little busy this week, but I will see what I can do.

For the record, I made some quick changes to see what the default windows qt dark mode would like like (starting with Qt6.5). It doesn't actually completely suck!

If anyone would like to play, I'm including the down and dirty patch (only a handful of lines changed) to main.cpp to allow it to work. There's a mass of nasty nested ifdefs there that I didn't feel like untangling just to test it out.

Note that it's required to launch sigil with the "-style fusion" command line option to get it to work. Might be that a few color tweaks here and there would make it go.

--- a/src/main.cpp	Mon Apr 15 11:32:45 2024
+++ b/src/main.cpp	Mon Apr 15 11:17:06 2024
@@ -481,7 +481,7 @@
             }
         }
         if (!darkmode_arg_exists) {
-            current_platform_args.append("darkmode=1");
+            current_platform_args.append("darkmode=2");
         }
     }
 #endif
@@ -599,12 +599,14 @@
 #else
         if (Utility::WindowsShouldUseDarkMode()) {
             // Apply custom dark style
-            app.setStyle(new SigilDarkStyle);
+            //app.setStyle(new SigilDarkStyle);
+            ;
 #if QT_VERSION <= QT_VERSION_CHECK(5, 15, 0) || QT_VERSION >= QT_VERSION_CHECK(6, 5, 0)
             // At this point, I have no idea where along the 5.15.x series this
             // being present will break dark mode. I only know the first official
             // official windows version that uses 5.15.9 needs it to be gone.
-            app.setPalette(QApplication::style()->standardPalette());
+            // app.setPalette(QApplication::style()->standardPalette());
+            ;
 #endif
         }
 #endif

[BeckyEbook]

Indeed – it is not tragic.
However, a few elements in dark mode are still annoying (e.g. those bright lines under toolbars, not clear dock/close icons, overly bright controls, and widget backgrounds, this is especially noticeable in Preferences).

Of course, someone might consider this too subjective.

Just the dark default background in fusion mode is probably acceptable, and if it doesn't suit someone, it can be tweaked via qt_styles.qss

Might be that a few color tweaks here and there would make it go.

I am of the same opinion.
We can simply slim down the current win-dark-style.qss file a bit.

Edit: qt_styles.qss not working?

[DiapDealer]

Originally Posted by BeckyEbook

Edit: qt_styles.qss not working?

Not sure. I really haven't had a chance to explore much. I don't think anything in my patch shouldn't have affected that, but I could be wrong. Setting the fusion style on the command line might change the order of things, compared to where our Sigil SigilDarkStyle did it.

[BeckyEbook]

I played with it for a while.
Overall – our implementation of dark mode a few years ago was done very well aesthetically and I just enjoy working in Sigil every day.

This test build somehow doesn't support qt_styles.qss (your guess about the -style fusion parameter overriding the order in which styles are applied may be true), and it looks like we're going back to a time before the dark mode implementation.

If we are aiming for Windows to use automatic system mode detection and automatic switching then OK, but once dark mode or 'auto' mode (apply system style) is detected it is best to keep our tweaks for dark mode (if possible).

[DiapDealer]

I like ours a lot better too. I'm just not sure If we can keep it AND do automatic switching at the same time. To even consider letting Qt handle everything, I'd want to make sure overrides via qt_styles.qss can still work. Losing that customization ability just isn't an option in my opinion.

But it's early days. I'm also very accustomed to the look of the current Windows dark mode. I'm not sure I could ever abandon supporting it in some form or another.

[KevinH]

The issue with stylesheet may be caused by Sigil/src/Misc/SigilDarkStyle.cpp which does the following:

void SigilDarkStyle::polish(QApplication *app) {
    if (!app) return;

    // loadstylesheet
    QFile qfDarkstyle(QStringLiteral(":/dark/win-dark-style.qss"));
    if (qfDarkstyle.open(QIODevice::ReadOnly | QIODevice::Text)) {
        // set stylesheet
        QString qsStylesheet = QString::fromLatin1(qfDarkstyle.readAll());
        app->setStyleSheet(qsStylesheet);
        qfDarkstyle.close();
    }
}

Everywhere else we effectively do:

app.setStyleSheet(app.styleSheet().append(NEW_STYL E_INFO))

which prevent overwriting of any earlier stylesheet info at the application level.

We should probably change that to be safe to prevent overwrites of stylesheet contents.

[DiapDealer]

Noted. That's a good idea. But I'm currently bypassing SigilDarkStyle entirely with my testing patch. So still not sure why our built-in qt_styles.qss (automatically loaded from the user preferences location at Sigil start) is not working after my patch.

[DiapDealer]

Hmmm... when launched without the "-style fusion" command line option, the qt_styles.qss feature is also not working. So either my patch breaks it some way I cannot fathom, or it was broken before I patched.

[KevinH]

Not good. Maybe I broke it with my last push.

I will test it on my machine.

[KevinH]

Okay tested it with a red focus highlight done only via qt)styles.qss and it worked on my Linux Manjaro machine.

So it should work on yours unless an ifdef or endif was changed.