Changes the main color of Ubuntu > 18.04 (The purple).
Hot Tip: Ubuntu Orange is “E95420”.
The first time you run this program it creates a copy of the affected config files and appends .original. The second time you run the program it appends .bak. That way you can always restore your original settings by invoking the “-r” or “–restore” argument.
Access is needed to:
grub_plymoth_file = ‘/usr/share/plymouth/themes/ubuntu-logo/ubuntu-logo.grub’
splash_plymouth_file = ‘/usr/share/plymouth/themes/ubuntu-logo/ubuntu-logo.script’
gdm_config_file = ‘/etc/alternatives/gdm3.css’
how does the code prevent the files from being re-set to their original states with the next update of the .deb packages ? all these files are shipped inside debian packages from the ubuntu archive, directly modifying their content (no matter if from a snap or a deb package) is a very bad idea in general.
if you want to change the themes you should rather simply create a package that ships your modified theme and changes the configuration to point to it instead of patching random files of the file system that a routine package update will just revert (or in the case of the alternative you modify, possibly even cause package system breakage when a package maintainer script tries to update it automatically during a routing update)
Did you “read” the program ?
Is this an answer ?
How do you simply create a package?
no, it was a bunch of questions and hints, your program modifies files of debian packages on the system, these are not config files and not meant to be edited by hand or scripts. an update of the deb packages that ship them will simply revert your change, checksums in the package database will not match files on disk anymore.
the gdm3.css alternative your app modifies can point to different files, indeed with different content, so your patching might even fail depending on what the alternative currently points to, other theme packages might ship additional alternatives for gdm3.css:
sudo update-alternatives --config gdm3.css
There are 2 choices for the alternative gdm3.css (providing /usr/share/gnome-shell/theme/gdm3.css).
Selection Path Priority Status
* 0 /usr/share/gnome-shell/theme/ubuntu.css 10 auto mode
1 /usr/share/gnome-shell/theme/gnome-shell.css 5 manual mode
2 /usr/share/gnome-shell/theme/ubuntu.css 10 manual mode
Press <enter> to keep the current choice[*], or type selection number:
Instead of modifying the system files, you should create a package with the modified files and use the provided system mechanisms to enable them instead of patching the logo, script and css files on disk. i think a deb package would be better suited here than a classic snap package since the dpkg system will provide you access to the package update triggers for initamfs and grub as well as integrating with the alternatives system to ship a modified alternative theme.
PS: yes i read the program…
Thank you, this makes sense…
This also might introduce more work than I am capable of doing.
So if I get you right:
You suggest making a dynamic plymouth theme and a alternative .css, (They would have to be dynamic as the user changes color so does the configuration). I am not sure a deb is the way if I ned the files to be dynamic anyway.
Then use the provided tools to point to the themes / files.
Any input on how to change plymouth themes?
PS: I was aware of updates changing it back, but can a changed file on disk introduce system breakage? This would be if the updated package where to patch files, not replace them?
if the files need to be dynamic you can simply put them into a place where the system expects them to be dynamic (/etc for config files, /var for variable files of other kinds)
There seems to be a good guide at:
depends … imagine a security fix changes the format of the theme files. your patching didnt get updated, and all of a sudden grub hangs when reading the theme and doesnt boot the systems anymore …
there are also security tools like debsums that check the /var/lib/dpkg/info/*.md5sums files for system integrity and would probably trigger some kind of virus alert in some setups.
So, Iv’e figured out how to do this correctly.
The “downside” is as you say that I need to put files in the system.
Can I use snap for this, can this be approved?.
I will make hooks to transfer the files to: (open for suggestions)
update them, and to remove them on uninstall.
It would mean a complete refactor of the original program so it would be nice to know if its possible to get this approved. The way I have to do this with snap (unless someone has a suggestion) means I have to make the program for snap, not snap a program, if it makes sense
PS: The more I think about this the more doubt in my mind. I would have to make the program idiotproof by doing tests to look for plymouth / GDM before applying the configurations… Can snap do this?
FYI, a similar, though more scoped use case, was presented here: Classic confinement request: communitheme-set-default (communitheme snap). The end result was that classic was not granted and that the proper solution (the design is given here) involves updating snapd to support an ‘alternatives’ interface. While the design is written and it is on the larger roadmap, that work is not prioritized by the snapd team. Of course, anyone willing and able to create a PR against snapd is welcome to do so.
Since this is nearly the exact same use case as laid out in Classic confinement request: communitheme-set-default and it was not granted classic confinement, I suggest this one also not be granted classic.
That was a good read…
I agree, with an implementation of alternatives as the spec describes “my” snap could be confined in the same way as the community theme.
All I want to do though is change the static background color. The best thing would be if this was an option available in the community snap. I am using this as it gave me the idea in the first place. I will contact the developers and see if they are interested in such an option.
Thanks for the links, good read.