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 <a...@gnome.org> wrote: > Bastien Nocera <had...@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 >
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
