From jschoett at gmail.com Fri Jan 1 03:36:58 2016 From: jschoett at gmail.com (=?UTF-8?Q?Jakob_Sch=c3=b6ttl?=) Date: Thu, 31 Dec 2015 19:36:58 -0800 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad In-Reply-To: <6000621.mhuxrWOlJE@navi> References: <5685B5A9.10202@gmail.com> <6000621.mhuxrWOlJE@navi> Message-ID: <5685F45A.2020004@gmail.com> On 31.12.2015 15:25, Bogdan Sinitsyn wrote: > On Thursday, December 31, 2015 3:09:29 PM MSK Jakob Sch?ttl wrote: >> Because there is no hardware keyboard I need a virtual keyboard. I tried >> these programs: xvkbd, matchbox-keyboard, onboard, florence >> >> Some of them work with some other programs. But when it works, it's >> still buggy: >> >> - after typing I have to click two times to a new input field to set focus >> - virtual keyboard steals focus >> - other windows get invisible and only come back when they get focus >> (super+j) >> - doesn't work at all with some programs >> >> Is there a way to get virtual keyboards work with Xmonad, reliably and >> for all programs? >> >> Thank you! >> >> Jakob >> >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > It this virtual keyboard _NET_WM_WINDOW_TYPE_DOCK or smth like this? If not, > it may be useful to make it be of this type. No, at least florence and onboard are not (xprop | grep DOCK). What is this property and how can I set it? From allbery.b at gmail.com Fri Jan 1 03:44:11 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 31 Dec 2015 22:44:11 -0500 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad In-Reply-To: <5685F45A.2020004@gmail.com> References: <5685B5A9.10202@gmail.com> <6000621.mhuxrWOlJE@navi> <5685F45A.2020004@gmail.com> Message-ID: On Thu, Dec 31, 2015 at 10:36 PM, Jakob Sch?ttl wrote: > On 31.12.2015 15:25, Bogdan Sinitsyn wrote: > >> On Thursday, December 31, 2015 3:09:29 PM MSK Jakob Sch?ttl wrote: >> >>> Because there is no hardware keyboard I need a virtual keyboard. I tried >>> these programs: xvkbd, matchbox-keyboard, onboard, florence >>> >>> Some of them work with some other programs. But when it works, it's >>> still buggy: >>> >>> - after typing I have to click two times to a new input field to set >>> focus >>> - virtual keyboard steals focus >>> - other windows get invisible and only come back when they get focus >>> (super+j) >>> - doesn't work at all with some programs >>> >>> Is there a way to get virtual keyboards work with Xmonad, reliably and >>> for all programs? >>> >>> Thank you! >>> >>> Jakob >>> >>> _______________________________________________ >>> xmonad mailing list >>> xmonad at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>> >> It this virtual keyboard _NET_WM_WINDOW_TYPE_DOCK or smth like this? If >> not, >> it may be useful to make it be of this type. >> > No, at least florence and onboard are not (xprop | grep DOCK). > > What is this property and how can I set it? You probably can't set it, at least early enough for it to matter. http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#idm139870830002400 You could however look for other properties in xprop output (probably you wan WM_CLASS) and doIgnore it in the ManageHook so it won't take focus and will float. Do the programs where it doesn't work under xmonad, work with it under another window manager? X11 actually makes this hard to do, for security reasons. xvkbd probably uses sendEvents, which some programs ignore as potential security issues (they are flagged by the X server as synthetic). If you enable the XTest extension and use a virtual keyboard that supports XTest, it will work reliably... but you've opened a bit of a security hole in the X server since now malicious programs can do things like injecting commands into a terminal with a root shell in it. (xmonad has no control whatsoever over this, it is the X server that controls it.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Jan 1 03:54:20 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 31 Dec 2015 22:54:20 -0500 Subject: [xmonad] Slowly, slowly getting calls to getWindowAttributes in XMonad to handle exceptions In-Reply-To: <87a8oq6xie.fsf@tullinup.koldfront.dk> References: <87a8oq6xie.fsf@tullinup.koldfront.dk> Message-ID: On Thu, Dec 31, 2015 at 5:53 PM, Adam Sj?gren wrote: > -- manage a new window > handle (MapRequestEvent {ev_window = w}) = withDisplay $ \dpy -> do > wa <- io $ getWindowAttributes dpy w -- ignore override windows > -- need to ignore mapping requests by managed windows not on the > current workspace > managed <- isClient w > when (not (wa_override_redirect wa) && not managed) $ do manage w > > What needs to happen is that I need to wrap this, so if > getWindowAttributes throws an exception, something reasonable happens. > What exceptions are you expecting? The only one I'd expect is no such window, in which case you kinda want to abort anyway. I've tried a number of combinations of wrapping C.handle around this, > similar to what I have found before?, but I certainly need (to read a > lot more, or, some) help - I keep getting IO () when I need X (), or the > opposite, and stuff like that. > http://xmonad.org/xmonad-docs/xmonad/XMonad-Core.html#v:catchX to catch exceptions from code producing X something. http://xmonad.org/xmonad-docs/xmonad/XMonad-Core.html#v:catchIO to catch exceptions from code producing IO something. (Don't feel too bad about this, it's actually a surprisingly hard problem in the general case. MonadBaseControl grew out of trying to deal with it in various situations, because it's hard to do "catch" properly in a monad over IO and impossible to do "bracket" properly. Specific cases can be done, as above catchX / catchIO, but even then require some thinking to write in the first place.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fercerpav at gmail.com Fri Jan 1 06:37:35 2016 From: fercerpav at gmail.com (Paul Fertser) Date: Fri, 1 Jan 2016 09:37:35 +0300 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad In-Reply-To: <5685B5A9.10202@gmail.com> References: <5685B5A9.10202@gmail.com> Message-ID: <20160101063735.GH22442@home.paul.comp> On Thu, Dec 31, 2015 at 03:09:29PM -0800, Jakob Sch?ttl wrote: > Because there is no hardware keyboard I need a virtual keyboard. I tried > these programs: xvkbd, matchbox-keyboard, onboard, florence I can tell you that I'm very satisfied with xvkbd and Xmonad on my smartphone. Please see http://paste.debian.net/359010/ (as gitorious.org still hasn't migrated the repositories to web archive...). > Some of them work with some other programs. But when it works, it's still > buggy: I didn't notice any issues with the apps I use with this config. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav at gmail.com From bogdan.sinitsyn at gmail.com Fri Jan 1 10:22:47 2016 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Fri, 01 Jan 2016 13:22:47 +0300 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad In-Reply-To: References: <5685B5A9.10202@gmail.com> <5685F45A.2020004@gmail.com> Message-ID: <3339369.Ngr4Pf0afb@navi> On Thursday, December 31, 2015 10:44:11 PM MSK Brandon Allbery wrote: > On Thu, Dec 31, 2015 at 10:36 PM, Jakob Sch?ttl wrote: > > On 31.12.2015 15:25, Bogdan Sinitsyn wrote: > >> On Thursday, December 31, 2015 3:09:29 PM MSK Jakob Sch?ttl wrote: > >>> Because there is no hardware keyboard I need a virtual keyboard. I tried > >>> these programs: xvkbd, matchbox-keyboard, onboard, florence > >>> > >>> Some of them work with some other programs. But when it works, it's > >>> still buggy: > >>> > >>> - after typing I have to click two times to a new input field to set > >>> focus > >>> - virtual keyboard steals focus > >>> - other windows get invisible and only come back when they get focus > >>> (super+j) > >>> - doesn't work at all with some programs > >>> > >>> Is there a way to get virtual keyboards work with Xmonad, reliably and > >>> for all programs? > >>> > >>> Thank you! > >>> > >>> Jakob > >>> > >>> _______________________________________________ > >>> xmonad mailing list > >>> xmonad at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > >> > >> It this virtual keyboard _NET_WM_WINDOW_TYPE_DOCK or smth like this? If > >> not, > >> it may be useful to make it be of this type. > > > > No, at least florence and onboard are not (xprop | grep DOCK). > > > > What is this property and how can I set it? > > You probably can't set it, at least early enough for it to matter. > http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#idm139870830002 > 400 > > You could however look for other properties in xprop output (probably you > wan WM_CLASS) and doIgnore it in the ManageHook so it won't take focus and > will float. > > Do the programs where it doesn't work under xmonad, work with it under > another window manager? X11 actually makes this hard to do, for security > reasons. xvkbd probably uses sendEvents, which some programs ignore as > potential security issues (they are flagged by the X server as synthetic). > If you enable the XTest extension and use a virtual keyboard that supports > XTest, it will work reliably... but you've opened a bit of a security hole > in the X server since now malicious programs can do things like injecting > commands into a terminal with a root shell in it. (xmonad has no control > whatsoever over this, it is the X server that controls it.) If it's just ignored, it theoretically could be overlapped by some new windows. But if xmonad thinks it's strut(it doesn't have to be of the dock type for this), it wouldn't be overlapped. Another solution is to make it always stay on top of other windows, but I don't know how to do it with xmonad if it's ignored. -- Bogdan Sinitsyn From asjo at koldfront.dk Fri Jan 1 14:41:32 2016 From: asjo at koldfront.dk (Adam =?utf-8?Q?Sj=C3=B8gren?=) Date: Fri, 01 Jan 2016 15:41:32 +0100 Subject: [xmonad] Slowly, slowly getting calls to getWindowAttributes in XMonad to handle exceptions References: <87a8oq6xie.fsf@tullinup.koldfront.dk> Message-ID: <87k2nticpv.fsf@tullinup.koldfront.dk> Brandon writes: > On Thu, Dec 31, 2015 at 5:53 PM, Adam Sj?gren wrote: >> -- manage a new window >> handle (MapRequestEvent {ev_window = w}) = withDisplay $ \dpy -> do >> wa <- io $ getWindowAttributes dpy w -- ignore override windows >> -- need to ignore mapping requests by managed windows not on the >> current workspace >> managed <- isClient w >> when (not (wa_override_redirect wa) && not managed) $ do manage w >> >> What needs to happen is that I need to wrap this, so if >> getWindowAttributes throws an exception, something reasonable happens. > What exceptions are you expecting? The only one I'd expect is no such > window, in which case you kinda want to abort anyway. I have put a "putStrLn" in before each call to getWindowAttributes in my local XMonad, and I am recording every time it crashes, so I am not expecting an exception in this place, I had one! Just aborting altogether I think I can manage - I will give it a shot. Thanks! >> I've tried a number of combinations of wrapping C.handle around this, >> similar to what I have found before?, but I certainly need (to read a >> lot more, or, some) help - I keep getting IO () when I need X (), or >> the opposite, and stuff like that. > http://xmonad.org/xmonad-docs/xmonad/XMonad-Core.html#v:catchX to catch > exceptions from code producing X something. > http://xmonad.org/xmonad-docs/xmonad/XMonad-Core.html#v:catchIO to catch > exceptions from code producing IO something. > (Don't feel too bad about this, it's actually a surprisingly hard problem > in the general case. MonadBaseControl grew out of trying to deal with it in > various situations, because it's hard to do "catch" properly in a monad > over IO and impossible to do "bracket" properly. Specific cases can be > done, as above catchX / catchIO, but even then require some thinking to > write in the first place.) (Given how low I am on the understanding-ladder, I don't feel bad at all - I've just come to realize that I need to solve "real" problems to get anywhere, but sometimes I get stuck, and sometimes I am too lazy to loop back to reading up on Haskell, so I ask instead. Thanks for helping!) Best regards, Adam -- "They misunderestimated me." Adam Sj?gren asjo at koldfront.dk From allbery.b at gmail.com Fri Jan 1 14:52:22 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 1 Jan 2016 09:52:22 -0500 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad In-Reply-To: <3339369.Ngr4Pf0afb@navi> References: <5685B5A9.10202@gmail.com> <5685F45A.2020004@gmail.com> <3339369.Ngr4Pf0afb@navi> Message-ID: On Fri, Jan 1, 2016 at 5:22 AM, Bogdan Sinitsyn wrote: > If it's just ignored, it theoretically could be overlapped by some new > windows. But if xmonad thinks it's strut(it doesn't have to be of the dock > type for this), it wouldn't be overlapped. Another solution is to make it > always stay on top of other windows, but I don't know how to do it with > xmonad > if it's ignored. > Only floating windows would overlap it; tiled windows would go below it. I don't think this would be too much of a problem in practice though. (Partly because floating windows are badly behaved anyway --- note that the strut is only applied to tiled windows!) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoett at gmail.com Sat Jan 2 03:49:36 2016 From: jschoett at gmail.com (=?UTF-8?Q?Jakob_Sch=c3=b6ttl?=) Date: Fri, 1 Jan 2016 19:49:36 -0800 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad In-Reply-To: <20160101063735.GH22442@home.paul.comp> References: <5685B5A9.10202@gmail.com> <20160101063735.GH22442@home.paul.comp> Message-ID: <568748D0.8070707@gmail.com> On 31.12.2015 22:37, Paul Fertser wrote: > On Thu, Dec 31, 2015 at 03:09:29PM -0800, Jakob Sch?ttl wrote: >> Because there is no hardware keyboard I need a virtual keyboard. I tried >> these programs: xvkbd, matchbox-keyboard, onboard, florence > I can tell you that I'm very satisfied with xvkbd and Xmonad on my > smartphone. > > Please see http://paste.debian.net/359010/ (as gitorious.org still > hasn't migrated the repositories to web archive...). > >> Some of them work with some other programs. But when it works, it's still >> buggy: > I didn't notice any issues with the apps I use with this config. Thanks for sharing your config! I just tried xvkbd. When ignored it works with all my other programs! (On system, it can only be launched with a terminal and not with dmenu.) I just have to position it somehow. At the moment it's at 0/0. From allbery.b at gmail.com Sat Jan 2 03:50:51 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 1 Jan 2016 22:50:51 -0500 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad In-Reply-To: <568748D0.8070707@gmail.com> References: <5685B5A9.10202@gmail.com> <20160101063735.GH22442@home.paul.comp> <568748D0.8070707@gmail.com> Message-ID: On Fri, Jan 1, 2016 at 10:49 PM, Jakob Sch?ttl wrote: > I just have to position it somehow. At the moment it's at 0/0. Look for a -geometry parameter, or possibly specify one in .Xresources. You probably can't position it within xmonad, at least not sanely. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fercerpav at gmail.com Sat Jan 2 08:09:26 2016 From: fercerpav at gmail.com (Paul Fertser) Date: Sat, 2 Jan 2016 11:09:26 +0300 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad In-Reply-To: References: <5685B5A9.10202@gmail.com> <20160101063735.GH22442@home.paul.comp> <568748D0.8070707@gmail.com> Message-ID: <20160102080926.GJ22442@home.paul.comp> On Fri, Jan 01, 2016 at 10:50:51PM -0500, Brandon Allbery wrote: > On Fri, Jan 1, 2016 at 10:49 PM, Jakob Sch?ttl <[1]jschoett at gmail.com> wrote: > > I just have to position it somehow. At the moment it's at 0/0. > > Look for a -geometry parameter, or possibly specify one in .Xresources. You > probably can't position it within xmonad, at least not sanely. Yes, I just have xvkbd.windowGeometry: 480x200+0+440 xvkbd.compact: true And as you might have noticed, I do not stop it when I need screen space, I just let Xmonad cover it, and once I need the keyboard, I press a hardware button to reveal it back. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav at gmail.com From tuncer.ayaz at gmail.com Sat Jan 2 11:56:13 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sat, 2 Jan 2016 12:56:13 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: <5905100.zN99sIxg7t@navi> References: <87eges6dnq.fsf@pmade.com> <5905100.zN99sIxg7t@navi> Message-ID: On 29 December 2015 at 12:53, Bogdan Sinitsyn wrote: > On Tuesday, December 29, 2015 12:30:39 PM MSK Tuncer Ayaz wrote: > > One thing I've noticed with mpv (and mplayer) is that > > if you enter and leave fullscreen, then the video (inside window) is > > cropped by at least one column of pixels, and the window is not > > restored to its original floating position but moved right+down by one > > or more pixels. These two effects are probably related, but I don't > > see anything wrong with the config. Any idea what's wrong? > > Maybe it's because border width is reapplied by core and then by layout? Is there a fix you would suggest? From tuncer.ayaz at gmail.com Sat Jan 2 12:07:23 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sat, 2 Jan 2016 13:07:23 +0100 Subject: [xmonad] Wayland Message-ID: Wasn't there a GSoC project to add Wayland support? In case you wonder why I'm considering it: Wayland is becoming a serious alternative, especially to solve tearing on newer Intel GPUs. Older Intel GPUs do not tear under Xorg at all, but newer ones tear constantly if you don't force vsync via compton. >From what I gather, this is a solved issue under Wayland. From bogdan.sinitsyn at gmail.com Sun Jan 3 20:21:29 2016 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Sun, 03 Jan 2016 23:21:29 +0300 Subject: [xmonad] More possibilities for border width customization In-Reply-To: References: <45339524.5RmUFrcah5@navi> Message-ID: <2092906.rINBeja33D@navi> On Tuesday, December 29, 2015 4:19:38 PM MSK you wrote: > On Tue, Dec 29, 2015 at 4:10 PM, Brent Yorgey wrote: > > This seems to me like it would be a rather invasive breaking change > > (changing the type of a field in the main xmonad config record). > > Personally I do not think it would be worth it. However if someone makes > > a > > patch, along with a reasoned justification, it will certainly be > > considered. > Not everything belongs in core. What I usually suggest in IRC is: > > setBorder bw = ask >>= \w -> liftX (withDisplay $ \d -> io $ > setWindowBorderWidth d w bw) >> idHook > > and then apply it to windows in the ManageHook. > An argument could possibly be made for that function going into the core... > but probably should start out in contrib. This doesn't help, just like hack with layoutHook similar to X.L.NoBorders Adding something like this to handleEventHook is not so useless, but it shows original borders for some time, so, I think, that's not a solution. -- Bogdan Sinitsyn From dmwit at dmwit.com Mon Jan 4 02:46:56 2016 From: dmwit at dmwit.com (Daniel Wagner) Date: Sun, 3 Jan 2016 18:46:56 -0800 Subject: [xmonad] Not running my startupHook on restart In-Reply-To: <87bn9660ez.fsf@tullinup.koldfront.dk> References: <87bn9660ez.fsf@tullinup.koldfront.dk> Message-ID: On Thu, Dec 31, 2015 at 8:35 AM, Adam Sj?gren wrote: > And then I have changed the restart keybinding like this: > > , ("M-S-r", spawn "xmonad --recompile; export NO_STARTUP_HOOK=1; > xmonad --restart") > > Unfortunately it doesn't work - I guess something "more" is going on To explain the "something more", `xmonad --restart` doesn't do what you think it does. Namely: it just sets a property on the root window and dies; the new xmonad process does *not* start managing windows. Instead, the existing xmonad process notices the property change on the root window and restarts *itself*, passing along its current internal state in command-line parameters. This is why the environment change is not absorbed: only the process that sets a root window property and exits sees the new environment; the existing process' environment, which is the one inherited by the new window manager, is unchanged. You should be able to fix this by setting the environment in-process with System.Environment.setEnv and then directly calling XMonad.Operations.restart (why go through a complicated rigamarole to send yourself a message when you can just pretend you already got it? ;-). Something like this: , ("M-S-r", setEnv "NO_STARTUP_HOOK" "1" >> restart "xmonad" True) ~d -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoett at gmail.com Thu Jan 7 20:30:36 2016 From: jschoett at gmail.com (=?UTF-8?Q?Jakob_Sch=c3=b6ttl?=) Date: Thu, 7 Jan 2016 12:30:36 -0800 Subject: [xmonad] Not running my startupHook on restart In-Reply-To: <874mey5yzz.fsf@tullinup.koldfront.dk> References: <87bn9660ez.fsf@tullinup.koldfront.dk> <874mey5yzz.fsf@tullinup.koldfront.dk> Message-ID: <568ECAEC.1080009@gmail.com> On 31.12.2015 09:06, Adam Sj?gren wrote: > Brandon writes: > >> as <- io getArgs >> when (null as) $ do >> {- your startup code here -} > That worked great - thanks! For me it does not work, I don't know why. myStartupHook = do args <- io getArgs spawn $ "xmessage " ++ show (length args) ... When I restart xmonad, xmessage pops up and shows "0". But `ps aux | grep xmonad` shows me the --resume option and the serialized state in the command line. Any ideas? From allbery.b at gmail.com Thu Jan 7 20:44:32 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 7 Jan 2016 15:44:32 -0500 Subject: [xmonad] Not running my startupHook on restart In-Reply-To: <568ECAEC.1080009@gmail.com> References: <87bn9660ez.fsf@tullinup.koldfront.dk> <874mey5yzz.fsf@tullinup.koldfront.dk> <568ECAEC.1080009@gmail.com> Message-ID: On Thu, Jan 7, 2016 at 3:30 PM, Jakob Sch?ttl wrote: > For me it does not work, I don't know why. > > myStartupHook = do > args <- io getArgs > spawn $ "xmessage " ++ show (length args) > ... > > Actually... I updated to 0.12 and at the same time switched from ghc 7.6.3 to 7.10.3, and found the same thing. I had to move the "args <- io getArgs" directly into "main" before invocation of the "xmonad" function. I haven't yet looked at the code but this seems surprising. I also suspect it's not related to a change in xmonad, since the only core changes (and only a core change could have any effect here) were documentation. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoett at gmail.com Fri Jan 8 02:31:39 2016 From: jschoett at gmail.com (=?UTF-8?Q?Jakob_Sch=c3=b6ttl?=) Date: Thu, 7 Jan 2016 18:31:39 -0800 Subject: [xmonad] Not running my startupHook on restart In-Reply-To: References: <87bn9660ez.fsf@tullinup.koldfront.dk> <874mey5yzz.fsf@tullinup.koldfront.dk> <568ECAEC.1080009@gmail.com> Message-ID: <568F1F8B.9060508@gmail.com> On 07.01.2016 12:44, Brandon Allbery wrote: > > On Thu, Jan 7, 2016 at 3:30 PM, Jakob Sch?ttl > wrote: > > For me it does not work, I don't know why. > > myStartupHook = do > args <- io getArgs > spawn $ "xmessage " ++ show (length args) > ... > > > Actually... I updated to 0.12 and at the same time switched from ghc > 7.6.3 to 7.10.3, and found the same thing. I had to move the "args <- > io getArgs" directly into "main" before invocation of the "xmonad" > function. > > I haven't yet looked at the code but this seems surprising. I also > suspect it's not related to a change in xmonad, since the only core > changes (and only a core change could have any effect here) were > documentation. That works! Thank you. Yeah it sounds like a GHC bug for me. I also have xmonad 0.12 and GHC 7.10.3. -------------- next part -------------- An HTML attachment was scrubbed... URL: From asjo at koldfront.dk Fri Jan 8 07:26:53 2016 From: asjo at koldfront.dk (Adam =?utf-8?Q?Sj=C3=B8gren?=) Date: Fri, 08 Jan 2016 08:26:53 +0100 Subject: [xmonad] Not running my startupHook on restart References: <87bn9660ez.fsf@tullinup.koldfront.dk> <874mey5yzz.fsf@tullinup.koldfront.dk> <568ECAEC.1080009@gmail.com> <568F1F8B.9060508@gmail.com> Message-ID: <87r3hs5y6a.fsf@tullinup.koldfront.dk> Jakob writes: > On 07.01.2016 12:44, Brandon Allbery wrote: >> Actually... I updated to 0.12 and at the same time switched from ghc >> 7.6.3 to 7.10.3, and found the same thing. I had to move the "args >> <- >> io getArgs" directly into "main" before invocation of the "xmonad" >> function. >> I haven't yet looked at the code but this seems surprising. I also >> suspect it's not related to a change in xmonad, since the only core >> changes (and only a core change could have any effect here) were >> documentation. > That works! Thank you. Yeah it sounds like a GHC bug for me. I also > have xmonad 0.12 and GHC 7.10.3. I run xmonad 0.11.1 and ghc 7.10.3 (both on Debian sid), and it works for me (to have "as <- io getArgs" in my startupHook). Just a data point, Adam -- "Boy, I love summer vacation. Adam Sj?gren I can feel my brain beginning to atrophy already." asjo at koldfront.dk From allbery.b at gmail.com Wed Jan 13 19:45:56 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 13 Jan 2016 14:45:56 -0500 Subject: [xmonad] Not running my startupHook on restart In-Reply-To: <87r3hs5y6a.fsf@tullinup.koldfront.dk> References: <87bn9660ez.fsf@tullinup.koldfront.dk> <874mey5yzz.fsf@tullinup.koldfront.dk> <568ECAEC.1080009@gmail.com> <568F1F8B.9060508@gmail.com> <87r3hs5y6a.fsf@tullinup.koldfront.dk> Message-ID: On Fri, Jan 8, 2016 at 2:26 AM, Adam Sj?gren wrote: > Jakob writes: > > On 07.01.2016 12:44, Brandon Allbery wrote: > >> Actually... I updated to 0.12 and at the same time switched from ghc > >> 7.6.3 to 7.10.3, and found the same thing. I had to move the "args > >> <- > >> io getArgs" directly into "main" before invocation of the "xmonad" > >> function. > > > That works! Thank you. Yeah it sounds like a GHC bug for me. I also > > have xmonad 0.12 and GHC 7.10.3. > > I run xmonad 0.11.1 and ghc 7.10.3 (both on Debian sid), and it works > for me (to have "as <- io getArgs" in my startupHook). > Turns out it is a code change. https://github.com/xmonad/xmonad/commit/307b82a53d519f5c86c009eb1a54044a616e4a5c This isn't even mentioned in breaking changes at https://wiki.haskell.org/Xmonad/Notable_changes_since_0.11 There's also documentation in various places that would need to be updated. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvstrand at gmail.com Thu Jan 21 09:30:19 2016 From: tjarvstrand at gmail.com (=?UTF-8?Q?Thomas_J=C3=A4rvstrand?=) Date: Thu, 21 Jan 2016 09:30:19 +0000 Subject: [xmonad] Yet another fullscreen thread... Message-ID: Hi! I'm a happy xmonad user since a couple of years now. Previously I managed to successfully set it up the way I wanted under Ubuntu using Gnome2 but recently I decided I wanted to try something new and installed xfce (xubuntu), under which I'm having some trouble setting the fullscreen functionality which for some reason was working flawlessly under ubuntu 14.04. I have problems getting fullscreen applications to work. Specifically showing media. I have been able to apply the workaround to float VLC but it's a bit annoying since I don't always want to have it fullscreen all the time and I haven't been able to find a good way of switching back and forth. In old Ubuntu 14.04 setup this was just working. In there any other way to solve this than the doFullFloat for VLC? BR Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmwit at dmwit.com Fri Jan 22 05:46:31 2016 From: dmwit at dmwit.com (Daniel Wagner) Date: Thu, 21 Jan 2016 21:46:31 -0800 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: References: Message-ID: It should be possible to find out what geometry the window is asking for. You could use that to decide whether the requested geometry is "big enough" to put full-screen or not. From looking at the source of `doFloat` in xmonad-core, I would guess `liftX . floatLocation` will give you the requested geometry in a `ManageHook`-friendly way. ~d On Thu, Jan 21, 2016 at 1:30 AM, Thomas J?rvstrand wrote: > Hi! > > I'm a happy xmonad user since a couple of years now. Previously I managed > to successfully set it up the way I wanted under Ubuntu using Gnome2 but > recently I decided I wanted to try something new and installed xfce > (xubuntu), under which I'm having some trouble setting the fullscreen > functionality which for some reason was working flawlessly under ubuntu > 14.04. > > I have problems getting fullscreen applications to work. Specifically > showing media. I have been able to apply the workaround to float VLC but > it's a bit annoying since I don't always want to have it fullscreen all the > time and I haven't been able to find a good way of switching back and > forth. In old Ubuntu 14.04 setup this was just working. In there any other > way to solve this than the doFullFloat for VLC? > > BR > Thomas > > > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.sinitsyn at gmail.com Fri Jan 22 06:28:01 2016 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Fri, 22 Jan 2016 09:28:01 +0300 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: References: Message-ID: <3016957.8X4phqv4uY@navi> Windows usually request full-screen by setting _NET_WM_STATE_FULLSCREEN, don't they? Anyway, for me full-screen VLC works using fullscreenSupport from X.L.Fullscreen without any workarounds. Thomas, do you have fullscreenSupport in your configuration? On Thursday, January 21, 2016 9:46:31 PM MSK Daniel Wagner wrote: > It should be possible to find out what geometry the window is asking for. > You could use that to decide whether the requested geometry is "big enough" > to put full-screen or not. From looking at the source of `doFloat` in > xmonad-core, I would guess `liftX . floatLocation` will give you the > requested geometry in a `ManageHook`-friendly way. > > ~d > > On Thu, Jan 21, 2016 at 1:30 AM, Thomas J?rvstrand > > wrote: > > Hi! > > > > I'm a happy xmonad user since a couple of years now. Previously I managed > > to successfully set it up the way I wanted under Ubuntu using Gnome2 but > > recently I decided I wanted to try something new and installed xfce > > (xubuntu), under which I'm having some trouble setting the fullscreen > > functionality which for some reason was working flawlessly under ubuntu > > 14.04. > > > > I have problems getting fullscreen applications to work. Specifically > > showing media. I have been able to apply the workaround to float VLC but > > it's a bit annoying since I don't always want to have it fullscreen all > > the > > time and I haven't been able to find a good way of switching back and > > forth. In old Ubuntu 14.04 setup this was just working. In there any other > > way to solve this than the doFullFloat for VLC? > > > > BR > > Thomas > > > > > > > > _______________________________________________ > > xmonad mailing list > > xmonad at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad -- Bogdan Sinitsyn From allbery.b at gmail.com Fri Jan 22 06:43:04 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 22 Jan 2016 01:43:04 -0500 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: References: Message-ID: On Fri, Jan 22, 2016 at 12:46 AM, Daniel Wagner wrote: > It should be possible to find out what geometry the window is asking for. > You could use that to decide whether the requested geometry is "big enough" > to put full-screen or not. From looking at the source of `doFloat` in > xmonad-core, I would guess `liftX . floatLocation` will give you the > requested geometry in a `ManageHook`-friendly way. fwiw I tracked down a problem with my xmonad.hs to an apparent bug in this which probably plays into the various reports of fullscreen windows having the wrong size when the default borderWidth is nonzero. Haven't looked at the code yet, but be aware that you may need to add 2*borderWidth conf to both height and width to get the correct window size. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Jan 22 06:47:14 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 22 Jan 2016 01:47:14 -0500 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: <3016957.8X4phqv4uY@navi> References: <3016957.8X4phqv4uY@navi> Message-ID: On Fri, Jan 22, 2016 at 1:28 AM, Bogdan Sinitsyn wrote: > Windows usually request full-screen by setting _NET_WM_STATE_FULLSCREEN, > don't > they? > Some programs (notably Firefox) check _NET_SUPPORTED and use the old way (just open a fixed size window, size obtained from the size of the Xinerama screen, or from the root window if there isn't Xinerama info); we do not put _NET_WM_STATE_FULLSCREEN in _NET_SUPPORTED because it's an optional component that needs to be added to handleEventHook and layoutHook, and neither can be introspected to see if it should be advertised or not. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.sinitsyn at gmail.com Fri Jan 22 06:48:24 2016 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Fri, 22 Jan 2016 09:48:24 +0300 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: References: Message-ID: <1958690.En14U6zTGp@navi> On Friday, January 22, 2016 1:43:04 AM MSK Brandon Allbery wrote: > On Fri, Jan 22, 2016 at 12:46 AM, Daniel Wagner wrote: > > It should be possible to find out what geometry the window is asking for. > > You could use that to decide whether the requested geometry is "big > > enough" > > to put full-screen or not. From looking at the source of `doFloat` in > > xmonad-core, I would guess `liftX . floatLocation` will give you the > > requested geometry in a `ManageHook`-friendly way. > > fwiw I tracked down a problem with my xmonad.hs to an apparent bug in this > which probably plays into the various reports of fullscreen windows having > the wrong size when the default borderWidth is nonzero. Haven't looked at > the code yet, but be aware that you may need to add 2*borderWidth conf to > both height and width to get the correct window size. Wouldn't it be better to set border width from fullscreenEventHook? -- Bogdan Sinitsyn From allbery.b at gmail.com Fri Jan 22 06:54:21 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 22 Jan 2016 01:54:21 -0500 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: <1958690.En14U6zTGp@navi> References: <1958690.En14U6zTGp@navi> Message-ID: On Fri, Jan 22, 2016 at 1:48 AM, Bogdan Sinitsyn wrote: > On Friday, January 22, 2016 1:43:04 AM MSK Brandon Allbery wrote: > > On Fri, Jan 22, 2016 at 12:46 AM, Daniel Wagner wrote: > > > It should be possible to find out what geometry the window is asking > for. > > > You could use that to decide whether the requested geometry is "big > > > enough" > > > to put full-screen or not. From looking at the source of `doFloat` in > > > xmonad-core, I would guess `liftX . floatLocation` will give you the > > > requested geometry in a `ManageHook`-friendly way. > > > > fwiw I tracked down a problem with my xmonad.hs to an apparent bug in > this > > which probably plays into the various reports of fullscreen windows > having > > the wrong size when the default borderWidth is nonzero. Haven't looked at > > the code yet, but be aware that you may need to add 2*borderWidth conf to > > both height and width to get the correct window size. > > Wouldn't it be better to set border width from fullscreenEventHook? > That's not the point. floatLocation misreports the requested position and size of *all* windows, because whoever wrote it didn't realize that the border is *inside* the window. And the default border is always set before ManageHook etc. run, which is also before the _NET_WM_STATE_FULLSCREEN change can be communicated to us whether it's by being set at ManageHook time or by sending a message to the root window. This does imply that if you decide to remove the border, you need to adjust the position and size again to compensate. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.sinitsyn at gmail.com Fri Jan 22 07:05:09 2016 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Fri, 22 Jan 2016 10:05:09 +0300 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: References: <1958690.En14U6zTGp@navi> Message-ID: <1552333.puqTzpu643@navi> On Friday, January 22, 2016 1:54:21 AM MSK you wrote: > On Fri, Jan 22, 2016 at 1:48 AM, Bogdan Sinitsyn > wrote: > > On Friday, January 22, 2016 1:43:04 AM MSK Brandon Allbery wrote: > > > On Fri, Jan 22, 2016 at 12:46 AM, Daniel Wagner wrote: > > > > It should be possible to find out what geometry the window is asking > > > > for. > > > > > > You could use that to decide whether the requested geometry is "big > > > > enough" > > > > to put full-screen or not. From looking at the source of `doFloat` in > > > > xmonad-core, I would guess `liftX . floatLocation` will give you the > > > > requested geometry in a `ManageHook`-friendly way. > > > > > > fwiw I tracked down a problem with my xmonad.hs to an apparent bug in > > > > this > > > > > which probably plays into the various reports of fullscreen windows > > > > having > > > > > the wrong size when the default borderWidth is nonzero. Haven't looked > > > at > > > the code yet, but be aware that you may need to add 2*borderWidth conf > > > to > > > both height and width to get the correct window size. > > > > Wouldn't it be better to set border width from fullscreenEventHook? > > That's not the point. floatLocation misreports the requested position and > size of *all* windows, because whoever wrote it didn't realize that the > border is *inside* the window. And the default border is always set before > ManageHook etc. run, which is also before the _NET_WM_STATE_FULLSCREEN > change can be communicated to us whether it's by being set at ManageHook > time or by sending a message to the root window. > > This does imply that if you decide to remove the border, you need to adjust > the position and size again to compensate. If we remove the border before sending any full-screen message to layout, we don't need to adjust the position and size because layout will calculate window size after we remove border. -- Bogdan Sinitsyn From audunskaugen at gmail.com Fri Jan 22 09:16:59 2016 From: audunskaugen at gmail.com (Audun Skaugen) Date: Fri, 22 Jan 2016 10:16:59 +0100 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: References: <3016957.8X4phqv4uY@navi> Message-ID: P? Fri, 22 Jan 2016 07:47:14 +0100, skrev Brandon Allbery : > On Fri, Jan 22, 2016 at 1:28 AM, Bogdan Sinitsyn > wrote: >> Windows usually request full-screen by setting >> _NET_WM_STATE_FULLSCREEN, don't >> they? > > Some programs (notably Firefox) check _NET_SUPPORTED and use the old way > (just open a fixed size window, size obtained from the size of >the > Xinerama screen, or from the root window if there isn't Xinerama info); > we do not put _NET_WM_STATE_FULLSCREEN in _NET_SUPPORTED >because it's > an optional component that needs to be added to handleEventHook and > layoutHook, and neither can be introspected to see if >it should be > advertised or not. Author of X.L.Fullscreen here. Would it be a good idea to provide a startupHook in the module which sets the _NET_SUPPORTED property? So people who use the layout modifiers could broadcast this support to client applications. -- Audun Skaugen -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Jan 22 14:17:32 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 22 Jan 2016 09:17:32 -0500 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: References: <3016957.8X4phqv4uY@navi> Message-ID: On Fri, Jan 22, 2016 at 4:16 AM, Audun Skaugen wrote: > Author of X.L.Fullscreen here. Would it be a good idea to provide a > startupHook in the module which sets the _NET_SUPPORTED property? So people > who use the layout modifiers could broadcast this support to client > applications. I'm working on a redesign of EWMH that will make this stuff more sensible. That said, it might be useful as a stopgap, since (a) the rewrite is going slowly (b) backward compatibility is Hard and I may just ditch it. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Jan 22 14:22:27 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 22 Jan 2016 09:22:27 -0500 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: <1552333.puqTzpu643@navi> References: <1958690.En14U6zTGp@navi> <1552333.puqTzpu643@navi> Message-ID: On Fri, Jan 22, 2016 at 2:05 AM, Bogdan Sinitsyn wrote: > If we remove the border before sending any full-screen message to layout, > we > don't need to adjust the position and size because layout will calculate > window size after we remove border. > We are supposed to guess beforehand that a normal window that gets fullscreened (this is the case that requires the handleEventHook) needs its border removed? Or that we should do so after it is removed from the tile but before we receive the message telling us to remove it from the tile and fullscreen it? I'm really not sure what window model you are using, but it doesn't seem to be X11's. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.sinitsyn at gmail.com Fri Jan 22 15:03:49 2016 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Fri, 22 Jan 2016 18:03:49 +0300 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: References: <1552333.puqTzpu643@navi> Message-ID: <2505136.deWoRAnzM4@navi> On Friday, January 22, 2016 9:22:27 AM MSK you wrote: > On Fri, Jan 22, 2016 at 2:05 AM, Bogdan Sinitsyn > wrote: > > If we remove the border before sending any full-screen message to layout, > > we > > don't need to adjust the position and size because layout will calculate > > window size after we remove border. > > We are supposed to guess beforehand that a normal window that gets > fullscreened (this is the case that requires the handleEventHook) needs its > border removed? Or that we should do so after it is removed from the tile > but before we receive the message telling us to remove it from the tile and > fullscreen it? > > I'm really not sure what window model you are using, but it doesn't seem to > be X11's. Event hook for full-screen windows already exists in X.L.Fullscreen. If we add removing and re-applying borders just before sending messages to layout in that hook(X.L.Fullscreen.fullscreenEventHook, it'll work fine. -- Bogdan Sinitsyn From tjarvstrand at gmail.com Fri Jan 22 15:07:48 2016 From: tjarvstrand at gmail.com (=?UTF-8?Q?Thomas_J=C3=A4rvstrand?=) Date: Fri, 22 Jan 2016 15:07:48 +0000 Subject: [xmonad] Yet another fullscreen thread... In-Reply-To: <2505136.deWoRAnzM4@navi> References: <1552333.puqTzpu643@navi> <2505136.deWoRAnzM4@navi> Message-ID: Thanks everyone for you replies! I'm not exactly what you would call well versed in Haskell but with some clues from above and some googling I think I managed to solve it with the below change: - , handleEventHook = ewmhDesktopsEventHook + , handleEventHook = ewmhDesktopsEventHook <+> fullscreenEventHook Thomas fre 22 jan. 2016 kl 16:03 skrev Bogdan Sinitsyn : > On Friday, January 22, 2016 9:22:27 AM MSK you wrote: > > On Fri, Jan 22, 2016 at 2:05 AM, Bogdan Sinitsyn < > bogdan.sinitsyn at gmail.com> > > wrote: > > > If we remove the border before sending any full-screen message to > layout, > > > we > > > don't need to adjust the position and size because layout will > calculate > > > window size after we remove border. > > > > We are supposed to guess beforehand that a normal window that gets > > fullscreened (this is the case that requires the handleEventHook) needs > its > > border removed? Or that we should do so after it is removed from the tile > > but before we receive the message telling us to remove it from the tile > and > > fullscreen it? > > > > I'm really not sure what window model you are using, but it doesn't seem > to > > be X11's. > > Event hook for full-screen windows already exists in X.L.Fullscreen. If we > add > removing and re-applying borders just before sending messages to layout in > that hook(X.L.Fullscreen.fullscreenEventHook, it'll work fine. > > -- > Bogdan Sinitsyn > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmonad at zevv.nl Tue Jan 26 08:49:02 2016 From: xmonad at zevv.nl (Ico) Date: Tue, 26 Jan 2016 09:49:02 +0100 Subject: [xmonad] Mouse focus without entering window Message-ID: <1453797809-sup-1469@pruts.nl> Hi Xmonad, I'd like xmonad to give focus to the window under my mouse cursor, independent of entering or leaving the window. Consider the following use case: one workspace with two windows. The mouse and focus are both in the left window. I use the keyboard to give focus to the right window (alt-tab or similar). To give focus back to the left window by mouse, I first need to move the mouse outside and then back into the window. Instead i'd like focus to pop back to window one as soon as I move the mouse. (Yes, I know I could/should give focus back with alt tab again, but that is not the point I have more similar use cases, some using multiple work spaces, where I'd like to see he same focus behaviour. According to #xmonad on irc some would consider this behaviour buggy, which I can understand. Is there still a way to make Xmonad act like described? Thank you, Ico -- :wq ^X^Cy^K^X^C^C^C^C From andrewjsw at gmail.com Tue Jan 26 19:24:18 2016 From: andrewjsw at gmail.com (Andrew Sackville-West) Date: Tue, 26 Jan 2016 19:24:18 +0000 Subject: [xmonad] Mouse focus without entering window In-Reply-To: <1453797809-sup-1469@pruts.nl> References: <1453797809-sup-1469@pruts.nl> Message-ID: One solution, while not ideal, is to morph the pointer to follow window focus. Then grabbing the mouse and moving it to the desired window would force focus to follow you back there. This isn't strictly what you're asking for but does provide a pretty intuitive recovery of mouse oriented focus. Look at XMonad.Actions.UpdatePointer A On Tue, Jan 26, 2016 at 12:49 AM Ico wrote: > Hi Xmonad, > > I'd like xmonad to give focus to the window under my mouse cursor, > independent of entering or leaving the window. > > Consider the following use case: one workspace with two windows. The > mouse and focus are both in the left window. I use the keyboard to give > focus to the right window (alt-tab or similar). To give focus back to > the left window by mouse, I first need to move the mouse outside and > then back into the window. Instead i'd like focus to pop back to window > one as soon as I move the mouse. (Yes, I know I could/should give focus > back with alt tab again, but that is not the point > > I have more similar use cases, some using multiple work spaces, where > I'd like to see he same focus behaviour. > > According to #xmonad on irc some would consider this behaviour buggy, > which I can understand. Is there still a way to make Xmonad act like > described? > > Thank you, > > Ico > > -- > :wq > ^X^Cy^K^X^C^C^C^C > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmonad at zevv.nl Tue Jan 26 19:40:31 2016 From: xmonad at zevv.nl (Ico) Date: Tue, 26 Jan 2016 20:40:31 +0100 Subject: [xmonad] Mouse focus without entering window In-Reply-To: References: <1453797809-sup-1469@pruts.nl> Message-ID: <1453837074-sup-3117@pruts.nl> Hi Samuli and Andrew, * On 2016-01-26 20:24:18 +0100, Andrew Sackville-West wrote: > > Look at XMonad.Actions.UpdatePointer Thanks for pointing me to UpdatePointer. It's indeed not exactly what I ment, but I guess it is close enough and solves my problem for now. Ico -- :wq ^X^Cy^K^X^C^C^C^C From kurnevsky at gmail.com Wed Jan 27 05:46:12 2016 From: kurnevsky at gmail.com (=?UTF-8?B?0JXQstCz0LXQvdC40Lkg0JrRg9GA0L3QtdCy0YHQutC40Lk=?=) Date: Wed, 27 Jan 2016 08:46:12 +0300 Subject: [xmonad] Mouse focus without entering window In-Reply-To: <1453837074-sup-3117@pruts.nl> References: <1453797809-sup-1469@pruts.nl> <1453837074-sup-3117@pruts.nl> Message-ID: Be careful - with XMonad.Actions.UpdatePointer mouse cursor gets stuck in the monitor corners sometimes. I made pull request to fix this https://github.com/xmonad/xmonad-contrib/pull/17 , but it is not merget at the moment. 2016-01-26 22:40 GMT+03:00 Ico : > Hi Samuli and Andrew, > > * On 2016-01-26 20:24:18 +0100, Andrew Sackville-West wrote: > > > > Look at XMonad.Actions.UpdatePointer > > Thanks for pointing me to UpdatePointer. It's indeed not exactly what I > ment, but I guess it is close enough and solves my problem for now. > > Ico > > -- > :wq > ^X^Cy^K^X^C^C^C^C > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -- ? ?????????, ?????????? ???????. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomi at nomi.cz Wed Jan 27 18:15:42 2016 From: tomi at nomi.cz (Tomas Janousek) Date: Wed, 27 Jan 2016 19:15:42 +0100 Subject: [xmonad] google code issues In-Reply-To: References: <87k2t86yph.fsf@pmade.com> Message-ID: <20160127181542.GB53667@nomi.cz> Hi all, On Sat, Aug 22, 2015 at 02:22:04PM -0400, Brandon Allbery wrote: > xmonad and xmonad-contrib repos added; aavogt and byorgey added as > maintainers, I presume others will be needed/wanted. (I may go hunting for > github ids of people already listed on xmonad.org) Could someone please push a notice to the old darcs repos saying they are abandoned? I've been doing darcs pulls on a semi-monthly basis for the last 6 years and it took me a few months to realize that ?No remote patches to pull in!? means the code was moved instead of xmonad finally being perfect and needing no further changes whatsoever. :-) In the unlikely event I'm not alone, it may help someone realize this sooner. Thanks. -- Tom?? Janou?ek, a.k.a. Pivn?k, a.k.a. Liskni_si, http://work.lisk.in/ From vogt.adam at gmail.com Wed Jan 27 19:01:14 2016 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 27 Jan 2016 14:01:14 -0500 Subject: [xmonad] google code issues In-Reply-To: <20160127181542.GB53667@nomi.cz> References: <87k2t86yph.fsf@pmade.com> <20160127181542.GB53667@nomi.cz> Message-ID: On Wed, Jan 27, 2016 at 1:15 PM, Tomas Janousek wrote: > Hi all, > > On Sat, Aug 22, 2015 at 02:22:04PM -0400, Brandon Allbery wrote: > > xmonad and xmonad-contrib repos added; aavogt and byorgey added as > > maintainers, I presume others will be needed/wanted. (I may go hunting > for > > github ids of people already listed on xmonad.org) > > Could someone please push a notice to the old darcs repos saying they are > abandoned? > > I've been doing darcs pulls on a semi-monthly basis for the last 6 years > and > it took me a few months to realize that ?No remote patches to pull in!? > means the code was moved instead of xmonad finally being perfect and > needing > no further changes whatsoever. :-) > > In the unlikely event I'm not alone, it may help someone realize this > sooner. > Thanks. > Hi Tomas, The two repos now have a _darcs/prefs/motd that tells people to go to github Regards, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at genaud.net Wed Jan 27 21:20:41 2016 From: alex at genaud.net (Alexander Genaud) Date: Wed, 27 Jan 2016 22:20:41 +0100 Subject: [xmonad] minimal easy Xmonad 0.11.1 on Lubuntu 15.10 with lxpanel 0.8.1 Message-ID: was "Vanilla Xmonad distribution" virtualbox on windows 10 created a vmachine with 600 MB RAM and 6 GB disk mounted lubuntu 15.10 32-bit iso installed, eject iso, restart, login, terminal # apt-get install xmonad $ mkdir ~/.xmonad $ cat > ~/.xmonad/xmonad.hs import XMonad import XMonad.Config.Desktop main = xmonad $ desktopConfig { modMask = mod4Mask , terminal = "lxterminal" } $ echo "exec lxpanel &" > ~/.xmonad/xmonad-session-rc logout, select XMonad (top right), login -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmwit at dmwit.com Sun Jan 31 20:26:39 2016 From: dmwit at dmwit.com (Daniel Wagner) Date: Sun, 31 Jan 2016 12:26:39 -0800 Subject: [xmonad] Mouse focus without entering window In-Reply-To: References: <1453797809-sup-1469@pruts.nl> <1453837074-sup-3117@pruts.nl> Message-ID: You should be able to do this with the `handleEventHook` [1], for which the `MotionEvent` [2] is the appropriate event to handle. You should be able to use `focus` [3] on the `Window` contained in the event to focus the window the mouse is currently over. Caveat emptor, this advice is entirely untested -- no idea what odd corners there are, or even whether it will work (e.g. I vaguely recall that xmonad used to ignore motion events in some circumstances; I don't see that in the code now but I wouldn't be surprised if it were still the case somehow). ~d [1] http://hackage.haskell.org/package/xmonad-0.12/docs/XMonad-Core.html#v:handleEventHook [2] http://hackage.haskell.org/package/X11-1.6.1.2/docs/Graphics-X11-Xlib-Extras.html#v:MotionEvent [3] http://hackage.haskell.org/package/xmonad-0.12/docs/XMonad-Operations.html#v:focus On Tue, Jan 26, 2016 at 9:46 PM, ??????? ?????????? wrote: > Be careful - with XMonad.Actions.UpdatePointer mouse cursor gets stuck in > the monitor corners sometimes. I made pull request to fix this > https://github.com/xmonad/xmonad-contrib/pull/17 , but it is not merget > at the moment. > > 2016-01-26 22:40 GMT+03:00 Ico : > >> Hi Samuli and Andrew, >> >> * On 2016-01-26 20:24:18 +0100, Andrew Sackville-West wrote: >> > >> > Look at XMonad.Actions.UpdatePointer >> >> Thanks for pointing me to UpdatePointer. It's indeed not exactly what I >> ment, but I guess it is close enough and solves my problem for now. >> >> Ico >> >> -- >> :wq >> ^X^Cy^K^X^C^C^C^C >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> > > > > -- > ? ?????????, ?????????? ???????. > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Jan 31 22:06:14 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 31 Jan 2016 17:06:14 -0500 Subject: [xmonad] Mouse focus without entering window In-Reply-To: References: <1453797809-sup-1469@pruts.nl> <1453837074-sup-3117@pruts.nl> Message-ID: On Sun, Jan 31, 2016 at 3:26 PM, Daniel Wagner wrote: > You should be able to do this with the `handleEventHook` [1], for which > the `MotionEvent` [2] is the appropriate event to handle. You should be > able to use `focus` [3] on the `Window` contained in the event to focus the > window the mouse is currently over Isn't this basically takeTopFocus (i.e. ICCCM WM_TAKE_FOCUS)? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: