Re: Re: Proposal for reducing the number of unremovable apps in GNOME Software
Le mar. 7 nov. 2017 à 16:11, PWR PWR a écrit : Great discussion! I would encourage making things as customization and personalized as possible, as a principle of open source software. *snip* having them hard-coded is simply going back to what large corporations are doing to control masses of people. Hi, I have the feeling you are mixing two orthogonal concepts: configuration and free software. The core principle of free software is to give power to its users by giving them rights, not buttons and switches. Limiting configuration is in no way comparable to the mass control you are referring to: free software allows you to can patch and fork, to have somebody to do it for you or to use a different yet similar system. That being said, I agree that this is a great discussion. ☺ Cheers, Adrien Plazas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for reducing the number of unremovable apps in GNOME Software
On Mon, 2017-11-06 at 11:15 +, Allan Day wrote: > Emmanuele Bassi wrote: > ... > > > > This does not mean that gnome-screenshot should be made > > unremovable, > > but it definitely needs some additional thought. > > > > Documentation is another factor to consider. Currently, if you look > up how > to take a screenshot, the docs tell you to use the screenshot app > [1]. > > Allan > > [1] > https://git.gnome.org/browse/gnome-user-docs/tree/gnome-help/C/screen > -shot-record.page?h=gnome-3-26 This is definitely something to look at. Setting aside for the moment the fact that gnome-help has atrophied again lately (sorry), the stuff we tell people to do in that document reflects what GNOME considers to be the core, immutable experience. In the long ago past, the docs team had a very difficult time writing instructions for a bucket of parts. The unified experience of GNOME 3 has made that easier (tho there's still been disagreement about whether to direct people to things like Tweak Tool). I don't know that allowing apps to be uninstalled necessarily changes what we write. We could still write for the default experience, and if the user uninstalls something, that's their problem. But it arguably starts us back on a path of partsbucketism. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
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 wrote: > Bastien Nocera 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 . Particular > issues that I see: > > 1. 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, 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 ? 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
Re: Proposal for reducing the number of unremovable apps in GNOME Software
On Tue, Nov 7, 2017 at 5:05 AM, Allan Day wrote: 3. I guess I just find it strange that this mechanism is so decentralised. Can anyone use ? Yes. Who makes the decisions about what's included and what isn't? How is that monitored and managed? Application developers make the decision themselves by specifiying it in the application's metainfo.xml/appdata.xml. It's certainly suboptimal. There used to be a list of "core" desktop files maintained by GNOME Software, so this was not a problem. But this metadata wound up being pushed into appstream a couple years ago. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for reducing the number of unremovable apps in GNOME Software
Bastien Nocera 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 . Particular issues that I see: 1. 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, 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 ? 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
