3 ms·

This logic is fine for GNOME apps, sure use client side decorations, use background jobs, remove advanced options etc but GNOME can't force non GNOME apps top f

This logic is fine for GNOME apps, sure use client side decorations, use background jobs, remove advanced options etc but GNOME can't force non GNOME apps top follow their big ego designer vision, there are also old application and games that can't just implement client side decorationbs because GNOME want to force their shit. So I see people like you that complaint hat Canonical did not implement X in snap(like third party repo) but defend GNOME that is rejecting keeping functionality with other applications with excuses like - GNOME devs are too busy to read and accept your patch (maybe Canonical devs are busy too) - GNOME devs don't want to add your patch that adds a checkbox to give you an option because is to much work maintining it (maybe Canonical thinks is too much work to maintain that third party repos patch) - GNOME devs don't want to support other applications and toolkits, is only the GNOME way or if you don't like it use KDE (then same should apply for snaps, you don't like it use flatpack) - systemd has some Google DNS hardcoded int he code, if you don't like it ask your distro to change it or recompile it yourself (then please apply same for snap, ask you distro to recompile, patch it , etc) - there is a large number of GNOME users that want tray icons, then GNOME response is "you are stupid, we know better, use something else or patch the code with an extension - you should apply same excuse for Canonical) Hope I made it clear, there are some double standards here, so we should be more consistent, probably both snap and GNOME are less user targeted and dev/designer ego driven since nobody pays for the product the user requests are ignored.

vetinari 6y ago
I will use just one example to demonstrate that your double standards are not really double: > - systemd has some Google DNS hardcoded int he code, if you don't like it ask your distro to change it or recompile it yourself (then please apply same for snap, ask you distro to recompile, patch it , etc) Systemd has a default fallback hardcoded to Google DNS. Yes, distributions can compile in another default fallback. At the end of the chain, someone had to pick something, that works. The users can configure whatever they want - no need to recompile anything, just config file - and once they configure something, the default fallback is no more, the option picked by the user is used. Canonical's snap store, on the other hand, is not a default fallback. It is only one option allowed, and if you don't like it, tough luck. Wrt. the discussion, there are tree possibilities: - you don't understand the nuance that makes the difference between those two situations; - you willingly misrepresent two different situations as one; - you don't understand what you are talking about. Anyway, in all three cases, there's no point to any further discussion.

vetinari 6y ago

I will use just one example to demonstrate that your double standards are not really double: > - systemd has some Google DNS hardcoded int he code, if you don't like it ask your distro to change it or recompile it yourself (then please apply same for snap, ask you distro to recompile, patch it , etc) Systemd has a default fallback hardcoded to Google DNS. Yes, distributions can compile in another default fallback. At the end of the chain, someone had to pick something, that works. The users can configure whatever they want - no need to recompile anything, just config file - and once they configure something, the default fallback is no more, the option picked by the user is used. Canonical's snap store, on the other hand, is not a default fallback. It is only one option allowed, and if you don't like it, tough luck. Wrt. the discussion, there are tree possibilities: - you don't understand the nuance that makes the difference between those two situations; - you willingly misrepresent two different situations as one; - you don't understand what you are talking about. Anyway, in all three cases, there's no point to any further discussion.