Closed smithfred closed 6 years ago
That's probably a good idea if it doesn't break anything when an existing user runs git pull
on his repo clone, I'll consider it when we merge all those fixes from #21.
It works perfectly ;) Please feel free to test.
Changed the installation instructions, no code change needed. I'm not removing the @import
s for the old custom*.css
files, because people use them, so that would be an unnecessary breaking change.
Nice one, thanks :) Might be worth including a "setup.sh" or similar that automates the instructions - the "create userC.css" items are idempotent; the sed ones just need a grep blah ||
sort of test before them. Could also automate detection of >1 Firefox profiles (if only one, install to .default, otherwise prompt for which).
I actually tried, but the script turned out to be too complicated. I don't want to lock it down to only work with profiles located in your ~/.mozilla/firefox
dir since I use my own FF profile manager, which doesn't use this location and then it has to detect whether you run it inside your chrome
dir or the repo's dir, or somewhere else... The installation steps aren't too complicated, so I think that's okay to leave them as they are.
Having a script for the default FF profile/recommended installation method wouldn't preclude manual installation.
You could also just put a `read -p 'This will install this theme to your default profile, continue y/N?' as well.
I can probably chuck one together if you'd include it.
At the moment (when installing per the instructions) firefox-gnome-theme takes over the entire $firefoxprofiledir/chrome directory, and subsequently "owns" (controls) that profile's primary userChrome.css and userContent.css files.
Instead, it's much tidier to put all of firefox-gnome-theme's files in their own subdirectory, and add a single @import to each of the user's userChrome.css and userContent.css files:
This has a number of benefits: