users of this plasmoid should have the possibility to restrict its use either to the current screen or to all screens (default). otherwise, its use is painful on multi-screen setups. thank you
a simple opinion sharing: in systemsettings > Window Behavior, there is the parameter "multi-screen behavior: separate focus of screens". the management of plasmoids/widgets related to window management should consider this parameter to avoid reporting bugs. see bellow a non-exhaustive list of features that does not take advantage of the general parameter managing multi-screen behavior: - scripts for kwiin - desktop effects > preview cordially
It's not quite clear to me how this would work. Say I have two screens, and some windows open on each. I open the configuration for the Minimize All Windows applet, which is on a panel on screen 1, move the window to screen 2, configure it to select only windows on the current screen. Then when I click the applet, the windows on that screen are minimized (and stored in a list so that clicking the button again will restore these minimized windows). I now configure the applet to minimize windows on all screens (the window was on the other screen, so it's not minimized). What should happen if I click the applet now? Should it restore the windows on screen 1, or minimize the windows on screen 2? I'm also a bit worried about how this would interact with per-screen virtual desktops, once that feature lands.
> ... stored in a list so that clicking the button again will restore these minimized windows) .. if you manage windows via a list, what do you think about a list per screen: each screen having its own list, transferring a window from screen 1 to screen 2 deletes window 1 from list 1 and writes it in list 2 of screen 2. > .. interaction with per-screen virtual desktops ?!! a list per screen and a sub-list per virtual desktop for the same screen wouldn't that be the solution?
(In reply to Cherkah from comment #3) > > ... stored in a list so that clicking the button again will restore these minimized windows) .. > if you manage windows via a list, what do you think about a list per screen: > each screen having its own list, transferring a window from screen 1 to > screen 2 deletes window 1 from list 1 and writes it in list 2 of screen 2. The list only exists while the Minimize All Windows applet is active on a activity/virtual desktop combination, so when you click the button until you either click the button again (when those windows get restored all at once) or when you focus another window on that activity/virtual desktop (when the list gets cleared and the windows stay minimized until you manually restore each window). Having it always operate only on one screen would not be a problem, then the applet is always either active (i.e. will restore windows when clicked) or inactive (will minimize windows when clicked). But when it's configurable, it's not always clear whether the applet is active or not, namely if the user changes the setting while it is active. > > .. interaction with per-screen virtual desktops ?!! > a list per screen and a sub-list per virtual desktop for the same screen > wouldn't that be the solution? The problem here is that the way it's currently intended to work is that the applet would only minimize things on the current virtual desktop. But if the user configures the applet to minimize windows on all screens, but to have separate virtual desktops on the screens, they would likely expect it to minimize windows on the other virtual desktop as well. This would again cause similar issues. For example, the user has 3 virtual desktops and some windows open (and not minimized) on each, and the applet is configured to minimize windows on all screens. Say workspace 1 and 2 are currently displayed. The user clicks the applet, so the windows on workspace 1 and 2 are now minimized. The user switches the screen for virtual desktop 1 to now display virtual desktop 3 instead. On the screens now are virtual desktop 3 (with some windows displayed) and virtual desktop 2 (with all windows minimized). Is the applet now active or not? (It's a bit hard to say how this would exactly work, as the per-screen virtual desktop feature is still being implemented, but I think it's worth thinking about this now so that we don't run into conceptual problems later.)
> Having it always operate only on one screen would not be a problem, in the end multi-screen users will have to place 1 applet/screen so that the thing is easy to achieve and remains simple (i don't think this point is a big problem at all) as for the configuration of the applet why want to assign it? how many users use this applet daily? surely not many. and even less its configuration parameters.. i mean that it is not so determining in a use as well punctual as daily. regards
(In reply to Cherkah from comment #5) > > Having it always operate only on one screen would not be a problem, > > in the end multi-screen users will have to place 1 applet/screen so that the > thing is easy to achieve and remains simple > (i don't think this point is a big problem at all) There are users that only have panels on one screen, so where would they put the applet on the other screen? Placing it on the desktop wouldn't make much sense. But yes, if we could assume that there is always an applet on each screen, it would be simple to do, we could just always minimize all on that screen. It would solve the issues. But I can see thing breaking people's existing workflows, which I would like to avoid. > as for the configuration of the applet why want to assign it? how many users > use this applet daily? surely not many. and even less its configuration > parameters.. > i mean that it is not so determining in a use as well punctual as daily. If we add a configuration option, we have to assume that people are going to use it, or we don't need to add it in the first place. And if we assume that people are going to use it, we should make sure that we work out how it should behave, and how we communicate how the function works to users.