Am Fr., 7. Juli 2023 um 15:25 Uhr schrieb Thibaut Cuvelier: > Qt hasn't changed its -style parameter at least since Qt 4 (2005), that's > quite stable (there is also an environment variable, QT_STYLE_OVERRIDE). > I couldn't find any way to tell if the style was set from the command line > or not (or to get the default style for the current platform), so we would > always need to check manually whether there has been some CLI-set style, > whatever path we end up taking. >
>From what I understand Qt has some style picking priority when creating the QApplication. https://stackoverflow.com/questions/48093102/how-does-qt-select-a-default-style (There is some precedent with locale handling, where Qt is trying hard to > impose its locale, it seems.) > (More details: the -style parameter is dealt with in > QGuiApplicationPrivate, not accessible from LyX and not available anywhere > in the API, as far as I can tell.) > > As Qt can dynamically change the style at runtime, why would you need to > know it when instantiating GuiApplication? Anyway, in my patch, the style > is set before calling QApplication::exec, before any user interaction can > take place, the user should not see any difference in delay before > interacting with LyX. > Your patch basically disables the "-style" CLI argument, because it sets (overwrites) the style *after* QApplication is created. My patch sets the style *before* QApplication is created, this style is then used by Qt when creating QApplication. If the user passed -style argument however, QApplication is created using that argument instead, because of some priority rules (I think it should be similar with the environment variable). But if you set the style after creation, those rules don't apply, it just sets the style on the existing QApplication. So 1. your patch would need to implement that priority rule(s) by its own instead of letting Qt handle it and 2. frontend::Application * createApplication(int & argc, char * argv[]) removes all the arguments it knows so the -style argument is not present anymore when your patch sets the style, so additionally you would need to read that argument before createApplication (here we go again), save it and then do task 1 afterwards. > > I have no opinion on whether the LyXRC file should be read before or after > createApplication, I have no idea about the trade-offs here. What do others > think about it? This change may impact other platforms too. > Yeah we need other opinions on this. > > Anyway, it works as expected. > > >> Also note that in the patch I have set "fusion" to default on Windows, >> other OSes can do it the same way if they want. >> > > Fusion doesn't look native at all on any platform by design > <https://www.qt.io/blog/2012/10/30/cleaning-up-styles-in-qt5-and-adding-fusion>, > but it's the only not-too-terrible choice for dark themes on Windows :/. I > would do either of the following: let Qt handle the default theme or only > impose the strange Fusion style on users when we know it's the least worst > for users. The idea is to have a good default for users, with LyX being as > native-looking as possible --- a goal that is currently achieved, albeit > the support for dark themes on Windows is really subpar (like many Windows > apps). > To be honest I think that the fusion style looks much more native on Windows 11 than the windowsvista style. > > Actually, I'd be OK with merging this patch with a change in the way the > default theme is selected. > -- Eugene
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
