Difference between revisions of "Talk:Xfce"

From ArchWiki
Jump to: navigation, search
(XFCE and GTK3 Theme: re)
 
(115 intermediate revisions by 14 users not shown)
Line 1: Line 1:
== A bit Outdated ==
+
== Lock screen on suspend ==
  
The wiki page is a bit outdated, nothing serious though. I'll fix once I get some free time, unless somebody is faster than me.
+
[[Xfce#Lock the screen]] gives an introduction to screen locking, but I can't get it to work with xfce4-power-manager on resuming from suspend. I've found little on this [https://bbs.archlinux.org/viewtopic.php?id=180985] [https://www.reddit.com/r/archlinux/comments/2eyt80/xfce_slock_not_locking_screen_when_suspending/] and an old bug for Xfce 4.8. [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738124]. Locking via {{ic|Ctrl+Alt+L}} works as expected (slock). Can others reproduce, and if yes, should I investigate further and file a bug upstream? Perhaps this could be related to the light-locker transition (where I use [[xinitrc]]). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:52, 13 July 2015 (UTC)
Untill then: tha base package has changed, it includes tumbler and thunar-volman.
+
: This functionality works fine for me but I use {{Pkg|gnome-screensaver}}. This might be an issue for specific screen lockers as opposed to a general Xfce issue. I notice that there is an alternative "lock screen before sleep" option under ''Applications'' -> ''Settings'' -> ''Session and Startup'' -> ''Advanced''. Perhaps that works where the xfpm option does not? -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 11:05, 13 July 2015 (UTC)
  
: I fixed the thunar-volman issue, by editing the Removable Devices section. [[User:Liquen|Liquen]] ([[User talk:Liquen|talk]]) 21:16, 28 December 2012 (UTC)
+
::Indeed, it works with gnome-screensaver. It even uses gnome-screensaver when I symlink slock in /usr/local/bin to xflock4 (though the shortcut and menu do respect xflock4). Looking through the source, xfpm is supposed to use xflock4 though [http://git.xfce.org/xfce/xfce4-power-manager/tree/common/xfpm-common.c#n58], so not sure what's happening here. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:04, 14 July 2015 (UTC)
  
== Archiver Installing ==
+
:::It's worth taking a look at what xflock4 is actually doing here - it's just a shell script. As can be seen from the first for loop, it will try to execute {{ic|xscreensaver-command -lock}} and {{ic|gnome-screensaver-command --lock}} in that order and it will exit. Only if neither of those can be executed will it move on to deal with xclock and slock. So xfpm's behaviour is correct here.
 +
:::Edit: Whoops, misread. Yes I see the problem here, the symlink isn't being respected. Not sure why that would be the case.
 +
:::Edit2: The lock screen panel action button first tries to find the program in path before executing.[http://git.xfce.org/xfce/xfce4-panel/tree/plugins/actions/actions.c#n868] The power manager doesn't. That's probably the source of the inconsistency. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 08:01, 14 July 2015 (UTC)
  
When installing xfce onto a fresh Arch system, one of the programs in the xfce-goodies package (might be thunar-archiver-plugin or something along those lines) requires the additional installation of a archiving program such as xarchiver or ark etc. Perhaps this is worth a note? [[User:Hozza|hozza]] ([[User talk:Hozza|talk]]) 07:37, 5 September 2012 (UTC)
+
::::No activity since mid July - was a decision reached on this? -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 16:34, 17 September 2015 (UTC)
  
== Install new Icon section ==
+
:::::I couldn't get this working outside gnome-screensaver/x-screensaver, even when putting a symbolic link directly in /usr/bin, but I'm afraid I didn't get the chance to contact upstream yet. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:16, 19 September 2015 (UTC)
Copy From [[ArchWiki:Reports]]: should first look if there is a package for that theme, and also consider whether creating a PKGBUILD before extracting to /usr/share/icons. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:35, 15 March 2013 (UTC)
+
 
 +
 
 +
== XFCE and GTK3 Theme ==
 +
 
 +
My edit [https://wiki.archlinux.org/index.php?title=Xfce&diff=prev&oldid=467430] for the section [[Xfce#Theming]] was removed without clearly explaining why, with the comment "not sure where this was copied from, but copying a theme-specific .css file to .config has no impact, in particular not to use the 'same theme colors as the rest (?) of XFCE'. cf [https://blogs.gnome.org/mclasen/2014/05/06/tweaking-a-the-gtk-theme-using-css/]". This link does not address the same issue at all. To answer "where this was copied from", the commands comes from here: [https://bbs.archlinux.org/viewtopic.php?id=119251].
 +
 
 +
This fix enabled me to have a dark Adwita theme with dark colors in GTK3 apps, such as Firefox or the XFCE Terminal Emulator, in different Arch installations. Even though I didn't delve in the details to know how this fix work, the thing is that it works, and is needed. Maybe a better fix exists, but it's not documented on the wiki. This picture illustrates the fix: [http://hpics.li/0591d91].
 +
 
 +
Could you, [[User:Alad|Alad]], explain to me why you think it has "no impact", as it solved my issue ? -- [[User:Jeatra|Jeatra]] ([[User talk:Jeatra|talk]]) 13:07, 2 February 2017 (UTC)
 +
 
 +
:Adwaita has light and dark variants. If you look at the file {{ic|/usr/share/themes/Adwaita/gtk-3.0/gtk.css}} you'll see that it contains a line for importing the Adwaita dark theme resource. So by copying that css file to your home directory you're effectively forcing the dark Adwaita variant as theme files in the home directory take precedence over the global ones. So what you did does work though it's not the cleanest solution. Does [[GTK+#Dark_theme_variant|this]] accomplish the same thing? -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 13:58, 2 February 2017 (UTC)
 +
 
 +
::[[GTK+#Dark_theme_variant|This]] does nothing on my system. However, with further tests, I found that just copying (or linking) {{ic|/usr/share/themes/Adwaita/gtk-3.0/gtk.css}} into {{ic|~/.config/gtk-3.0/}} corrects the theme. This file contains only the line {{ic|@import url("resource:///org/gtk/libgtk/theme/Adwaita/gtk-contained-dark.css");}}. Why is that needed? Did I miss a configuration step (which one)?
 +
 
 +
::I agree that my suggested fix is not a good fix as this force gtk3 applications to use the dark colors instead of the settings configured in ''Settings > Appearance'' or via {{ic|lxappearance}}. So I'm still looking for a good one, do you have any pointers or ideas? -- [[User:Jeatra|Jeatra]] ([[User talk:Jeatra|talk]]) 14:28, 2 February 2017 (UTC)
 +
 
 +
:::<s>As I understand it, adding a gtk.css file to {{ic|~/.config/gtk-3.0/'''''theme-name'''''}} affects the theme called theme-name.</s> (misread, I was thinking of {{ic|~/.themes}}) Adding a gtk.css file to {{ic|~/.config/gtk-3.0/}} affects all themes. So of the two solutions, I'd say the original is cleaner actually. I'm not really a fan of either solution though.
 +
:::In terms of what that line is doing, @import is a css statement which says, import the rules from the resource specified. The resource in question is {{ic|gtk-contained-dark.css}} which is provided with GTK+ 3 and contains the rules for the Adwaita dark theme. So what you're doing is forcing the rules of the Adwaita light theme to be overridden by the rules of the Adwaita dark theme.
 +
:::Are you certain that you cannot select the Adwaita dark theme from Settings -> Appearance in Xfce? In MATE, you can {{ic|Adwaita-dark}} is listed as an option and it works fine. If the Adwaita dark theme cannot be applied from within the Xfce GUI then I would regard that as an Xfce bug that should be filed upstream. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 15:23, 2 February 2017 (UTC)
 +
 
 +
::::I can select the Adwaita dark theme from ''Settings -> Appearance'' in Xfce, or using the LXDE application {{ic|lxappearance}}, however this does not impact gtk3 applications. I did not try with the Gnome or MATE tools. -- [[User:Jeatra|Jeatra]] ([[User talk:Jeatra|talk]]) 16:45, 2 February 2017 (UTC)
 +
 
 +
:::::Tested again using MATE and you're right. Adwaita-dark is GTK+ 2 only and setting {{ic|gtk-application-prefer-dark-theme &#61; true}} in {{ic|~/.config/gtk-3.0/settings.ini}} does not work. So this isn't Xfce specific The only trouble with creating {{ic|~/.config/gtk-3.0/settings.ini}} is that users won't be able to change the theme for GTK+ 3 applications until that file is removed. I think the best approach might be to expand [[GTK+#Dark theme variant]], adding the solution you suggested and making a note of the fact that the {{ic|gtk-application-prefer-dark-theme}} doesn't appear to work. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 10:29, 3 February 2017 (UTC)
 +
 
 +
::::::As per [[Talk:GTK+#Adwaita-dark seems broken; possible workaround.|this discussion]], there was a bug in gnome-themes-standard versions below 3.22.2 and below which broke Adwaita-dark. Adwaita-dark should work correctly now. On my system (using MATE) selecting Adwaita-dark sets a dark theme for GTK+ 2 and 3 applications. Still not sure about the status of {{ic|gtk-application-prefer-dark-theme}} - will need to look into that. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 14:55, 10 May 2017 (UTC)

Latest revision as of 14:55, 10 May 2017

Lock screen on suspend

Xfce#Lock the screen gives an introduction to screen locking, but I can't get it to work with xfce4-power-manager on resuming from suspend. I've found little on this [1] [2] and an old bug for Xfce 4.8. [3]. Locking via Ctrl+Alt+L works as expected (slock). Can others reproduce, and if yes, should I investigate further and file a bug upstream? Perhaps this could be related to the light-locker transition (where I use xinitrc). -- Alad (talk) 10:52, 13 July 2015 (UTC)

This functionality works fine for me but I use gnome-screensaver. This might be an issue for specific screen lockers as opposed to a general Xfce issue. I notice that there is an alternative "lock screen before sleep" option under Applications -> Settings -> Session and Startup -> Advanced. Perhaps that works where the xfpm option does not? -- Chazza (talk) 11:05, 13 July 2015 (UTC)
Indeed, it works with gnome-screensaver. It even uses gnome-screensaver when I symlink slock in /usr/local/bin to xflock4 (though the shortcut and menu do respect xflock4). Looking through the source, xfpm is supposed to use xflock4 though [4], so not sure what's happening here. -- Alad (talk) 06:04, 14 July 2015 (UTC)
It's worth taking a look at what xflock4 is actually doing here - it's just a shell script. As can be seen from the first for loop, it will try to execute xscreensaver-command -lock and gnome-screensaver-command --lock in that order and it will exit. Only if neither of those can be executed will it move on to deal with xclock and slock. So xfpm's behaviour is correct here.
Edit: Whoops, misread. Yes I see the problem here, the symlink isn't being respected. Not sure why that would be the case.
Edit2: The lock screen panel action button first tries to find the program in path before executing.[5] The power manager doesn't. That's probably the source of the inconsistency. -- Chazza (talk) 08:01, 14 July 2015 (UTC)
No activity since mid July - was a decision reached on this? -- Chazza (talk) 16:34, 17 September 2015 (UTC)
I couldn't get this working outside gnome-screensaver/x-screensaver, even when putting a symbolic link directly in /usr/bin, but I'm afraid I didn't get the chance to contact upstream yet. -- Alad (talk) 11:16, 19 September 2015 (UTC)


XFCE and GTK3 Theme

My edit [6] for the section Xfce#Theming was removed without clearly explaining why, with the comment "not sure where this was copied from, but copying a theme-specific .css file to .config has no impact, in particular not to use the 'same theme colors as the rest (?) of XFCE'. cf [7]". This link does not address the same issue at all. To answer "where this was copied from", the commands comes from here: [8].

This fix enabled me to have a dark Adwita theme with dark colors in GTK3 apps, such as Firefox or the XFCE Terminal Emulator, in different Arch installations. Even though I didn't delve in the details to know how this fix work, the thing is that it works, and is needed. Maybe a better fix exists, but it's not documented on the wiki. This picture illustrates the fix: [9].

Could you, Alad, explain to me why you think it has "no impact", as it solved my issue ? -- Jeatra (talk) 13:07, 2 February 2017 (UTC)

Adwaita has light and dark variants. If you look at the file /usr/share/themes/Adwaita/gtk-3.0/gtk.css you'll see that it contains a line for importing the Adwaita dark theme resource. So by copying that css file to your home directory you're effectively forcing the dark Adwaita variant as theme files in the home directory take precedence over the global ones. So what you did does work though it's not the cleanest solution. Does this accomplish the same thing? -- Chazza (talk) 13:58, 2 February 2017 (UTC)
This does nothing on my system. However, with further tests, I found that just copying (or linking) /usr/share/themes/Adwaita/gtk-3.0/gtk.css into ~/.config/gtk-3.0/ corrects the theme. This file contains only the line @import url("resource:///org/gtk/libgtk/theme/Adwaita/gtk-contained-dark.css");. Why is that needed? Did I miss a configuration step (which one)?
I agree that my suggested fix is not a good fix as this force gtk3 applications to use the dark colors instead of the settings configured in Settings > Appearance or via lxappearance. So I'm still looking for a good one, do you have any pointers or ideas? -- Jeatra (talk) 14:28, 2 February 2017 (UTC)
As I understand it, adding a gtk.css file to ~/.config/gtk-3.0/theme-name affects the theme called theme-name. (misread, I was thinking of ~/.themes) Adding a gtk.css file to ~/.config/gtk-3.0/ affects all themes. So of the two solutions, I'd say the original is cleaner actually. I'm not really a fan of either solution though.
In terms of what that line is doing, @import is a css statement which says, import the rules from the resource specified. The resource in question is gtk-contained-dark.css which is provided with GTK+ 3 and contains the rules for the Adwaita dark theme. So what you're doing is forcing the rules of the Adwaita light theme to be overridden by the rules of the Adwaita dark theme.
Are you certain that you cannot select the Adwaita dark theme from Settings -> Appearance in Xfce? In MATE, you can Adwaita-dark is listed as an option and it works fine. If the Adwaita dark theme cannot be applied from within the Xfce GUI then I would regard that as an Xfce bug that should be filed upstream. -- Chazza (talk) 15:23, 2 February 2017 (UTC)
I can select the Adwaita dark theme from Settings -> Appearance in Xfce, or using the LXDE application lxappearance, however this does not impact gtk3 applications. I did not try with the Gnome or MATE tools. -- Jeatra (talk) 16:45, 2 February 2017 (UTC)
Tested again using MATE and you're right. Adwaita-dark is GTK+ 2 only and setting gtk-application-prefer-dark-theme = true in ~/.config/gtk-3.0/settings.ini does not work. So this isn't Xfce specific The only trouble with creating ~/.config/gtk-3.0/settings.ini is that users won't be able to change the theme for GTK+ 3 applications until that file is removed. I think the best approach might be to expand GTK+#Dark theme variant, adding the solution you suggested and making a note of the fact that the gtk-application-prefer-dark-theme doesn't appear to work. -- Chazza (talk) 10:29, 3 February 2017 (UTC)
As per this discussion, there was a bug in gnome-themes-standard versions below 3.22.2 and below which broke Adwaita-dark. Adwaita-dark should work correctly now. On my system (using MATE) selecting Adwaita-dark sets a dark theme for GTK+ 2 and 3 applications. Still not sure about the status of gtk-application-prefer-dark-theme - will need to look into that. -- Chazza (talk) 14:55, 10 May 2017 (UTC)