Desktop Customization (xfce)

indolering · December 21, 2020, 1:04am

I’m all for hacks being discussed in the forum, but please keep GUI customization out of the main website. Linux GUIs are the source of endless bikeshedding.

deeplow · December 21, 2020, 6:47pm

It’s already out. Notice the documentation links about customization now redirect to the community external documentation

Reason for that:

github.com/QubesOS/qubes-issues

Split Qubes docs into "core" and "community" docs

opened 09:55AM - 07 Jan 19 UTC

closed 12:37PM - 08 Dec 20 UTC

ghost

T: enhancement C: doc P: default

This will likely be a controversial topic, but let's float the idea. tl;dr; i…mho it would make sense to split the docs into "core", well-reviewed, security-sensitive docs, and "community" reviewed docs that are more "peripheral" to Qubes. This should help: - increase the number of first-time contributors - who could then become regular contributors to the project - help contributors with doc guidelines and improve the quality of the docs overall; the "community" could be used as a staging area similar to the staging branch of the linux kernel - lower @marmarek 's workload - increase (and make easily found/searchable) the number of docs/resources related to Qubes OS's usage. [EDIT] An alternative would be to leave the docs as-is, and put links to "community" resources somewhere in the official docs. --- Issues with the current docs: - the PR submission process isn't easy for git noobs. At least it wasn't for me - I had to learn git only to be able to improve the docs, it did require time and motivation, hopefully that was at a time when I could spend more spare time on Qubes than I do now. That's likely not the case for most users, some of them who could have provided helpful improvements but are/were put off by the seemingly convoluted process. (Sure, once you know git it is easy but then not everyone knows git nor is interested in learning it). - @marmarek is more or less the only technical reviewer of doc PRs nowadays and his workload makes him a bottleneck; PRs can stay for weeks/months before being accepted. That can be a bit discouraging for users who have put some time in trying to improve the project. (to be clear I'm not complaining - just stating what I see). - some official docs have nothing to do with Qubes and clutter the doc ToC. The [Qubes Community](https://github.com/Qubes-Community) project [tries to solve](https://qubes-community.github.io/) (some of) the issues above. The project is very slowly getting some traction but judging by questions asked on the ML and issues which are already answered in details in docs in the project, most people aren't aware of this effort. There are also great third party resources (eg @tasket 's contributions, @unman 's repositories, ...) that users aren't aware of because they're not advertised anywhere in the official site - and rightfully so, because that could give a false sense of endorsement and/or security. Having links to those resources in a "community" resources page, with the usual disclaimer, would definitely increase the visibility of such efforts. Given all of the above, wouldn't it make sense to have only a small amount of "core" official docs that are carefully reviewed by the Qubes team and thus have a higher "security trust level", and have a Qubes endorsed community doc project (not necessarily the one mentioned above), administered by proficient/long-time qubes users - maybe picked by the Qubes team - where the submission rules/quality would be relaxed, and where it would be clear for users that those community docs have a lower "trust level" ? As noted above, this would: - allow people not familiar to git to contribute stuff, and maybe learn git in the process until they're confident enough to send PRs (both the the community and official docs). - allow people to contribute lower quality/incomplete/... *but helpful* docs (eg. specifics of installing [whateverOS] as a qube VM). - streamline the official docs structure (and thus making it easier to parse) by keeping only the documentation specific to Qubes OS, on which the community docs are based. Some of the existing docs could me moved - eg. configuration of OSes in (H)VMs, XFCE/KDE features that aren't specific to Qubes, DPI in VMs, setting a dark background, etcetera. Thoughts ?

indolering · December 22, 2020, 8:14am

Yeah that’s fine, community docs are designed to house stuff that doesn’t make the cut in terms of quality.

deeplow · December 22, 2020, 11:06am

Not at all (sometimes that is the case because there isn’t someone full time like @adw to maintain them. It’s all volunteer run, but the difference is basically:

The main difference between core (or official) and external (or community or unofficial) documentation is whether it documents software that is officially written and maintained by the Qubes OS Project. The purpose of this distinction is to keep the core docs maintainable and high-quality by limiting them to the software output by the Qubes OS Project.

Taken from here: Core vs. external documentation

Anyways. This just to mention that yes, how do customize Qubes aesthetics-wise belongs to the Qubes Community Docs.

Sforg · February 21, 2021, 12:07am

Hello! Customization of my workspace is important for me, so I’m glad of discover this topic. In the past distros that I’ve used, for put in the tray softwares without the option (e.g., thunderbird, zotero, signal) I usually employed kdocker that works perfectly, at least in KDE distro.

Now on Qubes, obviously it doesn’t work installing it in a TemplateVM, but install anything in dom0 open same old concerns.
In your opinion, There’s a similar way to minimize in tray any software’s windows here? Install a similar program on dom0 may lead to issue and lack of security? There’s an XFCE alternative, as I’m running this environment now?

I apologize if it’s a yet discussed topic. Thanks in advance!

deeplow · February 23, 2021, 10:08pm

4 posts were merged into an existing topic: Way of minimizing applications onto system tray

sebuq · March 20, 2021, 10:52am

Cute cube icons included in 4.1 release. I want to change icons in a 4.0.4 release. Is there any file to install and copy it to the images in dom0 domain or do I have to configure it differently?

h110w · July 22, 2021, 1:45pm

I noticed you can right click on a downloaded wallpaper in a disposable vm and select “convert to trusted”, once this is done can anyone confirm if it is safe to copy the trusted image to dom0?

unman · July 22, 2021, 3:26pm

I noticed you can right click on a download wallpaper in a disposable van and select convert to trusted, once this is done can anyone confirm if it is safe to copy the trusted image to dom0?

It is. I prefer to use the “full screen and screenshot” method, since
this is entirely within dom0.
There’s also qvm-get-image which will convert to trusted and copy to
dom0.

deeplow · July 22, 2021, 4:05pm

Wow. How is this not documented anywhere?

unman · July 22, 2021, 4:25pm

unman:

There???s also qvm-get-image which will convert to trusted and copy to dom0.

Wow. How is this not documented anywhere?

Just to blow your mind, you can convert files automatically by
specifying format, and
qvm-get-tinted-image will (obviously) tint the image for you as well.
Good if you need a red wallpaper, for example.

adw · July 22, 2021, 6:18pm

Never heard of either of these!

deeplow · July 22, 2021, 8:44pm

Mindblown. This absolutely needs to go into the docs. Otherwise they go unused.

I guess I’ll subscribe the commit’s rss feed not to miss anything. Haha.

Scumbag · May 7, 2022, 2:58pm

Does anyone know how to change the window title font color? If I go to System Tools → Window Manager I can change the font and size, but not color.
On Qubes R4.0, the window title font was white. After upgrading to R4.1, it is black (except dom0 windows). The black is harder to read and looks ugly.

tzwcfq · May 7, 2022, 3:08pm

https://forum.xfce.org/viewtopic.php?pid=27791#p27791
UPD:
This doesn’t work, the colors seems to be hardcoded.

enmus · May 7, 2022, 7:13pm

How to change window title color of untrusted (red) qubes?

whoareyou · May 7, 2022, 11:46pm

I got similar problem, it only works on Dom0, but not on other DomUs unless the color label is black.

Scumbag · May 12, 2022, 12:27pm

There is an issue about it:

github.com/QubesOS/qubes-issues

[Regression?] Font color for titlebars black regardless of titlebar color, xfwm theme chosen, etc; significantly harder to see than prior versions

opened 05:41AM - 07 May 20 UTC

GSF1200S

T: bug C: desktop-linux ux r4.0-dom0-stable P: default

**Qubes OS version** Qubes 4.0 **Affected component(s) or functionality** x…fwm4.x86_64 1000:4.12.4-2.fc25 I did not have this problem until the above package dropped in my system May 6th, 2020. **Brief summary** When opening a terminal, xfce4 settings, qube manager, etc on dom0, the text color reflects the theme you've chosen for the window manager. You can go into the themerc of the style you are using and change the active font color if you want... and the change will be reflected in a [Dom0] window. For my case, I use the Bluebird theme. No change to active text color above has any effect on windows not [dom0]; worse, the contrast is often terrible. For purple, orange, yellow, green, red, and blue titlebar colors, the titlebar text is black when active and dark gray when inactive. This is much more difficult to see then it used to be in the past. For black titlebars, the text is white or very light gray; by default black is the color of TemplateVM and Vault titlebars. **To Reproduce** As above... **Expected behavior** Active titlebar text should be the same between dom0 and AppVMs. **Actual behavior** Active titlebar text is not the same between dom0 and AppVMs, and the contrast is often poor. It is not the same even with, say, similar titlebar colors e.g. both blue. **Screenshots** I dont think this is necessary, but if so I will post one for you. **Additional context** The only reason I'm filing this bug report is that it is extremely annoying from a usability angle... especially when the screen is in direct sunlight. Contrast is a good thing- a darker orange and a bright white contrast better than a darker orange and black. It forces me to get right up on the screen to read the titlebar text. **Solutions you've tried** I tried changing themes, and moving Bluebird theme gtkrc into my user's .config/gtk-2.0 directory. I don't know what else to try... I can get dom0's windows to have the active font color I want in the titlebar by changing the themerc, but it has no effect on any other windows (TemplateVMs, AppVMs, etc)

Scumbag · May 12, 2022, 12:39pm

A note for people who prefer the standard menu over the whisker menu:
In Qubes R4.1, I just tried to set the “windows key” to pop-up the menu.
When searching for instructions, I found that the shortcut should be:
xfce4-popup-applicationsmenu
Instead of:
xfce4-popup-whiskermenu
However, that did not work for me. When I did that, it opened the same menu that you get when you right-click on the desktop. That menu does have the list of applications in the bottom item, however, that is of course an extra step and it doesn’t open in the location of the Q menu button.

/usr/bin/xfce4-popup-applicationsmenu
Does work however. It is the same command, not sure why it behaves differently when you add the file path though.

Scumbag · June 29, 2022, 1:54pm

Window title font is white again instead of black