the owner doesn't seem to be saved and restored anywhere, so it may happen that is not deterministic who owns it? (not sure if needed tough)
(btw, if one had an Applet subclass implementation, there is a globalConfig() kconfiggroup thatsaves and reads in an area of appletsrc common for all applets of a given tye

A question: what would happen if a user has existing shortcuts defined already? (I know that's a non-default case)

the owner doesn't seem to be saved and restored anywhere, so it may happen that is not deterministic who owns it? (not sure if needed tough)

In Component.onCompleted it sets itself as owner if its config says the feature is Enabled

btw, if one had an Applet subclass implementation, there is a globalConfig() kconfiggroup thatsaves and reads in an area of appletsrc common for all applets of a given tye

Neat. There I could just store the ID and then we also avoid two applets claiming to be the owner (should not happen but who knows)

what would happen if a user has existing shortcuts defined already?

They won't be re-assigned, ie. if Meta+1 is already something else, it will stay that way. But you can end up with a bit of a mixture of, for example, only Meta+4, Meta+5, Meta+6 being assigned to task manager if the others were occupied.

In D2680#49893, @lbeltrame wrote:

A question: what would happen if a user has existing shortcuts defined already? (I know that's a non-default case)

afaik then the corresponding shortcuts from the taskbar should be disabled by default

Do we really need KActionCollection? At least in KWin I ported away from it, because I don't want the xmlgui dependency.

Isn't needed at all from what I can tell. I could just set the component name property manually and call it a day.

In D2680#49912, @broulik wrote:

Do we really need KActionCollection? At least in KWin I ported away from it, because I don't want the xmlgui dependency.

Isn't needed at all from what I can tell. I could just set the component name property manually and call it a day.

yeah, cool!

I'm kind of wondering about the arch here ... I can see that this works, but is it worth putting complexity like evaluating taskManagerAppletsCount into the QML code, along with all of this register/unregister applet stuff? I feel like this could all be on the C++ side and driven by the constructors+destructors of the Backend class, keeping a static instance counter in there. It would cut down on the boilerplate and avoid exposing the nitty-gritty to the QML code unnecessarily.

In D2680#49986, @hein wrote:

I feel like this could all be on the C++ side and driven by the constructors+destructors of the Backend class, keeping a static instance counter in there. It would cut down on the boilerplate and avoid exposing the nitty-gritty to the QML code unnecessarily.

I tend to agree here

Has the alternative of having a shortcut that shows up small 'hints' on the tasks - number or letter that should be pressed in order to activate the task been considered?

Like Konqueror and KMail had with the 'ctrl'?

Along the lines of https://www.qutebrowser.org/doc/img/hints.png

This would be more scalable than actually registering all these shortcuts.

Has the alternative of having a shortcut that shows up small 'hints' on the tasks - number or letter that should be pressed in order to activate the task been considered?

I thought about, say, longpress Meta and it shows up the numbers but I have no clue how/if this could be implemented. You still need to register all of the shortcuts, though, iirc.

I meant more of a single shortcut 'Meta+PlasmaKey' which focusses on plasma and shows the overlays. No further shortcuts needed.

And this would be possible to generalize later to access systray applets, etc.

In D2680#50099, @ivan wrote:

I meant more of a single shortcut 'Meta+PlasmaKey' which focusses on plasma and shows the overlays. No further shortcuts needed.

And this would be possible to generalize later to access systray applets, etc.

I would actually go one step further: Don't have a single "Plasma shortcut", but just use the existing feature that one can assign a shortcut to an applet, assigning a shortcut to the task manager in our default config(s) (and also one for the systray if we want to make it possible there as well) and when that is pressed, show an overlay with the assigned numers.

Yes, it would mean that switching to a task would take one more key press, but

• It would do away with all the conflicts with multiple task managers
• It would not need any addition config UI
• It would occupy only one shortcut per Plasmoid (so 1 to 2 as I see it now)

any news on that?

monthly ping: What is the status of this? Any unresolved issues?

What is the status of this?

Dunno, somewhat lost motivation, frankly. Imho we need Meta+number, as that's what virtually any other desktop has and what anybody keeps complaining about.

While Meta+some-other-shortcut and then pressing 1 would work for multi-screen (assign a different shortcut per task manager) and I somewhat like that idea – it's much easier to implement on a technical level, at least if you don't go crazy with "plasma overlay that has everything in it" – that's not something I would use if I had to press two distinct keyboard shortcuts.

So, dunno how I should proceed.

My suggestion would be to make meta+number only work for the first task manager on the primary screen. Similar to how we do it with the meta only activation. It only triggers for the first launcher it finds. Yes, it would not support the full flexibility, but we also don't have to support the full flexibility. Sometimes we can go and offer a feature which works for > 90 % of the users and ignore the super-customizers.

As maintainer: I agree with graesslin.

How would I tell the "primary monitor task manager" applet?

We could do the same hack we have with Kickoff, where the first task manager it finds with a global shortcut will be invoked. But that's not really discoverable how to change/why it broke when you created a new panel manually, etc etc.

Ping

How would I tell the "primary monitor task manager" applet?

I would go with following heuristic:

1. Identify primary screen
2. Iterate over all panels by ids
3. Check whether there is a task manager
4. if there is a panel bingo
5. if not go to next screen, till we find a task manager