Re: Proposal for reducing the number of unremovable apps in GNOME Software



Great discussion! I would encourage making things as customization and personalized as possible, as a principle of open source software.

Let's not make things required and unremovable to the fullest extent possible, to avoid leading consumers down a path of what's right or wrong according to someone's opinion. Linux systems must inspire freedom and choice in use as well as design. We can take Apple as an example of what not to do. We would also benefit from systems that don't easily become obsolete, and inspire the creative use of computers through giving the user access to options.

Some might think that too many options overwhelms users. This is where intelligent UI and design comes in--

Part of the complaints Allan mentioned may have to do more with organization of our app management and structure. This might be what should be tackled. I strongly believe distros can be shipped with consistent experience and gui tools, but having them hard-coded is simply going back to what large corporations are doing to control masses of people.

My proposal is, how can we tackle Allan's three points without making apps mandatory, and rather, allowing users to become engineers of their own systems (if desired)?
​ ​

On Tue, Nov 7, 2017 at 5:05 AM, Allan Day <aday gnome org> wrote:
Bastien Nocera <hadess hadess net> wrote:
...
I don't think that applications such as Calendar, Contacts, or finding
and reminding apps should be removed from the requirements for a well-
rounded, default desktop. How they're installed is a technical question
that's not relevant to the fact that they're needed.

That's certainly true. I'm mostly coming it this from a direction of a) trying to figure out what the user experience will look like on a flatpak-based system and b) having done some digging, feeling somewhat dissatisfied with the current use of <mandatory_for_desktop>. Particular issues that I see:

1. <mandatory_for_desktop> is only respected by Software or other "app centers", so you get different behaviour with the command line, which lets you install and remove apps that Software doesn't. This adds complexity, makes testing difficult, and introduces bugs. It also creates ambiguity; I don't think anyone is really sure what the experience is supposed to be.

2. In Software, <mandatory_for_desktop> is used to hide apps that belong to other desktops. In part I think this is motivated by the desire not to end up with identical apps (because stock apps tend to use the icon theme and often have identical names). However, it has the side-effect that applications that could easily be installed can't be. This is because it equates something being essential to an environment as meaning that it shouldn't be available outside of it, which I don't think is always the case - we might well say that Photos is essential to GNOME 3, but that doesn't necessarily mean that it shouldn't be installable on a non-GNOME system.

3. I guess I just find it strange that this mechanism is so decentralised. Can anyone use <mandatory_for_desktop>? Who makes the decisions about what's included and what isn't? How is that monitored and managed?

Relying an the ostree/flatpak split to determine which apps are removable has some advantages in relation to this - it would remove a layer of configuration, you'd get a consistent experience and GUI tools would be transparent in how they operate, it would be the OS builder who decides what forms part of the product, and projects could decide what to make available as standalone apps simply by making them available as flatpaks or not.

Maybe there are issues with this approach - and I certainly take the point about updates - but maybe it's also illustrative of what we ought to be aiming for.

Allan


______________________________
_________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]