After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760717 - Allow users to disable core apps
Allow users to disable core apps
Status: RESOLVED FIXED
Product: gnome-software
Classification: Applications
Component: General
3.18.x
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Software maintainer(s)
GNOME Software maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-01-16 15:29 UTC by Michael Catanzaro
Modified: 2016-09-09 11:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Catanzaro 2016-01-16 15:29:20 UTC
We should consider to allow "disabling" core apps without allowing users to remove the core apps from the system. This could be implemented by e.g. dropping a NotDisplay=True desktop file into ~/.local/share/applications. Then the app will disappear for users who don't want to see it, but it will still be there for new user accounts, reflecting that it is a core component of the operating system. The app would appear as usual under the System Applications heading in Software, with a Disable or Enable button rather than a Remove button.

This would basically be equivalent to how Windows allows you to disable Internet Explorer, XPS Viewer, etc. so they don't clutter your menus, without actually allowing you to uninstall them. It would satisfy users who want to use alternatives to our core apps, e.g. VLC or MPlayer rather than Totem and not have unwanted apps cluttering the overview, and while maintaining the distinction that the core app is a core component of the operating system -- which is why we made these apps uninstallable in the first place. This way, users don't have to drop to the command line to remove the app they want to get rid of ('sudo dnf remove totem'), and don't suffer unexpected consequences from doing so (losing the nautilus thumbnailer).
Comment 1 Matthias Clasen 2016-02-22 12:25:07 UTC
'disabled' applications are not a concept we have. I don't think it is a good idea to introduce it.
Comment 2 Michael Catanzaro 2016-02-22 13:42:24 UTC
I don't mind closing this bug. This is only one possible solution to the problem in bug #760697, which is that random core apps are uninstallable. We do need to solve that problem.
Comment 3 Matthias Clasen 2016-02-22 15:59:13 UTC
One would hope that core apps are not 'random'. And that their being uninstallable is a problem is a claim that you've made - is there any supporting evidence for that ?
Comment 4 Jasper St. Pierre (not reading bugmail) 2016-02-22 16:04:00 UTC
I've heard it from multiple users. I also don't like it. Just because the apps are core, doesn't mean users aren't happier with other alternatives. Users should be able to install the apps they want to, without the rest of them cluttering up their apps grid.
Comment 5 Michael Catanzaro 2016-02-22 16:21:17 UTC
(In reply to Matthias Clasen from comment #3)
> One would hope that core apps are not 'random'.

They are not, you know I worked on this quite recently.

However, the system.xml shipped by GNOME Software no longer matches our definition of our core apps (and it never quite matched before, either).

> And that their being
> uninstallable is a problem is a claim that you've made - is there any
> supporting evidence for that ?

I actually do not mind so much either way (though I'm inclined to agree that users should be able to remove or replace applications when it doesn't lead to problems). My primary concern is that GNOME Software currently blocks removing an arbitrary subset of the core apps, which seems to please nobody.
Comment 6 Matthias Clasen 2016-02-22 17:53:51 UTC
(In reply to Jasper St. Pierre from comment #4)
> I've heard it from multiple users. I also don't like it. Just because the
> apps are core, doesn't mean users aren't happier with other alternatives.

How does having core apps installed get in the way of using your favorite alternative ?
Comment 7 Jasper St. Pierre (not reading bugmail) 2016-02-22 18:03:12 UTC
Simple example: I use a different media player from Totem. This different media player doesn't set up MIME type associations, so every time I open up a "new" kind of file format I haven't touched before, I have to set the default association. If I could uninstall Totem, the defaults would be correct.
Comment 8 Matthias Clasen 2016-02-22 18:30:02 UTC
> If I could uninstall Totem, the defaults would be correct.

I don't see how; if the player doesn't set up mime type associations, nothing would offer to launch it to play any kind of file.

This seems a weak argument; the players' installation is just broken.
Comment 9 Jasper St. Pierre (not reading bugmail) 2016-02-22 18:56:16 UTC
No, the player has the correct association, it's just secondary to the core app. Perhaps that's just because there really is only one "default video app", and we shouldn't differentiate between MP4 and MOV files -- maybe you consider that the real bug.

I do think the overview grid having lots of icons you can't remove is a major issue. Four-five pages of app icons isn't good for anything.
Comment 10 Michael Catanzaro 2016-02-24 16:49:48 UTC
Many users want to avoid cluttering the overview with apps they never use.
Comment 11 Matthias Clasen 2016-02-24 16:52:06 UTC
As always, making things optional has a cost too - all of a sudden, we can no longer assume that clicking on a file path will bring up a file manager - it might have been uninstalled. Do we make every app handle that error condition now ?
Comment 12 Allan Day 2016-02-24 17:19:16 UTC
(In reply to Michael Catanzaro from comment #10)
> Many users want to avoid cluttering the overview with apps they never use.

App folders seem well positioned to allow that.
Comment 13 Michael Catanzaro 2016-02-24 18:04:58 UTC
(In reply to Matthias Clasen from comment #11)
> As always, making things optional has a cost too - all of a sudden, we can
> no longer assume that clicking on a file path will bring up a file manager -
> it might have been uninstalled. Do we make every app handle that error
> condition now ?

OK, good point....
Comment 14 Richard Hughes 2016-09-09 08:43:21 UTC
I think we should continue this discussion on a mailing list if it needs to continue.
Comment 15 Michael Catanzaro 2016-09-09 11:45:35 UTC
(In reply to Richard Hughes from comment #14)
> I think we should continue this discussion on a mailing list if it needs to
> continue.

Yeah, we actually discussed this at our release team meeting last month. Matthias and I have a pending action item to discuss it with you... we don't want to impose some preferred behavior on you, and I haven't heard anybody but me support this disable apps idea, but we also don't like the new behavior in 3.22, where (to our understanding) random third-party apps can make themselves uninstallable just by indicating so in appstream metadata. So this is something we want to look at for 3.24.