Re: proposal: Default application functionality criterion reduction

[Kamil Paral <kparal@xxxxxxxxxx>]

On Wed, Mar 4, 2020 at 9:28 PM Ben Cotton <bcotton@xxxxxxxxxxxxxxxxx> wrote:

On Wed, Mar 4, 2020 at 1:55 PM Kamil Paral <kparal@xxxxxxxxxx> wrote:
>
> """
> If there are multiple applications of the same type (e.g. several web browsers), the primary/default one must satisfy the requirements. If the primary/default application can't be determined, only one of said applications must satisfy the requirements.
>
> Note: Determining primary applications
> The usual way to determine a primary/default application is to look into system configuration where default applications are set (e.g. gnome-control-center -> Default Applications), or to launch the default application on an appropriate file type (e.g. double click on an .odt file in a file browser), or to look into a favorites menu section (e.g. KDE menu -> Favorites).
> """

I like it. This seems like a reasonable way to address their concerns.
Another approach could be to have the maintaining SIG provide their
preferred default and in cases where none is provided, at least one
has to work. So maybe, e.g. Llama Spin doesn't care *which* web
browser works, but Alpaca Spin says Firefox has to work even if
another browser is functional.

This essentially lets us go with the original proposal as a default
case instead of having to go through and figure it out (because it may
change from release-to-release, so it has to be verified every cycle)

Yes, that's also an option. However, I intentionally tried to stay away from hard-coding concrete application names in release criteria (doesn't matter who maintains them, whether QA or some SIG). There's a maintenance cost I'd like to avoid. I'm afraid that people will forget to update the criteria when there are changes in the desktop apps. Also, if the list grows and people can't remember it, it might actually be easier to figure out the default application from the desktop environment than open the criteria, find the relevant section, and learn the application names. So I'd rather go with the generic solution, and if it doesn't work well, we can always change it to what you said or something similar.

_______________________________________________
kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kde@xxxxxxxxxxxxxxxxxxxxxxx