Skip to content

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

@Euwiiwueir

Description

@Euwiiwueir

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.)

Metadata

Metadata

Assignees

Labels

C: gui-virtualizationThis issue pertains to GUI virtualization in Qubes OS.P: defaultPriority: default. Default priority for new issues, to be replaced given sufficient information.pr submittedA pull request has been submitted for this issue.targets-4.3Feature planned for Qubes 4.3. Remove label if not implemented by release; leave if implemented.uxThis issue pertains to the user experience (UX) in Qubes OS.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions