Light app when prefer dark is off

When the system-wide prefer-light switch is off the app is light for me now, which results in this very weird light chrome:

I can sort of see why someone might want the rest of the app to follow the system (seeing as it's not really visual content), but the chrome around the VM itself should definitely stay dark.

changed the description

#788 (comment 1439528)

As pointed out above, I think the primary app UI including preferences, grid view, etc. are fine to follow the preference, but the chrome around the actual VM should always be dark, otherwise it draws way too much attention.

I disagree. With the guest OS being in any state imaginable, picking the black boot will of course paint a favorable picture for the dark chrome. However with many preferring a light chrome, we didn't provide an easy way to opt in to the light chrome.

picking the black boot will of course paint a favorable picture for the dark chrome

I mean it's the same as any other type of visual content. It doesn't matter whether the content is light or dark, it's about providing a neutral frame around it, and dark is just better for that.

Screencast_from_03-05-22_17_01_03

What do you folks think of the transition between one color-scheme and the other?

cc @jimmac

Works for me!

Looks rather abrupt. I'd suggest to avoid doing this and revert to dark by default until it's using GTK4 and libadwaita. At that point it can be done smoothly without switching global color scheme.

Another reason not to do this: we have a multi-window mode. You cannot have a light collection window and a dark VM window, it's all or nothing atm. Again, later it can be fixed, but not yet.

This dynamically changing approach is odd. If you're going to insist that light chrome for Boxes is a poor choice, the only way to reconcile light-preferring crowds and the good old dark default is to expose the selector in the app, ala Apostrophe:

It's not odd if it's properly implemented. Which is impossible in GTK3. Look at e.g. media viewer on Telegram on iOS and Android - it's dark and it's all perfectly nice. We can do that just fine in libadwaita.

Which is why I'm suggesting to revert it for now and only do it once it's GTK4 - then it can work well.

Screencast_from_11-05-22_22_36_08

An example of how it can look like in that case. But again, this needs GTK4 first.

That does look sleek.

Created some less deceptive screenshots of actual running sessions and VM grid for next week's call:

Not maximized and surrounded by a light wallpaper == even more deceptive, sorry.

How about this:

I never use Boxes unmaximized on this screen. That's the only viable way to use it on fullhd or smaller screens (in logical pixels, so this is fullhd@2).

The most striking part of your Ubuntu guest screenshot for me is the GNOME Shell top bar. A light top bar may help there.

If the Appearance > Style became a tri-state: Light, Default, Dark, then I think people would generally be ok with Boxes being Dark by default. I think #788 (closed) was filed because of the GNOME 42 Light/Dark setting.

And I think with that tri-state, then apps generally don't need to offer their own dark/light/default switcher. Maybe app developers have only done that because the GNOME Settings weren't complete enough yet.

The most striking part of your Ubuntu guest screenshot for me is the GNOME Shell top bar.

Not at all, I have a dark bezel around the screen, so this panel is effectively invisible.

The problem here is not the contrast between the panel and the header bar, it's that the window UI is overshadowing all of the content by a large margin. That would be even worse with a light panel.

It's the same exact reason as why everyone does dark image viewers etc. Depending on what's around the screen it can be downright painful to look at a single light element around content.

Have you seen #791 (comment 1449991)?

Not at all

Different people see different things. I see the light app headerbar sandwiched between 2 dark Shell top bars.

Fullscreen the screenshot before viewing then.

There's an upcoming UI freeze next week (beta release), so that's the window we have to flip the switch on this for gnome-43.

I mean I'm still proposing the same thing: revert it for 43. There's no way to make the dynamic thing work in GTK3 (with "Open in New Window" in particular), and there's no GTK4 port in sight, so...

+1, the actual VM view, usually maximized/fullscreen, is where people spend most of the time in this app. Dergrading that experience for the sake of maybe improving less important parts of the app is backwards to me.

mentioned in commit b43d670e

mentioned in merge request !535 (merged)