Hi,

I would like to propose an idea and hope for some feedback from you. It is about having an "Alternatives" menu directly in the Help menu of the default application of one kind (e.g. for taking screenshots).

This is what it would/could look like:



(The actual position of the menu item (in this case the last one of the help menu) is just because it was easiest to implement; probably it should be moved to some other place.)

This is the reasoning behind the alternatives menu:

• Similar to the new Plasma5 Alternatives for widgets, this feature would allow the user to explore the own system in the same context where the question for an alternative would come up.
• Having a list of alternative applications build in right into the KDE code supports the idea of a self-documenting system.
  
  • In my personal experience, it requires some tedious web searching in finding decent alternative apps and most application names are not self-explanatory.
• Free software is full of alternatives which is good on the one hand but can be confusing for new users on the other hand. The menu would help those users to take their first "alternatives" steps.
• The "hard-coded" list of alternatives should only contain freedom respecting applications. Having inherently low advertising budget this could benefit these applications.

Note, that in the demo implementation (https://git.reviewboard.kde.org/r/123873/)...

• ...there is only minimal additional code for the target application, see e.g. https://git.reviewboard.kde.org/r/12387 ... dex_header
• ...the list of alternative applications is explicitly NOT maintained in the application itself but centrally in the KDE frameworks component KMoreTools. This means, the application maintainer does not have to worry about maintaining the list and the application code does not get polluted with additions or removals from the list.
• ...all potential quarreling about the actual contents of the alternatives list takes place centrally in only one component.
• if the experiment is considered a failure it can be removed from the concerning application as easy as it would have been added.

There already is an argumentation against the proposal which is documented in this RR https://git.reviewboard.kde.org/r/123873/:

• One point there is that alternative apps are to be searched in the app store / package manager. Having them in the application itself would only confuse the user.
  
  • Following my arguments above, I as a user, would be happy to have some hand-picked alternatives built into the system. But what do others think?
• The other point is that if one application would have alternatives, then all other applications should have them also, for consistency reasons.
  
  • To this I would reply that I see the Alternatives applications feature as desirable but not mandatory at all. It could be added step-by-step mainly to the current DEFAULT applications because that is what the user is confronted by default. (The traditional ways of searching alternatives applications will still be open.)

Apart from spectacle as first candidate for this feature, I see dolphin which could point to krusader (a tool which I find very useful in some cases and which I only found by accident). And there are surely more...