I also added another session name to differentiate from the ppa. There has been some workarounds needed for cursor icon theme and dash to dock style override. As I already stated on another topic about it, I needed to push an empty file with our theme name so that we can override the Dash to Dock theme from our theme directly (the !important trick mentioned in the theme is wrong btw, and doesn’t work. Is there anyone volunteering to clean that up?).
Once the UIF exception is accepted due to new translation strings entering the distribution, I’ll upload both components (Bug #1760049 “[UIFe] Optional (hidden by default) communitheme s...” : Bugs : gnome-session package : Ubuntu).
Note that we expect people to remove the ppa version and switch to the snap version.
Finally, the settings override has also to be in distro, to set the correct theme names and general parameters. This will be hard to change once in (and can’t be piloted from the snap). This is why I’m asking for feedbacks.
Here are the keys:
Actually, that’s exactly what I was asking for, what else do need to change by default so that I upload the package with those settings
Ok, noting to setting “center new windows” to true for this session. IIRC, there was also a discussion about default font size, what was decided in the end, any other keys to change (the ppa schema doesn’t contain a change for font size)?
Size 10! But you’re right, no change has been made yet - can you fix that too @didrocks?
I don’t mind at all - please do.
I didn’t see the default cursor size discussion. Was this only for the busy spinner or for the pointer as well?
I’ve changed the sizes of idea 2+3 as requested.
It works fine for testing without, so I got lazy - sorry. Sure, I’ll fix that There’s also so more house cleaning to do
I would suggest that we only package one cursor style ( Communitheme_12 if you prefer) and remove the other designs. Is that still the plan?
EDIT: BTW I not really 100% satisfied with any of the designs yet
All fonts? (there are 4 fonts that people can generally change in Tweaks), or only Title fonts or anything else?
Oh correct, that was that one! So nothing to do on my side
That’s possible, I thought about installing them all and use a symlink as a pointer, but you’re correct, as you can’t load other from the snaps (as it’s loaded by X, before setting magic env variables) , let’s only ship one. We can then change it anymore for that part anyway
[quote=“didrocks, post:6, topic:4890”]
All fonts? (there are 4 fonts that people can generally change in Tweaks), or only Title fonts or anything else?[/quote]
@madsrh: I would need an answer quickly on this to make the upload in ubuntu now that beta freeze is lifted.
So, the process I’m envisioning is that any new commits upload a snap to the store in the edge channel (people who want to track the latest would be able to get thus the latest of latest in just minutes!). Then, after some manual check and release management, someone (or maybe some people would be responsible of promoting it to the stable channel (like once a week?) so that most of people are using the safe and checked channel. I was thinking about giving those powers to @merlijn-sebrechts (are you interested?), but others can step in too and multiple people can have those rights, if think you want to do it. I’ll publish guidelines on how to do that, it’s pretty easy.
I think that’s a good idea and I’m interested to take care of this, although it’s best to have multiple people with this power, I can’t guarantee that I have time every week to do this.
So basically, the theme files are contained in the snap, and you tell Gnome to look for themes in that snap’s folder using XDG_DATA_DIR magic? Does snapd change XDG_DATA_DIR when the theme snap is installed?
If I understand correctly, this will only work on Ubuntu 18.04+, right? Other distros will need to install a package which adds the session, settings and dash-to-dock override, right? Or does the session also use the XDG_DATA_DIR magic?
How does the confinement work for this? Can anyone create a new theme and add it or do you need some blessing from the snapd folks? (a plug?) How does versioning work? Is there any way to make sure the theme and gnome version are compatible?
Exactly! snapd won’t be even invoked, it’s only used as a transport mecanism for that part. Basically, the session is driving XDG_DATA_DIR.
That’s all correct! + a little magic (herm, a symlink) for the cursor theme to work on X, as X is started before the session
We don’t really use snapd as a confinement mechanism (nobody was able with any technology to confine yet an entire user session), so it’s only a delivery mechanism that enables people to select their level of “risk” (tracking edge or stable for instance), and auto-refresh. We take advantages of both. So, right now, this is limited to communitheme only (as you noted, there are some parts which are in the distro and can’t be pushed as part of the snap). For compatibility, there is the notion of tracks, and we’ll create a “bionic” track once we move to an uncompatible GNOME Shell and move people to it (however, there is no dependencies notions between snaps and debs). However, the bionic GNOME Shell version will stay forever compatible as part of our release process.
Magic ! (well, actually TryExec in the session file pointing to the helper in the snap! ;)). More on that in a blog post I plan to write early next week.
Hey @didrocks, a quick snap based question: Seems the theme is able to work out of a snap soon, but what about the theming support for example LibreOffice Snap?
Not really (this is currently done by the snap team itself) and I don’t have an idea of their priorities/timelines. But once implemented, I’ll make sure the communitheme snap works with it
As mentioned on the blog post, there are autogenerated snap support for PR.
This enable users to try a branch work in progress before getting it merged to master.
I got a question today from @frederik-f why this wasn’t working for him on https://github.com/ubuntu/gnome-shell-communitheme/pull/104.
Just to be clear: for security reasons, the hidden token (snap store to push the snap and Github to comment on the PR) aren’t accessible for branches not being in the same repository than the destination target. This is a Travis CI feature.
What it means is that if you want to have automated generated snap before they hit master as part of the PR (as in https://github.com/ubuntu/communitheme-snap-helpers/pull/6), you need to have your source branch under the ubuntu repo instead of your own fork.
I’ve fixed the build script so that people using branches on their own fork don’t have CI failing. Their branches are still building a snap to ensure it works, but not uploaded to the store and thus, no comment appearing:
Note that if you intend to get it merged them soon without having snap previews from your branch, don’t bother Just ensure that future branches follow this!
There’s also so more house cleaning to do 
this