yuzu icon indicating copy to clipboard operation
yuzu copied to clipboard

Linux: handle dark system themes nicely

Open Docteh opened this issue 1 year ago • 7 comments

yuzu's default theme doesn't specify everything, which is fine for windows, but in linux anything unspecified is set to the users theme.

Symptoms of this are that a linux user with a dark theme won't think to change the theme to a dark theme when first using yuzu

Idea here is to try and support arbitrary themes on linux.

preliminary work on a "default_dark" theme, used only as overlay for any themes that are measured to be dark mode.

Other work done:

FreeDesktop standard icon names: plus -> list-add delete refresh, we use view-refresh

remove duplicated icons for qdarkstyle_midnight_blue referencing icon aliases in the qrc files is the way to go

Note: Dynamic style changing doesn't appear to work with AppImage


I'm not sure where to put the GMainWindow::check_dark_mode function, maybe it belongs lower in the file, same with location of the additions to main.h

Long term the themes should be split into two parts, regular Qt theme, and yuzu specific

fixes #8643

Docteh avatar Jul 26 '22 13:07 Docteh

image

Looks like on Linux we're grabbing icons from the theme, which is fine, but there is no fallback to explicitly grab icons from the program. #8339 might be of reference

When showing the gamelist I see two errors about QPixmal::scaled: Pixmap is a null pixmap Is one or both the plus icon, time will tell.

Docteh avatar Jul 26 '22 13:07 Docteh

#7755 is also of reference. Turns out the default is to use the colorful icons, nobody told the UpdateUI function I've been staring at, if given an invalid theme it'll actually fall back to default instead of colorful/colorful_dark

AppImage on Default, note the total lack of icons. image

If I don't actually set the icon theme to "default" when using "default" image

Path A: just ignore this for now. For QIcon with its themeName and themeSearchPaths it looks like it finds

Path B: conform to FreeDesktop icon naming, because QIcon::fromTheme actually intends to get icons from a theme

star -> rating, example from oxygen rating or maybe user-bookmarks

plus -> either folder-new or list-add chip -> cpu sd_card -> media-flash

https://commons.wikimedia.org/wiki/Comparison_of_icon_sets

Path C: Essentially re-implement a form of QIcon::fromTheme that runs after checking QIcon::hasThemeIcon

Path D: Leaning towards this one, just use yuzu's icons, and ignore the desktop icons.

// In src/yuzu/main.cpp GMainWindow::UpdateUITheme
    QIcon::setThemeName(current_theme);
    QIcon::setThemeSearchPaths(QStringList(QStringLiteral(":/icons")));

TL;DR of this comment, looking at QIcon::fromTheme I don't believe we can use this function to grab icons from the users theming, and grab icons from internal themes at the same time.

Docteh avatar Jul 27 '22 14:07 Docteh

@Tachi107 I've been meaning to ask, if I make a copy of say dist/qt_themes/default/style.qss do I mark leave the year 2018 in the copy, or make it 2022?

Docteh avatar Jul 29 '22 10:07 Docteh

@Docteh I believe that if you make a copy the same copy-right year applies :)

Tachi107 avatar Jul 29 '22 10:07 Tachi107

image Appllication Style: Breeze Icons: Buff-plasma Color Scheme: DarkRed_0-4

Docteh avatar Jul 30 '22 03:07 Docteh

In the last image, DOCKED fell back to the text color, but NEAREST and NO AA are grey. I've found that colors can be specified to be palette(text) for consistency. Also grabbed the brighter colors for the VULKAN/OPENGL and GPU HIGH/GPU NORMAL image

image I'm going to wait for the AppImage to build, see if the dotted lines in the QTreeView are there. Otherwise this is a sensible image of the PR, showing a mainline build vs what the PR does.

Docteh avatar Aug 05 '22 14:08 Docteh

AppImage generated by this PR image

Docteh avatar Aug 05 '22 23:08 Docteh