Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Support themes installed in two file system locations #1561

Open
travier opened this issue Jun 18, 2022 · 10 comments · May be fixed by #1739
Open

Enhancement: Support themes installed in two file system locations #1561

travier opened this issue Jun 18, 2022 · 10 comments · May be fixed by #1739

Comments

@travier
Copy link

travier commented Jun 18, 2022

Add support for using themes installed in two different file system locations instead of a single one right now.

The objective is to be able to define the two following locations:

  • /usr/share/sddm/themes: themes installed by packages from Linux distributions
  • /var/lib/sddm/themes: themes installed by a local user/administrator

This is especially useful on Linux distributions where /usr is mounted read only such as Fedora Kinoite.

Will help fix: https://bugs.kde.org/show_bug.cgi?id=454509

Thanks!

@marcdeop
Copy link

Perhaps even better if there is a setting so distros can configure this kind of stuff :-)

@travier
Copy link
Author

travier commented Mar 11, 2023

This is the idea. There is currently only one option in the settings (https://github.com/sddm/sddm/blob/develop/data/man/sddm.conf.rst.in#L81) and would either need to make that a list or to add a "System Themes" / "User Themes" option.

@aleixpol
Copy link
Contributor

How about we make Current accept being an absolute path?

I don't see how we benefit from the ThemeDir + Current distrinction.

@Vogtinator
Copy link
Contributor

How about we make Current accept being an absolute path?

I don't see how we benefit from the ThemeDir + Current distrinction.

Could be done, but IMO sddm should have a default location for themes outside of /usr. If that's not provided somehow, this is entirely up to the user or configuration tool, which is IMO the wrong place.

@aleixpol
Copy link
Contributor

What I mean is that it feels wrong to ask SDDM to be figuring out at runtime where to get the theme from.

If the users want to have sddm use a theme located elsewhere, they should be able to just inform which directory it's on.

@Vogtinator
Copy link
Contributor

What I mean is that it feels wrong to ask SDDM to be figuring out at runtime where to get the theme from.

Yeah, and ideally SDDM provides a location OOTB where all configuration tools (I guess just sddm-kcm, can anything else install themes?) can look for it and write to.

If the users want to have sddm use a theme located elsewhere, they should be able to just inform which directory it's on.

In theory that could mislead users (or worse, tools) to select some location inside $HOME, which can be insecure.

IMO doing it like SessionDir in PR #1543 and allowing multiple directories to be specified (with one being inside /var, /usr/local/ or maybe /etc) is the most straightforward and obvious option.

@travier
Copy link
Author

travier commented Mar 13, 2023

IMO doing it like SessionDir in PR #1543 and allowing multiple directories to be specified (with one being inside /var, /usr/local/ or maybe /etc) is the most straightforward and obvious option.

Definitely agree with this approach with the paths from my first comment.

@aleixpol
Copy link
Contributor

In theory that could mislead users (or worse, tools) to select some location inside $HOME, which can be insecure.

Having a ThemeDir can also mislead users to thinking they should be using home. I don't see why we need to make it more complex than it needs to be.

@alebastr alebastr linked a pull request Jun 23, 2023 that will close this issue
@bayazidbh
Copy link

Since SDDM will be joining KDE and KDE Plasma 6 is in development, might this be a good chance to implement or otherwise change where the SDDM themes are located?

@Terraphice
Copy link

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants