xmonad-contrib
xmonad-contrib copied to clipboard
xmonad
Rewrite X.U.NamedScratchpad using X.L.Minimize
Using additional "secret" workspace seems to be very hackish way and produces many issues. I think using X.L.Minimize is better for that. X.L.Minimize is not ready for this(it should minimize windows persisting on multiple workspaces correctly) but that's another issue.
Related for X.U.NamedScratchpad: #85 and similar problems
Related for X.L.Minimize: ~~#49~~ #102
@f1u77y is #102 enough for this rewrite? Are there other issues with X.L.Minimize that need to be resolved?
@IvanMalison X.L.Minimize couldn't be used for named scratchpads just because of separate minimized state for one window on different workspaces.
And as I can see @geekosaur does not agree that minimized state should be global(but then I don't understand what's the point of having EWMH-related code in X.L.Minimize; separate state for workspaces are breaking compliance)
@IvanMalison X.L.Minimize couldn't be used for named scratchpads just because of separate minimized state for one window on different workspaces.
Right, that is what I thought -- it seems like #102 fixes that completely, so we should be able to make NamedScratch pad simply use minimization, right?
And as I can see @geekosaur does not agree that minimized state should be global(but then I don't understand what's the point of having EWMH-related code in X.L.Minimize; separate state for workspaces are breaking compliance)
@geekosaur can you clairify your position here?
we should be able to make NamedScratch pad simply use minimization, right?
Another point is that such implementation could cause mess when user minimizes window A, then toggles off some scratchpad B, and then he wants to restore A with withLastMinimized maximizeWindow but restores B. So, maybe this should be separate from minimizing(but use the same idea)
I am not averse to providing an option for it; I am averse to removing the existing behavior entirely, as not everyone uses or wants EWMH. As the current behavior is not the EWMH one, perhaps the correct way to go is an EWMHMinimize separate from the existing one.
On Mon, Nov 21, 2016 at 7:03 PM, Ivan Malison [email protected] wrote:
@IvanMalison https://github.com/IvanMalison X.L.Minimize couldn't be used for named scratchpads just because of separate minimized state for one window on different workspaces.
Right, that is what I thought -- it seems like #102 https://github.com/xmonad/xmonad-contrib/pull/102 fixes that completely, so we should be able to make NamedScratch pad simply use minimization, right?
And as I can see @geekosaur https://github.com/geekosaur does not agree that minimized state should be global(but then I don't understand what's the point of having EWMH-related code in X.L.Minimize; separate state for workspaces are breaking compliance)
@geekosaur https://github.com/geekosaur can you clairify your position here?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xmonad/xmonad-contrib/issues/90#issuecomment-262107145, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8SoDwmhoVFYomkWu_f1Pu40yQ-kfM4ks5rAjE9gaJpZM4KO0xP .
brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
The only difference from current behaviour is that new version minimizes windows, that present on multiple workspaces, on all of them while current minimizes on current one. But current version has code that (un)sets _NET_WM_STATE_HIDDEN and sets window state to Normal/Iconic. That could confuse statusbars/panels or applications themselves. So, the current behaviour is not minimize at all, it is more like "make window invisible on current workspace"
On 11/22/2016 06:35 AM, geekosaur wrote:
I am not averse to providing an option for it; I am averse to removing the existing behavior entirely, as not everyone uses or wants EWMH. As the current behavior is not the EWMH one, perhaps the correct way to go is an EWMHMinimize separate from the existing one.
On Mon, Nov 21, 2016 at 7:03 PM, Ivan Malison [email protected] wrote:
@IvanMalison https://github.com/IvanMalison X.L.Minimize couldn't be used for named scratchpads just because of separate minimized state for one window on different workspaces.
Right, that is what I thought -- it seems like #102 https://github.com/xmonad/xmonad-contrib/pull/102 fixes that completely, so we should be able to make NamedScratch pad simply use minimization, right?
And as I can see @geekosaur https://github.com/geekosaur does not agree that minimized state should be global(but then I don't understand what's the point of having EWMH-related code in X.L.Minimize; separate state for workspaces are breaking compliance)
@geekosaur https://github.com/geekosaur can you clairify your position here?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub
https://github.com/xmonad/xmonad-contrib/issues/90#issuecomment-262107145, or mute the thread
https://github.com/notifications/unsubscribe-auth/AB8SoDwmhoVFYomkWu_f1Pu40yQ-kfM4ks5rAjE9gaJpZM4KO0xP .
brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xmonad/xmonad-contrib/issues/90#issuecomment-262139005, or mute the thread https://github.com/notifications/unsubscribe-auth/AKyf5XnRrTXYHHFhGhC1tasXQLbY_MlIks5rAmMPgaJpZM4KO0xP.
On Tue, Nov 22, 2016 at 12:59 PM, Bogdan Sinitsyn [email protected] wrote:
The only difference from current behaviour is that new version minimizes windows, that present on multiple workspaces, on all of them while current minimizes on current one. But current version has code that (un)sets _NET_WM_STATE_HIDDEN and sets window state to Normal/Iconic. That could confuse statusbars/panels or applications themselves. So, the current behaviour is not minimize at all, it is more like "make window invisible on current workspace"
This already raises several questions, one of which I mentioned before but you apparently decided to ignore.
- There's stuff that already uses/presumably, by your interpretation, "abuses" copyTo... expecting independent control per workspace. Your approach means this is "illegal".
- Your argument still assumes that following EWMH strictly is necessarily the correct behavior. How far do you go with this? We violate this by treating workspaces as things that can move between monitors, instead of considering all monitors to span a single workspace; EWMH does not explicitly say this is wrong but it is implied by the interrelationships between its workspace-related properties. In particular, _NET_WORKAREA will never work the way EWMH expects with a dwm/xmonad workspace model (there's an active ticket about this). Do you in fact assert that following EWMH here is necessary? If not, at what point does it become acceptable to you to depart from strict EWMH behavior?
2a. The dwm/xmonad model also means that EWMH pagers will never work correctly, regardless of the hidden window situation. Do you consider this a bug in xmonad?
brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Just to be clear on this: #2 above is not a question of "if xmonad were clever enough we could make it work". It is a fundamental conflict between the workspace models. You can only "fix" it by changing workspace models completely.
On Tue, Nov 22, 2016 at 1:16 PM, Brandon Allbery [email protected] wrote:
On Tue, Nov 22, 2016 at 12:59 PM, Bogdan Sinitsyn < [email protected]> wrote:
The only difference from current behaviour is that new version minimizes windows, that present on multiple workspaces, on all of them while current minimizes on current one. But current version has code that (un)sets _NET_WM_STATE_HIDDEN and sets window state to Normal/Iconic. That could confuse statusbars/panels or applications themselves. So, the current behaviour is not minimize at all, it is more like "make window invisible on current workspace"
This already raises several questions, one of which I mentioned before but you apparently decided to ignore.
- There's stuff that already uses/presumably, by your interpretation, "abuses" copyTo... expecting independent control per workspace. Your approach means this is "illegal".
- Your argument still assumes that following EWMH strictly is necessarily the correct behavior. How far do you go with this? We violate this by treating workspaces as things that can move between monitors, instead of considering all monitors to span a single workspace; EWMH does not explicitly say this is wrong but it is implied by the interrelationships between its workspace-related properties. In particular, _NET_WORKAREA will never work the way EWMH expects with a dwm/xmonad workspace model (there's an active ticket about this). Do you in fact assert that following EWMH here is necessary? If not, at what point does it become acceptable to you to depart from strict EWMH behavior?
2a. The dwm/xmonad model also means that EWMH pagers will never work correctly, regardless of the hidden window situation. Do you consider this a bug in xmonad?
brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Your approach means this is "illegal"
No, I meant that setting some EWMH state with current minimize behaviour
is illegal because it's better to assume that window is shown while it's
hidden then do the contrary. In other words, I just suggest to remove
setMinimizedState usage from current code of X.L.Minimize because in
my optinion setting no state is better then setting incorrect state.
Your argument still assumes that following EWMH strictly is necessarily the correct behavior.
Okay, I misused words "correct"/"incorrect". That was I called correct is more like familiar to me.
Do you in fact assert that following EWMH here is necessary?
No, and I agree that current behaviour should be left as it was. I'm just talking about removing code, that sets wrong state, from current code.
Do you consider this a bug in xmonad?
No
I use the following code to obtain the titles of all windows managed by XMonad. If there were any open windows, I'd like to abort reboot and shutdown prompts and show the titles of open windows in a message.
import XMonad
import Control.Monad (filterM, join)
titles :: X [String]
titles = do
withDisplay $ \disp -> do
(_, _, ws) <- io $ queryTree disp $ defaultRootWindow disp
join $ mapM (runQuery title) <$> filterM isClient ws
If a scratchpad was minimized, could it be still detected by titles?
It shouldn't be filtered out by filterM isClient. isClient is from XMonad.Operations.
isClient ultimately checks if a window is a XMonad.StackSet.member of the current WindowSet.
I tried to understand the code of Minimize, but it was very difficult to reason about it.
In neither the old nor new styles would it be mapped. It should still be present as a child of the root.
That said, queryTree is rather inefficient. You'd probably do better to use XMonad.StackSet.allWindows. (This also means you can dump the isClient check.)
I am getting the hangs of it, but I don't understand clearly.
Are you saying that XMonad.StackSet.allWindows or isClient would catch minimized windows?
You are safe either way. I'm just suggesting something faster (and less "hammer the X server") than queryTree, and that if you use it you also don't need isClient any more (since isClient just checks if it's in the StackSet somewhere, which it must be if you're getting the window list from the StackSet).
When I wrote titles, I didn't know better, so I ended up using X11 functions.
It turns out that I could just use allWindows. Thanks for the tip. Here's the better version.
import XMonad
import qualified XMonad.StackSet as W
titles :: X [String]
titles = withWindowSet $ mapM (runQuery title) . W.allWindows
@f1u77y @geekosaur I saw that there was some discussion about _NET_WM_STATE_HIDDEN here, but I couldn't tell if a deliberate decision not to set that property in XMonad was made, or if support has simply not yet been implemented.
EDIT: nevermind... ignore this. I see that it is supported.
As discussed in https://github.com/xmonad/xmonad-contrib/issues/591 it's probably worth opening a new issue to brainstorm hot-swappable backends for NSP, in case people are interested.
