You are the most awesome person in the world today.

Here's a radical thought: get rid of the More menu entirely and move all of its content inline, like so:

          Installed:
SimpleScreenRecorder
-----------------------------
        Not installed:
Peek                       >
Vokoscreen                 >
-----------------------------
Configure...

Or even this:

Open SimpleScreenRecorder
-----------------------------
Install Peek
Install Vokoscreen
-----------------------------
Configure...

...And clicking on the menu items for any of the Install options would open the appstream:// URL, falling back to the home page if no AppStream information is available. I think that would be super slick.

In D13880#286800, @ngraham wrote:

You are the most awesome person in the world today.

Yay!

Here's a radical thought: get rid of the More menu entirely and move all of its content inline, like so:

Sound good to me

And clicking on the menu items for any of the Install options would open the appstream:// URL, falling back to the home page if no AppStream information is available. I think that would be super slick.

That would have been my next patch. Do you know if/how we can check if there is a handler for appstream://? So we can fall back to website if none is available

In D13880#286816, @ngraham wrote:

Or even this:

Open SimpleScreenRecorder
-----------------------------
Install Peek
Install Vokoscreen
-----------------------------
Configure...

Put into code it would look like this

Pro: Very flat hierarchy, code could be simplified a lot
Con: Unwanted and uninstalled tools would be present all the time.

Before I proceed with any idea I would like to have an opinion from @gregormi or @dhaumann

If it's important for uninstalled tools to be not always be visible, maybe what we should do is embed the content of the KNewStuff menu in Spectacle rather than exposing the whole thing as a sub-menu. Then we could make a few string changes, and it would be like this in Spectacle:

No apps installed:

Open Screenshots folder
Print...
Install apps to Record screen    >

One app installed:

Open Screenshots folder
Print...
----------------------------------
         Record screen
Open SimpleScreenRecorder
View Alternatives                >   Peek
                                     Vokoscreen

All apps installed:

Open Screenshots folder
Print...
----------------------------------
         Record screen
Open SimpleScreenRecorder
Open Peek
Open Vokoscreen

This would have the benefit that you could avoid a level of hierarchy for the workflow of actually actually opening an installed screen recording app in Spectacle, but would have the disadvantage that it would involve some additional code changes in Spectacle (and other apps that include the KNewStuff menu as a sub-menu).

You are the most awesome person in the world today.

+1 :-)

Pro: Very flat hierarchy, code could be simplified a lot
Con: Unwanted and uninstalled tools would be present all the time.

Exactly my thoughts. The idea behind the More menu was to hide (a potentially large number) of alternative programs which are not installed and not needed for the user. And even if there is only one alternative not installed program which the user does not want to use, always showing a "Install XYZ" seems a bit obtrusive to me.

https://phabricator.kde.org/D13880#286937

+1 for your suggestions. Downside: higher implementation effort.

A bit of history: When I was creating the More submenu and the Configure... item I was pondering a thing: I was (and still am) not so glad about those two items because they are seldom used but always present in the menu. Back then, I thought about adding a keyboard modifier (like the Shift key) which must be pressed to let the Configure... item appear (similar to the context menu in Windows Explorer where the Shift key let more advanced items appear like Run as admin... etc.). I discarded the idea because of its hard discoverability.

Another alternative would be to somehow hook the Configuration of KMoreTools menus in the host applications main Configure... dialog. Downside: configuration is far away from the actual menu.

It would be cool if instead of the text "Configure..." or "More" there would be a small gear icon that does not take the space of a whole menu item. I suspect this is not possible with QMenus.

In D13880#287481, @gregormi wrote:

+1 for your suggestions. Downside: higher implementation effort.

I like it, too, and I am willing to put effort in it, as soon as we agree on a way forward.

A bit of history: When I was creating the More submenu and the Configure... item I was pondering a thing: I was (and still am) not so glad about those two items because they are seldom used but always present in the menu. Back then, I thought about adding a keyboard modifier (like the Shift key) which must be pressed to let the Configure... item appear (similar to the context menu in Windows Explorer where the Shift key let more advanced items appear like Run as admin... etc.). I discarded the idea because of its hard discoverability.

Another alternative would be to somehow hook the Configuration of KMoreTools menus in the host applications main Configure... dialog. Downside: configuration is far away from the actual menu.

It would be cool if instead of the text "Configure..." or "More" there would be a small gear icon that does not take the space of a whole menu item. I suspect this is not possible with QMenus.

I think this is quite orthogonal to the hierarchy discussion.

@ngraham Your approach makes total sense for Spectacle, but would not be appropriate for e.g. the disk utility or find menu in Dolphin since there is no menu level above to embed the actions. It's no big issue, just something we need to take into account when implementing.

As for the implementation my idea would be:
Additionally to the full menu we expose the top-level applications/more menu as List of Actions/Menu. Then the calling applications can embed them in any way they want.

With this approach this patch would still be an improvement for cases where the old menu is used, e.g. the Dolphin cases I described earlier

I like the idea as well. +1

Sounds good to me! It sounds like we're all in agreement?

The spirit goes in the right direction; please proceed :-). Note, that Kate's project plugin also uses KMoreTools.

What is the current state of this? The new private functions should move to the pimpl class behind the d-pointer.

In general: Looking at the public classes, /all/ the private functions should have been hidden behind the pimpl class...

In D13880#307597, @dhaumann wrote:

What is the current state of this?
The new private functions should move to the pimpl class behind the d-pointer.

In general: Looking at the public classes, /all/ the private functions should have been hidden behind the pimpl class...

We agreed on how we want to structure the menu, but I haven't had time to implement it. IMHO it is out of scope for this patch, though. I think this patch is still an improvement for cases where aforementioned redesign won't be used and worth merging (after I address your comment)

I'm okay with this patch as a first step, FWIW.

Ok - then with minor changes, let's move this forward. Who is going to do the work? :-)

@nicolasfella ping! It would be a shame to lose this since it's already quite a good improvement.

Almost good enough, can you remove the forward declaration again? Just another one-line change. I then don't have any objections anymore.