Hello,
a picture instead of too many words :
How to fix these ?
Only thing I managed to do is go to chrome-store to find a theme that fits a bit ( tabs were initially light-grey ).
You cant fix it. That’s how sandboxed apps work
…with broken icons and wrong theming ???
…4 years after snap has been introduced into an LTS release - I know you’re not guilty of anything but I still can’t understand why snap has any interest for desktop users.
Maybe → https://snapcraft.io/adapta-gtk-snap ?
No harm on trying that theme snap and the connect info. Yes, snaps that understand theming needs a connection to themes packaged as a snap.
Similarly icons can be be connected if they are packaged as a snap.
And « fixed » :
And chromium uses adapta gtk-theme accordingly.
Not perfect but less ugly.
django@ASGARD:~$ sudo snap connect chromium:gtk-3-themes adapta-gtk-snap:gtk-3-themes
[sudo] Mot de passe de django :
django@ASGARD:~$ sudo snap connect chromium:icon-themes adapta-gtk-snap:icon-themes
django@ASGARD:~$
Clarification on snaps and themes.
The reason some themes work and others do not is that on the back end there is a “gtk common themes” snap that cannonical has made. When your theme is included in that snap, your theme related oddities drop dramatically.
I’m working on getting our official theme added but I’m still trying to figure that out (I need to modify the snap and do a pull request).
But we can’t add any theme we like as canonical is trying to keep the size of that snap down.
There’s been some discussion around doing a “per flavour” snap to combat this and allow a little more flexibility, but I have not seen that discussion move ahead (various pros/cons).
That per flavour thing sounds good. Could then stuff QogirBudgie and Pocillo. Guess the yaml would be very similar to that adapta theme snap. If we could get that connect method automated even better
@fossfreedom yeah, my understanding is that the snap team has to do some dev to enable something like that. There’s no mechanism (I think it’s called a “slot”) to hook up to currently.
We will see.
And any installed snap should then be themed accordingly to system theme.
I guess some app-dev’s exactly don’t want that.
Snap… lack « global » integration into the user environment :
⋅ theming,
⋅ easily settings like removable-media, inputs ( wacom, joysticks, and so on )
⋅ interactions between app’s ( maybe I speculate here but we can imagine many snap app’s using the same contacts or mailing app, that sort of « links » )
I don’t know what’s best « logic » :
⋅ a one place to manage all snap options, app by app or
⋅ a wizard at first launch of each snap-app to invite user to take care of the many options ?
⋅ well, one does not exclude the other, tout compte fait.
It looks like very much what happens when syncing local and online services where any part asks authorization from other. Such a mess sometimes. And thanks to snap & c° we now have that same pleasure in desktop pc…
I just can’t imagine a kdenlive with no access to external media/drives or a krita without a wacom-like or a supertuxkart without gamepad-like…
The way to look at this is; confinement is a substantial aspect of the design goals. Anything they add for a plug or interaction is not added lightly and needs to be appropriately designed.
The real problem is not so much what the snap can or can’t do. I find most times when something does not work - it is usually (but not always) due to how the snap author put it together. Maybe they missed an interface. And at times the application itself may need modification - something like a path modified (you would be surprised how many paths are hard coded in apps).
And for apps like kdenlive that may need full system access, it can get it. But the author has to apply for classic status. (easy - just a forum post and a review).
I think the problem also with snaps is that people assume they are “done”. The snap system is under heavy dev (as are all universal packaging formats). It will take time, but all of them will get better
Snap is enabled in LTS versions of Ubuntu since 16.04 meaning some people somewhere thought it was stable enough to bother regular end-users…
Snaps are first shown in some app-stores without any warnings nor recommendations meaning some people somewhere thought they were ready enough as a transparent alternative to .deb…
Some snaps are provided as default in new Ubuntu installation ( but fewer in 20.04 - wisely ) meaning…
Those people are terribly wrong, sorry. If they thought those new packaging are in-dev then why shipping them ( and pushing them ) onto LTS ? They should only aim at specific distributions for dedicated testing, and not the LTS ones at least. ( a specific distro where app’ user side are only snap - just to see how it works ).
À la rigueur providing only one « heavy » app ( poor chromium ) in snap is a better route for real ground testing than a calculator that was obviously ruined since day one and became the worst advocate for snap…
So ok, you are right : snaps are far from ready to be in the hands of everyday and randomly skilled users. Then please Canonical stop pushing them everywhere as if they were good enough. Please Canonical listen to the many reports from non tecchy users who feel a bit lost with snaps. Please here that not everybody has ssd and dozens terabytes available at hand…
Sorry for the rant @bashfulrobot and @fossfreedom I really appreciate your sense of wisdom and see any day your devoted commitment to Budgie ( and else ) but I really don’t understand Canonical’s route here.
If all software was “done” on release, no one would be updating for anything other than security. There are additional features, fixes, etc always going out. The release of any software is usually based on a MVP (Minimum Viable Product). I hardly think anything under heavy dev = “not stable”.
Moving Chromium to a snap was not a “test”. There are reasons for it. (If interested - https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition). While some may disagree, it makes sense from an engineering effort POV. I actually get why they did it. And do not disagree with it.
I never said they are far from ready. What I was saying is that how people package things can be a factor. This can be said for any 3rd party PPA, The Arch AUR, etc. Are there pain points? Absolutely (like any software). But if you look at the benefits, additional security, commercial entities “actually” packaging software for Linux (huge win in my books), I feel something like a universal packaging format is the way to go. If you look at ANY of the 3 in dev right now, they all have pros/cons.
And if you sit on it until it is perfect, you may have already lost market share.
Rants are good. Opinions are great (no right/wrong). All POVs are valid. We just happen to have different ones. 
I don’t think they are so different, fundamentally. A universal packaging sounds very promising. I’m biased because I really think how it’s handled now is almost nonsense.
It should be thought with [ end-user in mind ] + [ what works good in legacy formats ].
Granted the engineering point of view ( I perfectly hear why universal formats are a relief for dev’s ) all these efforts will end nowhere if the end user experience is bad / at least not as good as with legacy formats.
And pardon me but any time you have the choice between legacy and new format, legacy works as expected whereas new brings weirdness ( and yes having to connect, plug, theme is weird, whoever’s fault ). Because of my admitted ignorance I still feel « safety » is used as an excuse to cover UX big flaws ( I still don’t understand why I was not in safety using APT/.deb till today ??? )
But chicken or egg first ? How fix UX if there’s no experiment, right ? Then we need a full-snap desktop system to crash-test it every possible way… Not these half baked things we have today - from a stupid random user point of view like me. I’m still using ppa’s for Gimp or LibreOffice and others because resulting packages integrate flawlessly in my system and workflow. That’s not true at all with snap and flatpak.
When at work I need a predictable environment, hence LTS and .deb which I can trust. At home - and because am not really a Linux beginner - I’m ok to crash test something totally different, as long as I don’t forget to backup my personal data 
But the in between situation is unbearable : it’s confusing, it does not advocate well the « new thing » and I guess it does not provide enough valuable reports for the dev’s. And those new packagings implies many changes regarding « updates » and maintenance, for all, users, ( distro ) maintainers, dev’s, a.s.o. These changes need a broader plan to define what is a distro, who’s in charge of what…
…I have the feeling there’s a lack of « targeting » here. Well maybe there’s a global lack of « targeting » regarding the future of desktop pc, also. Cristal ball speaking…
Well, well, well… sorry again, being locked down gives me too much time to bother you, lol ! Sometimes passion blurs a bit the lines between reason and expectation.
Anyway be sure I’m full admiring « you » the people skilled and enthusiast enough to create and share all these ideas, concepts, codes and programs… Forget my bitterness if any
Ooww… and I just noticed today that removing a snap ( gimp ) also gets rid of all « personal » config’ files which is absolutely wrong !
Is it not in ~/snap? It should be. That is not the default behaviour (to remove). If it is, you may want to post on the snapcraft forum.
Mmm… I think I’ve misunderstood how it works.
Today I have this in ~snap/gimp :
coeurnoir@Asgard:/media/coeurnoir/Budgie19.10$ ls -la home/django/snap/gimp/
total 20
drwxrwxr-x 5 coeurnoir coeurnoir 4096 mai 22 16:47 .
drwxrwxr-x 5 coeurnoir coeurnoir 4096 avril 10 19:42 ..
drwxr-xr-x 4 coeurnoir coeurnoir 4096 mai 4 00:24 252
drwxr-xr-x 4 coeurnoir coeurnoir 4096 mai 22 16:47 273
drwxr-xr-x 3 coeurnoir coeurnoir 4096 mai 4 00:24 common
lrwxrwxrwx 1 coeurnoir coeurnoir 3 mai 22 16:47 current -> 273
coeurnoir@Asgard:/media/coeurnoir/Budgie19.10$
Are 252 and 273 folders matching each installation of Gimp I had made ? Or what are the meanings of these folders ?
When I removed gimp snap and later reinstalled it, the whole interface, preferences and tools were reset to default.
But maybe I should have re-used the 252 folder ?
Each number corresponds to a version, not installation. And the symlink from current to a number is the active install/version.
Ok. Therefore not what I thought.
I’ll remove / reinstall again and see what will happen.
If the behaviour is not what you expect , I highly suggest to post on the snapcraft forum. It’s the only way to get things like this fixed (if you have hit a bug).