Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow the gui-daemon background color to be configurable #9304

Closed
Euwiiwueir opened this issue Jun 14, 2024 · 6 comments · Fixed by QubesOS/qubes-gui-daemon#144 or QubesOS/qubes-core-admin-client#295
Closed

Allow the gui-daemon background color to be configurable #9304

Euwiiwueir opened this issue Jun 14, 2024 · 6 comments · Fixed by QubesOS/qubes-gui-daemon#144 or QubesOS/qubes-core-admin-client#295
Assignees
@Euwiiwueir
Labels
C: gui-virtualization P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience

Comments

@Euwiiwueir
Copy link

How to file a helpful issue

The problem you're addressing (if any)

This is an outgrowth of this forum thread:

https://forum.qubes-os.org/t/suppressing-the-white-flash/26829

I've filed this as an enhancement but it's a mitigation of a usability bug that affects some proportion of users.

Context:

When VM window content is not immediately available to dom0's X, but something must be displayed in the dom0 passthrough window for that VM window, the gui-daemon falls back to filling this unavailable content with a hardcoded background color.

Examples:

  1. A domU window is resized on dom0 and hasn't yet been redrawn by the VM.
  2. The user switches to another workspace which triggers redraws of domU windows placed on that workspace and the passthrough windows are displayed before the redrawn domU content is available. (I am supposing here this is the event flow.)

This display of the hardcoded background color is usually quite transient, milliseconds, but is briefly visible to the user.

Problem:

The background color is hardcoded to white. If the user is running a dark color theme on their desktop, a window's brief flash of bright white is visually uncomfortable, especially if it happens frequently. Especially especially if the window is large or full-screen.

In my own workflow I switch between workspaces very frequently, which means quite frequent white flashes.

The solution you'd like

Allow the gui-daemon background color to be black instead of white. I patched my gui-daemon to use black and for me it's been a complete mitigation of this usability issue. Users who run a bright desktop theme probably would prefer the current white, though. Therefore the background color should probably be configurable.

marmarek outlines the shape of that work here:

I guess it has to do with “background pixel”:

https://github.com/QubesOS/qubes-gui-daemon/blob/main/gui-daemon/xside.c#L332

If somebody wants to play with it, it should be quite easy to change it and see if it helps. For example there is similar BlackPixel function. Making it configurable should also be possible, but it’s going to be a bit more work (add config option to gui-daemon, fetch it from the config file there, and then add support for setting this option via features in core-admin-client).

My instinct is that an option of black or white is good enough; allowing the color to be an arbitrary hue perhaps grants this issue more attention than it deserves. Also, the implementation is simpler. But I defer to others.

The majority of the work of the implementation will be the plumbing to propagate the color choice to gui-daemon/xside.c.

The value to a user, and who that user might be

Better usability/comfort for users like me who use dark styling.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)
@Euwiiwueir Euwiiwueir added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. labels Jun 14, 2024
@Euwiiwueir
Copy link
Author

A couple related issues:

  1. Flickering screen when switching windows in i3 #2391

  2. Make tray icon background color transparent instead of white #2846

(1) I think is probably the same underlying issue I'm describing, though for me the choice (or absence) of a compositor does not materially help.

(2) Is distinct but similar.

@Euwiiwueir
Copy link
Author

Lastly, I'm willing to implement this myself if the proposed solution sounds ok.

@marmarek
Copy link
Member

Allow the gui-daemon background color to be black instead of white.

Sounds good

Euwiiwueir added a commit to Euwiiwueir/qubes-core-admin-client that referenced this issue Jun 22, 2024
@Euwiiwueir
qvm-start-daemon: expect gui-window-background-color
56ab8ce 
Look for these features as settable by qvm-features:
- gui-window-background-color
- gui-default-window-background-color

Translate them into the window_background_color setting in the
configuration file generated for qubes-guid.

Related to: QubesOS/qubes-issues#9304
Euwiiwueir added a commit to Euwiiwueir/qubes-gui-daemon that referenced this issue Jun 22, 2024
@Euwiiwueir
Factor out a function to parse color from string
7e85df2 
Also add some minimum effort error checking/correction as this will soon
be processing a user-entered value. The extant code path should not be
affected as input color values are correctly specified.

Color values can be words or hex values.

Accepted:
- 'black'
- 'white'
- 'blue'
- 'dark blue'
- '0x0000ff'

Rejected with logged error + exit:
- 'nonsense color'
- '0xZZZZZZ'

Related to: QubesOS/qubes-issues#9304
Euwiiwueir added a commit to Euwiiwueir/qubes-gui-daemon that referenced this issue Jun 22, 2024
@Euwiiwueir
qubes-guid: add window_background_color setting
51399c3 
This configuration setting allows changing the background pixel for
local windows that display content of VM windows. Generally the color is
only visible rarely and briefly. Previous to this commit the color was
hardcoded to white which is suboptimal for users running dark desktop
styling.

This is the downstream translation of these VM features:

- gui-window-background-color
- gui-default-window-background-color

Testing process:

  [user@dom0 ~]$ qvm-features dom0 gui-default-window-background-color <color>
  [user@dom0 ~]$ qvm-run --dispvm=default-dvm --service qubes.StartApp+debian-xterm
  # (Then play with the terminal's window to expose the color)

Related to: QubesOS/qubes-issues#9304
This was referenced Jun 23, 2024
Merged
Merged
@Euwiiwueir
Copy link
Author

PRs submitted.

@andrewdavidwong andrewdavidwong added the pr submitted A pull request has been submitted for this issue. label Jun 24, 2024
@Euwiiwueir
Copy link
Author

Thanks for accepting the patch. I'm really pleased to have this fixed.

This was referenced Jul 5, 2024
Closed
Closed
@Euwiiwueir
Copy link
Author

Is it in the cards this patch could make its way to r4.2? I can maintain my own patched 4.2 rpms until 4.3, but I am curious.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Euwiiwueir Euwiiwueir

Labels
C: gui-virtualization P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience
Projects
None yet
Milestone
No milestone
3 participants
@marmarek @andrewdavidwong @Euwiiwueir