> Another easy thing I think we could add to QPalette is the set of (16?) most-common colors. That way, when an application really wants something to be blue, it could use QPalette:Blue, and the theme would be able to control the brightness and the exact shade of blue.
A good benchmark for this would be to check how it would work with the Base16 theming framework, based on 16 colors : https://github.com/chriskempson/base16 ; they can be checked there : http://chriskempson.com/projects/base16/ There's also Kvantum which is a SVG theme engine for Qt (examples: https://store.kde.org/browse/cat/123/) ; it would be nice to have it integrated to Qt directly maybe ? And then use a GPU-based SVG renderer to only have to do the GPU work once (how far is QtQuick.Shapes from rendering full-fledged SVG ?). Best, Jean-Michaël ------- Jean-Michaël Celerier http://www.jcelerier.name On Fri, Jul 6, 2018 at 10:50 AM, Shawn Rutledge <shawn.rutle...@qt.io> wrote: > > > On 4 Jul 2018, at 16:19, Morten Sørvig <morten.sor...@qt.io> wrote: > > > > Hi all, > > > > macOS 10.14 is now in (public) beta and we've had some time to test Qt > on it. > > > > ... > > Dark appearance: In theory, applications should pick up the dark > appearance via > > the style and palette. In practice, they may not due to incomplete/buggy > QPalette > > and QMacStyle implementations, or hardcoded colors in Qt or the > application. > > > > The current state of the patches for dev/5.12 is that custom-styled > applications > > can work well in dark mode, for example Qt Creator with a dark theme. > > > > The plan is to disable dark mode support by default in Qt, at least until > > QMacStyle is fixed. This means that applications will start up using > standard > > Aqua theme/colors, also when the desktop is configured for dark mode. > > > > The application has the final call here, and can opt in or out by > setting the > > NSRequiresAquaSystemAppearance key in the Info.plist file. For example: > > > > <key>NSRequiresAquaSystemAppearance</key> > > <false/> > > > > will indicate that the app _does_ support dark mode, and Qt will get out > > of the way and not apply its disable. Setting it to true will insulate > the > > app against any changes in the Qt default. > > I would like to see this feature as a cross-platform feature rather than > mac-specific. > > I missed that news about Apple until now, but I had the idea a few years > ago anyway that there should be an easy global switch (always within reach, > not having to paw through system settings) to toggle quickly between light > and dark themes. There was the first time I started up my laptop on a > plane while other passengers were trying to sleep, and got some dirty looks > because I didn’t have much control over the brightness (the laptop’s > backlight level couldn’t be reduced enough, and it took some time to open > up the system settings and switch themes, and then I think I had to log out > and back in again too. Creator didn’t have themes at all back then.) And > there was a consultancy customer a few years ago who planned to have themes > with different brightness levels in an embedded application, but AFAIK they > still haven’t gotten around to it, maybe because we didn’t make it > particularly easy in Qt Quick. And actually I tend to switch themes at > least seasonally: if there’s a lot of sun and I’m trying to hack while > riding the metro, I can’t see well enough if the theme is too dark, but > otherwise I like using a dark theme in darker conditions. So it’s been > annoying me for years that most applications can’t easily switch (they tend > to make up for lack of system-wide settings by having their own instead), > and some desktop environments have inconvenient controls, and/or the theme > changes don’t necessarily propagate to all apps at once. > > But now that Apple is finally doing something, I think the copycats are > inevitable, so I fully expect to see news that an identical or better > feature is coming soon to KDE and/or Gnome any day now. For now there’s > just “redshift", it seems. But IMO having a lot of white space that has > gone dingy in the dark is not as nice as having a theme that looks good > without having so much white in it. And so far Apple didn’t put the switch > in the menubar, but I suppose that’s probably inevitable too: a utility > will probably show up in the app store, if there’s an API to make it > possible. > > Anyway, to the extent that widgets and controls are drawn with QPalette > colors, switching the palette globally ought to be easy; and we have > QEvent::PaletteChange, so applications have already been able to respond > quickly to system-wide palette changes for ages, right? But there’s the > trend of using image-based styles more, which contributes to the annoyance > that you don’t actually have system-wide control over colors and styles. > So it just becomes more work for widgets, controls and applications to have > both sets of images, in addition to having different resolutions for > high-dpi support, whenever they are built that way. > > The default Fusion widget style still has hard-coded colors, by the way. > I wanted to fix it, but ran into resistance about using QSettings for that, > and yet no other solution has been forthcoming either. > > One of the contributing reasons that _we_ use images more is probably > because of the perception that a GPU is best used as a texture-flinging > device, because it's not so good at drawing vector graphics. (So much so > that Shapes are a really recent addition, while Canvas and QtSVG continue > to use QPainter to render to a texture.) That’s always been unfortunate > from my perspective… _our_ use of today’s gaming-oriented GPUs still hasn't > advanced the state of the art in 2D since the 1980’s, unless you use > vendor-specific stuff like NV_path_rendering, or if you draw aliased > graphics and then apply (expensive) global antialiasing techniques like > MSAA. (But I continue to believe it’s possible to do better than that. > Especially now that we have Vulkan.) You can write smarter shaders, but > then you need a diversity of shaders, and that breaks batching in the scene > graph. That’s just wrong IMO. Fixing that somehow would enable us to go > back to having styles that use vector graphics and therefore can respond to > changes in the palette. But another way is to use a fragment shader to > switch specific colors on the fly. I did this with my PDF viewer, to make > it possible to read “white papers” in the dark: it inverts black and white, > but leaves color images intact. It could at least be a workaround for > applications that use too many images. > > Another easy thing I think we could add to QPalette is the set of (16?) > most-common colors. That way, when an application really wants something > to be blue, it could use QPalette:Blue, and the theme would be able to > control the brightness and the exact shade of blue. (The color of blue > that is default on a white xterm is nowhere near the one you want if your > terminal is black.) So you could easily "solarize" your whole desktop, if > that’s your thing, even while applications retain control over the general > hues. Then terminal applications, editors that have syntax highlighting, > and such things would be able to use those colors. The settings to define > each of those would be global, and the need for e.g. Konsole and Creator to > have their own independent sets of themes for text highlighting would go > away. (Although, Creator would still need settings to map highlighting > classes to QPalette colors: e.g. comments are green and keywords are blue, > or whatever.) So they too would respond to global theme changes. > > There is talk of rearchitecting QStyle in Qt 6. IMO this is a very > important feature we should take into account. > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
