|Summary:||Attaching windows to activities is too clumsy|
|Product:||[Plasma] kwin||Reporter:||artem <artem.rizhov>|
|Component:||activities||Assignee:||KWin default assignee <kwin-bugs-null>|
|Severity:||normal||CC:||dolgener, kdebugs, lnxusr, moltonel|
|Latest Commit:||http://commits.kde.org/kde-workspace/b0c1a197d30f42fc405586aff18cd21ea3e46037||Version Fixed In:||4.10.2|
Menu demo with autohiding
Description artem 2011-10-04 11:09:22 UTC
Comment 1 artem 2011-10-04 11:31:04 UTC
About checkboxes vs radiobuttons. Actually, checkboxes make sense when you have more then two activities. You can wish to show some window in two activities but not in third one. But anyway there should be easy way to MOVE window between activities in one click, like it is possible with desktops. And ofcourse both activities and desktops submenu should work the same way while they looks similar. If you want to provide such ability, one solution is to replace the "all activities" menu item with "multiple activities". If "multiple activities" is unchecked, selecting another activity moves the window and unchecks the current activity. If you select "multiple activities", it selects all activities automatically, all checkboxes became checked, so it works like extended "all activities" checkbox, and you don't have to click on each other activity to select all activities. But if you want to define some more complex rule, you have to uncheck the annecessary activities. If you unchecked all activities but one, the "multiple activities" became unchecked automatically, again, to awoid too many clicks. If you uncheck "multiple activities", it unchecks all activities automatically except of first selected (or even last time selected). Another good thing is to keep the submenu opened after clicking on the menu item in case the "multiple activities" item is selected, but hide when focus is lost. So you don't have to open it again and again if you want to select/unselect few activities. Otherwise, if "multiple activities" is uchecked then the menu should be hidden right after selecting activity, like it works right now.
Comment 2 Vincent de Phily 2012-05-31 11:28:00 UTC
Try as I might, I don't understand artem's second paragraph, so I'm affraid it'll be complex to use too. I suggest instead (similar to artem's third paragraph) to have radio buttons in the menu : one for each activity (which will handle the common "move to another single activity" action), and one labeled "multiple activities" which opens a child window that stays open untill dismissed and has a checkbox for each activity instead of radiobuttons.
Comment 3 artem 2012-05-31 13:48:13 UTC
Comment 4 artem 2012-05-31 13:51:39 UTC
Comment 5 Thomas Lübking 2012-05-31 15:02:19 UTC
any opinions about preventing the popup from autoclosing when checking an item?
Comment 6 artem 2012-05-31 15:58:39 UTC
Created attachment 71476 [details] Menu demo with autohiding I've added few variants to the demo which show various autohiding methods.
Comment 7 artem 2012-05-31 16:02:54 UTC
(In reply to comment #5) > any opinions about preventing the popup from autoclosing when checking an > item? IMHO, most adequate variants are "Closing on radio" and "Always closing". And I'm not sure what is better. Another variants seem a bit confusing (see the updated demo)
Comment 8 artem 2012-05-31 16:11:05 UTC
One more note to my proposition. When uncheck "Multiple activities", the current one should be selected to prevent window from playing hide-and-seek. My demo does not reflect this because there is no current acitivity. Maybe I'll implement activities on the next update ))
Comment 9 artem 2012-06-01 12:34:54 UTC
(In reply to comment #5) > any opinions about preventing the popup from autoclosing when checking an > item? Also, what about holding shift or ctrl to prevent autoclosing? This may be easy to use. But I don't know how to hint the user at this feature.
Comment 10 Vincent de Phily 2012-06-01 16:40:18 UTC
I think "closing on radio" is the one we want here, otherwise we get back to the usability problem we started with (having to reopen the menu multiple times). If it can be implemented like this, I'm happy. But I'm afraid that we'll have technical problems trying to alter the behaviour of the Qt menu to stay open, or to change its content from radiobuttons to checkboxes without closing it first. Don't want to have some ugly hacks to make it work on all platforms. This is why I was sugesting a menu with all radio buttons: (*) Multiple activities ( ) First activity ( ) Second activity ( ) Third activity but when "Multiple activities" is clicked, a new window (not a menu) opens and allows you to choose any combination via checkboxes. It's not as elegant UI-wise, but it may be a safer choice Bug-wise.
Comment 11 artem 2012-06-01 16:55:58 UTC
(In reply to comment #10) > I think "closing on radio" is the one we want here, otherwise we get back to > the usability problem we started with (having to reopen the menu multiple > times). > But I'm afraid that we'll have technical problems trying to alter the > behaviour of the Qt menu to stay open, This is the only real problem that I'd check if it is really exists or not. > or to change its content from > radiobuttons to checkboxes without closing it first. This problem may be avoided by using checkboxes instead radiobuttons, just changing behaviour. > This is why I was sugesting a menu with all radio buttons: > (*) Multiple activities > ( ) First activity > ( ) Second activity > ( ) Third activity > but when "Multiple activities" is clicked, a new window (not a menu) opens > and allows you to choose any combination via checkboxes. If it appears impossible to keep the menu opened, maybe it makes sense to replace the whole submenu with a new window? It should not be a problem to implement any logic this way.
Comment 12 Vincent de Phily 2012-06-02 17:18:39 UTC
I think we agree on the desired behaviour (the "close on radio" one for you demo being the best one). It'now up to a developer to see if some compromise needs to be made.
Comment 13 Thomas Lübking 2012-12-15 16:50:15 UTC
*** Bug 303982 has been marked as a duplicate of this bug. ***
Comment 14 Thomas Lübking 2012-12-15 16:50:26 UTC
*** Bug 308486 has been marked as a duplicate of this bug. ***
Comment 15 Thomas Lübking 2012-12-15 16:52:40 UTC
Also see bug #305758 (MW action proposal)
Comment 16 Thomas Lübking 2012-12-30 22:37:06 UTC
Comment 17 Thomas Lübking 2013-01-21 20:45:47 UTC
*** Bug 311862 has been marked as a duplicate of this bug. ***
Comment 18 Thomas Lübking 2013-03-24 21:54:44 UTC
Git commit b0c1a197d30f42fc405586aff18cd21ea3e46037 by Thomas Lübking. Committed on 24/03/2013 at 21:57. Pushed by luebking into branch 'KDE/4.10'. use QWidgetAction for activity setting in alt+f3 not that i really like using QWidgetAction, but it'll prevent the popup from autoclosing. Introduce activityUpdateBlocking to prevent users from removing the popup under their fingertips FIXED-IN: 4.10.2 REVIEW: 107762 M +19 -4 kwin/client.cpp M +3 -0 kwin/client.h M +24 -5 kwin/useractions.cpp http://commits.kde.org/kde-workspace/b0c1a197d30f42fc405586aff18cd21ea3e46037