After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 787454 - Allow configuration of GDM theme
Allow configuration of GDM theme
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: login-screen
3.25.x
Other Linux
: Normal normal
: ---
Assigned To: Ray Strode [halfline]
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-09-08 17:40 UTC by Jeremy Soller
Modified: 2018-09-08 20:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jeremy Soller 2017-09-08 17:40:42 UTC
Allow the configuration of GDM's theme by setting the stylesheet option of the gdm mode in gnome-shell when a theme is enabled.

The theme can be selected in GDM's gsettings. When this setting is set to the name of a gnome-shell CSS file in /usr/share/gnome-shell/theme, that file will be used to theme the gdm mode.
Comment 1 Florian Müllner 2017-09-08 23:50:47 UTC
No, we don't support a theme setting for the user session (see bug 650701), and there's no reason why the login-screen session should be different in that regard.

gnome-shell uses CSS styling information not just for applying a certain look to a fixed set of widgets, but also to position and size particular UI components. That is, a bad or outdated theme will not just look a bit wrong, but can actually break functionality for users.

Insistent users can of course still change whatever they want - it's free software after all - but they get to keep the pieces if stuff breaks. An easily accessible shoot-users-in-the-foot setting would be a whole different story ...
Comment 2 Didier Roche 2017-09-11 09:07:30 UTC
Hey Florian,

I guess Jeremy is reporting from the System76 perspective, as a vendor.

You are completely right that there is the risk of user's theme breaking with a new version of the Shell in term of looking outdated or just breaking due to missing entries.

However, as a vendor, it's the vendor's perspective to DTRT. However not hardcoding this value (and making that easily switchable by the vendor) will give an unique and easy way to propose multiple Shell experiences (as we do with our ubuntu session, as system76 starts doing with their pop version), while still providing the upstream experience to those who desired, via our GNOME vanilla session.

Similarly, we could theme GDM in RHEL shipping GNOME classic by default accordingly to the theme.

Does it make sense, is that something you would be interesting in us working on, ensuring at the same time Shell safety and resilience by not exposing this to the user, but still allowing vendors/distributors to tweak and change this?
Comment 3 Ray Strode [halfline] 2017-09-11 15:01:24 UTC
it might be interesting to allow extensions at the lock screen and gdm screen.  right now we disable them, but we could potentially include which session-modes an extension supports in its metadata, instead of just having a big binary "allowExtensions" boolean associated with the session mode.
Comment 4 Didier Roche 2017-09-12 06:00:54 UTC
I guess that's an interesting way to be able to solve this and another class of eventual issues (I didn't consider it at first, but the more I'm thinking about it, the more I like that proposal).
Comment 5 Jan Niklas Hasse (Account disabled) 2017-09-21 19:49:14 UTC
> it might be interesting to allow extensions at the lock screen and gdm screen.

Have a look at https://bugzilla.gnome.org/show_bug.cgi?id=781760 :)