Bug 430440 - The "Show in Activities" menu does not work as expected
Summary: The "Show in Activities" menu does not work as expected
Status: REPORTED
Alias: None
Product: kwin
Classification: Plasma
Component: activities (show other bugs)
Version: unspecified
Platform: Neon Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 434621 435892 437826 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-12-15 18:59 UTC by Gaël de Chalendar (aka Kleag)
Modified: 2021-10-19 22:59 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gaël de Chalendar (aka Kleag) 2020-12-15 18:59:34 UTC
SUMMARY


STEPS TO REPRODUCE
1. Create two activities A and B
2. Open an application in activity A
3. Right-click on the window title bar and select "Show in activities" -> "B"

OBSERVED RESULT
The window now is displayed on both activities A and B

EXPECTED RESULT
The window should appear only on activity B. If I wanted to display it in all activities, I would chose "All Activities" in the menu.

The current behavior forces me to do 2 times the same selections.

SOFTWARE/OS VERSIONS
Operating System: KDE neon 5.20
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2
Kernel Version: 5.4.0-56-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz
Memory: 31.2 Gio of RAM
Graphics Processor: llvmpipe

ADDITIONAL INFORMATION
Comment 1 Oded Arbel 2021-02-28 09:54:36 UTC
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.
Comment 2 ederag 2021-07-05 11:42:56 UTC
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.
Comment 3 Oded Arbel 2021-07-05 12:24:13 UTC
(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).
Comment 4 ederag 2021-07-05 13:31:31 UTC
(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 ?
Comment 5 Oded Arbel 2021-07-05 16:13:42 UTC
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.
Comment 6 Gauthier 2021-10-16 07:13:55 UTC
*** Bug 437826 has been marked as a duplicate of this bug. ***
Comment 7 Gauthier 2021-10-16 07:15:21 UTC
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?
Comment 8 Gauthier 2021-10-16 07:41:22 UTC
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).
Comment 9 Gauthier 2021-10-16 07:45:09 UTC
*** Bug 434621 has been marked as a duplicate of this bug. ***
Comment 10 Gauthier 2021-10-16 07:54:53 UTC
*** Bug 435892 has been marked as a duplicate of this bug. ***
Comment 11 Oded Arbel 2021-10-17 07:05:46 UTC
(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.
Comment 12 ederag 2021-10-17 07:52:32 UTC
(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.
Comment 13 Gauthier 2021-10-17 08:47:09 UTC
(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)?
Comment 14 Gauthier 2021-10-17 08:49:36 UTC
I meant to write

> The lack of keyboard shortcut to 

"move a window to activity X" 

> as been pointed out in Bug 411688
Comment 15 Oded Arbel 2021-10-18 06:07:48 UTC
(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)?
Comment 16 Gauthier 2021-10-19 09:18:36 UTC
(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?
Comment 17 ederag 2021-10-19 22:59:18 UTC
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.