Bug 430440

I have the same issue. In the past it used to be that clicking the activity checkboxes in the "show in activities" menu would not immediately close the menu, so you could just tick any checkboxes you like and ESC the menu, so moving a window to another activity using the keyboard would be:

[windows op menu] -> show in activities -> tick boxes -> ESC

Now its:

[window op menu] -> show in activities -> choose "all" (menu closes) -> [window op meny] -> show in activities -> choose activity.

Granted, in the old way once you uncheck the activity you are currently in - the window would disappear by the menu will try to stay open and some graphical glitches can occur (especially if you have transparent menus) which was not pretty - but at least it was fast.

Agreed with Oded. Previous behavior was good.
It is even clearer with 3 activities A, B and C.
If one wanted an application on B and C,
it was just a matter of checking B and C (and unchecking A).

This is incompatible with the OP,
but I guess that if the selection popup would stay up (as it used to do),
to allow these changes in one go,
the concern would vanish.
In other words, right now, since only one change can be done at a time,
it is normal to expect either only a single activity or all activities),
but this would be too limiting.

(In reply to ederag from comment #2)
> but I guess that if the selection popup would stay up (as it used to do),
> to allow these changes in one go,
> the concern would vanish.

In a discussion bug #438197, it was explained that keeping the menu open after clicking cannot currently be accomplished due to limitation of the Qt library (I'm not sure if the change from the old behavior was because Qt changed or KDE's use of specific Qt classes changed).

(In reply to Oded Arbel from comment #3)
Thanks for the information.
Then here is a proposition:

Popup with these radiobuttons:
- All activities
- only A
- only B
- only C
- some

And anytime the "some" is clicked, a new window appears,
with checkboxes (like the old behavior),
visible on all activities (in case the user would like to see if it worked).
Advantage: 
- quick for simple use case (solves the OP concern)
- still allows the important use case where a window should appear 
only on some activities.
- no flicker, as this new window is separated from the taskbar.
Not as good as seeing and setting checkboxes right away,
but better than current state ?

Looking at the kwin code, I don't think Nate's assertion in the above linked report is correct. I'm working on an MR based on my suggestion from that report on how to implement both "move to" as well as "toggle also on" behaviors, for virtual desktops. If that works, it can also work on activities because it is almost exactly the same code (it actually is two different functions in the same file, that look so similar I'm tempted to refactor out the common behavior).

I'll update.

*** Bug 437826 has been marked as a duplicate of this bug. ***

This is now solved with : https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231

Scheduled for Plasma 5.24 (sad it got missed for 5.23).

Should it get marked as resolved?

Actually I hadn't read all comments, the new menu: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231 solves it to move an activity to only one other one but does not solve the case of ticking several ones.

@Oded Have there been any progress on your MR for VDs, and if so, does it seem likely to also work for activities?

Since the work has started with the MR linked above to solve one use case (i.e. to move an activity), it would be great to solve this bug for selecting several activities and get all of that "Show in activities" function consistent for Plasma 5.24 (and ideally across both kwin and task manager menus).

*** Bug 434621 has been marked as a duplicate of this bug. ***

*** Bug 435892 has been marked as a duplicate of this bug. ***

(In reply to Gauthier from comment #7)
> Should it get marked as resolved?

Looking at the MR that was merged, it adds the workaround to the task bar context menu. This issue is about the window operations menu, so the MR does not solve this issue in that it doesn't fix the window operations menu. I'm not sure what is the use case for the task bar right click menu as I almost never use it and there is no keyboard shortcut to get to it. IMHO the window operations menu should be the target for any improved behavior its better accessible by both keyboard and mouse (Fitz law).

(In reply to Gauthier from comment #8)
> @Oded Have there been any progress on your MR for VDs, and if so, does it
> seem likely to also work for activities?

I did not move forward with my work on the checkboxed window operations submenus (I'm treating desktops and activities the same for this). I didn't have a lot of time for that, but more than that I'm very confused about the situation - in Kwin Wayland there is a workaround for the desktops menu that is very similar in behavior to https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231, but not identical, and of course that it wasn't implemented for activities.

I think before any additional work is done, there should be some effort to understand what is the UX that we are aiming for and how it should apply to all relevant use cases - wayland, x11, window operations menu, plasma shell task bar menus, activities, desktops, whatever else is relevant. Currently there are too many different behaviors for things that should basically be the same. I'm not sure how/where/when/with who to start such a discussion.

On that note, I personally dislike the "dual control" UX that is offered in Wayland windows operation menu and the above mentioned MR: on my systems I have few activities (2 or 3 normally) and many virtual desktops (6 or 8) and while the "checkbox + move to items" is kind of manageable in the activities selection, it is almost unusable for virtual desktops (the wayland window operations desktops menu takes more than half the height of my screen now) - it actually takes noticeable time and thought to locate the menu option I need in order to just move this one window to desktop 4. I believe we can do better, and would like to have a discussion about that.

(In reply to Oded Arbel from comment #11)
> I'm not sure what is the use case for the task bar right click menu [...]

It is very nice to remove a window from an activity without bringing it to focus.

(In reply to Oded Arbel from comment #11)
> (In reply to Gauthier from comment #7)
> > Should it get marked as resolved?
> 
> Looking at the MR that was merged, it adds the workaround to the task bar
> context menu. This issue is about the window operations menu, so the MR does
> not solve this issue in that it doesn't fix the window operations menu.

You are right that technically this bug is about the menu in the title bar so it is not addressed by this new commit. Though the problematic behaviour is the same in both the title bar (kwin) menu and the task manager menu so it is an attempt to start address the issue as a whole. However, I agree with you that the proposed approach in the commit may not be the best (see below in response to your comment).

> I'm not sure what is the use case for the task bar right click menu as I almost
> never use it and there is no keyboard shortcut to get to it. IMHO the window
> operations menu should be the target for any improved behavior its better
> accessible by both keyboard and mouse (Fitz law).

I agree with ederad, it is a common use case, it is nice not to have to bring the window into focus to move them. I use that a lot. The lack of keyboard shortcut to "move to an activity" as been pointed out in Bug 411688

> 
> (In reply to Gauthier from comment #8)
> > @Oded Have there been any progress on your MR for VDs, and if so, does it
> > seem likely to also work for activities?
> 
> I did not move forward with my work on the checkboxed window operations
> submenus (I'm treating desktops and activities the same for this). I didn't
> have a lot of time for that, but more than that I'm very confused about the
> situation - in Kwin Wayland there is a workaround for the desktops menu that
> is very similar in behavior to
> https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231, but not
> identical, and of course that it wasn't implemented for activities.
>
> I think before any additional work is done, there should be some effort to
> understand what is the UX that we are aiming for and how it should apply to
> all relevant use cases - wayland, x11, window operations menu, plasma shell
> task bar menus, activities, desktops, whatever else is relevant. Currently
> there are too many different behaviors for things that should basically be
> the same. I'm not sure how/where/when/with who to start such a discussion.

I agree with you tat this whole things needs tidying up and made consistent across X11/Wayland, Activities, VDs, kwin menu and task manager menu. Not sure where to start either.

> On that note, I personally dislike the "dual control" UX that is offered in
> Wayland windows operation menu and the above mentioned MR: on my systems I
> have few activities (2 or 3 normally) and many virtual desktops (6 or 8) and
> while the "checkbox + move to items" is kind of manageable in the activities
> selection, it is almost unusable for virtual desktops (the wayland window
> operations desktops menu takes more than half the height of my screen now) -
> it actually takes noticeable time and thought to locate the menu option I
> need in order to just move this one window to desktop 4. I believe we can do
> better, and would like to have a discussion about that.

I think you are right here. When I looked at the commit I thought it would only work well if one has only 2/3 activities, but with many, the double of menu items would get long and cumbersome. 
Would it be possible to only keep the tick boxes, but ensure that the menu stays open AND changes are only applied after either: the mouse moves out of the menu (if using the mouse), or the ESC key is pressed (if navigating using the keyboard)?

I meant to write

> The lack of keyboard shortcut to 

"move a window to activity X" 

> as been pointed out in Bug 411688

(In reply to Gauthier from comment #14)
> > The lack of keyboard shortcut to 
> 
> "move a window to activity X" 
> 
> > as been pointed out in Bug 411688

IMO, the ability of the user to assign a custom keyboard shortcut to a "move to activity" operation does not solve the inaccessibility of the taskbar to keyboard operation. Please don't conflate "being able to assign keyboard shortcuts" with "being able to use the keyboard to select and activate things".

My point is that I understand that some people can make a good use the taskbar with a mouse, but as someone who prefers to use the keyboard - the taskbar is completely inaccessible to me and I use it as visual reference only. As such, adding capabilities to the taskbar is *not* a good replacement to missing window operations menu functionality (the window operations menu is *very* keyboard accessible).

(In reply to Gauthier from comment #13)
> Would it be possible to only keep the tick boxes, but ensure that the menu
> stays open AND changes are only applied after either: the mouse moves out of
> the menu (if using the mouse), or the ESC key is pressed (if navigating
> using the keyboard)?

Tying "apply operations" to mouse movement is a problematic proposition - some pointing devices (and some people) are very inaccurate and having a wrong move trigger an operation that takes significant effort to revert (its not just CTRL+Z), will be very frustrating to the user. ESC would work, but you do want additionally something that is both discoverable and can be operated by a mouse.

I thought about this a bit and in the context of a menu we are precluded from a lot of guided interaction we can do with dialogs: you can't have explanatory text and you can't have an "apply" button. There are some use cases that are hard to do "properly" in a menu - so can we just stop pretending to care about them?

I want to support the following use cases:

1. Show the window in all activities.
2. Add the window to this one additional activity.
3. Move the window to this one other activity.

I don't want to support the following use cases as I think they are niche, can be achieved with a combination of actions (1), (2) and (3) (albeit slower, as the menu would need to be reopened), and not worth sacrificing the usability of (1), (2) and (3) for:

4. Add the window to 2 or more additional activities.
5. Move the window to 2 or more other activities.

(all the above also applies to virtual desktops, as appropriate, as it is basically the same thing on a different axis).

What do you think? Do you often find yourself moving a window from the current activity to 2 other activities (as described in comment #2)?

(In reply to Oded Arbel from comment #15)
> (In reply to Gauthier from comment #14)
> > > The lack of keyboard shortcut to 
> > 
> > "move a window to activity X" 
> > 
> > > as been pointed out in Bug 411688
> 
> IMO, the ability of the user to assign a custom keyboard shortcut to a "move
> to activity" operation does not solve the inaccessibility of the taskbar to
> keyboard operation. Please don't conflate "being able to assign keyboard
> shortcuts" with "being able to use the keyboard to select and activate
> things".

Yes you are right, I meant that at least it provides a way for those who use the keyboard to move an activity :)

> My point is that I understand that some people can make a good use the
> taskbar with a mouse, but as someone who prefers to use the keyboard - the
> taskbar is completely inaccessible to me and I use it as visual reference
> only. As such, adding capabilities to the taskbar is *not* a good
> replacement to missing window operations menu functionality (the window
> operations menu is *very* keyboard accessible).

I fully agree that it is not a replacement but the person who worked on this, also tried to address the kwin/title bar menu, they just didn't know how to do it. What I meant is that the process has started trying to solve the issue with "Show in activities" menu(s) as a whole. But yes the kwin / title bar is still not solved needs addressing.
 
> (In reply to Gauthier from comment #13)
> > Would it be possible to only keep the tick boxes, but ensure that the menu
> > stays open AND changes are only applied after either: the mouse moves out of
> > the menu (if using the mouse), or the ESC key is pressed (if navigating
> > using the keyboard)?
> 
> Tying "apply operations" to mouse movement is a problematic proposition -
> some pointing devices (and some people) are very inaccurate and having a
> wrong move trigger an operation that takes significant effort to revert (its
> not just CTRL+Z), will be very frustrating to the user. ESC would work, but
> you do want additionally something that is both discoverable and can be
> operated by a mouse.

While I fully agree with you in principle, and I think you're making very good points regarding accessibility. However in that case I'm not sure it applies since currently the mouse action (a click on a tick box) triggers the apply operation straight away as the menu closes and the change is applied. What I propose is actually a "delay" of the apply operation, until a further mouse action is done, i.e. moving the cursor outside the menu area. What do you think?

> I thought about this a bit and in the context of a menu we are precluded
> from a lot of guided interaction we can do with dialogs: you can't have
> explanatory text and you can't have an "apply" button. There are some use
> cases that are hard to do "properly" in a menu - so can we just stop
> pretending to care about them?
> 
> I want to support the following use cases:
> 
> 1. Show the window in all activities.
> 2. Add the window to this one additional activity.
> 3. Move the window to this one other activity.
> 
> I don't want to support the following use cases as I think they are niche,
> can be achieved with a combination of actions (1), (2) and (3) (albeit
> slower, as the menu would need to be reopened), and not worth sacrificing
> the usability of (1), (2) and (3) for:
> 
> 4. Add the window to 2 or more additional activities.
> 5. Move the window to 2 or more other activities.
> 
> (all the above also applies to virtual desktops, as appropriate, as it is
> basically the same thing on a different axis).
> 
> What do you think? Do you often find yourself moving a window from the
> current activity to 2 other activities (as described in comment #2)?

I would very much agree that we should prioritise the use cases 1. 2. and 3. I would think that even 1. and 3. would be the ultimate priority.

Unless you still think it is a problem, it does feel like my above proposition (apply changes on moving mouse outside the menu / press ESC key) would solve most use cases you've outlined, no?

Ditching the possibility to put a window to several activities
would render activities almost useless at least to me.

If delayed operation is acceptable
(the settings are applied when the menu is closed),
then the OP issue would be solved as well, wouldn't it ?
(check new activity, uncheck old one; no need to reopen the menu)
So the issue is really more about the menu being closed too early.

Reading https://bugs.kde.org/show_bug.cgi?id=438197#c5,
The described behavior seems actually good to me:
the submenu with the checkboxes stays in place until it is left,
either by going to the parent menu if still there, or by clicking outside,
or hitting ESC.

Currently on kwin_wayland, the window operation menu and the taskbar task menu offer the same capabilities, which are:
1. Put the window in all activities (there are actually two intuitive ways to do that).
2. Add the window to one other activity.
3. Move the window to another activity.

While this report is not Wayland specific, and while I haven't used X11 recently to know what's the status there - with the current focus on Plasma 6 and "Wayland first" behavior, I suggest that the current behavior is good enough and this ticket should be closed.