From soliditsallgood at mailbox.org Sat Jan 8 16:46:21 2022 From: soliditsallgood at mailbox.org (Solid) Date: Sat, 08 Jan 2022 17:46:21 +0100 Subject: [xmonad] Vote for the new XMonad logo! Message-ID: <87v8yunpk2.fsf@hyperspace> Hi, this is a quick reminder that people have one week left to vote for a new XMonad logo! Since there were some concerns regarding having to have a GitHub account in order to participate, we'd like to offer an alternative way of voting—simply reply to this thread. Below are the summarised rules; for more information, as well as the logos themselves, see the GitHub Discussions page[1]: For voting, we will use an instant-runoff[2] type system. In short: - Users rank _a minimum of five (5) submissions_ (by name) according to their preferences in decreasing order (you can vote for your own submission). - If a logo wins a majority of first-preference votes (> 50%) it is chosen. - If not, we eliminate the logo with the least amount of first preference votes, exposing the second preference of those who voted for it. - Rinse and repeat until we have a majority. - If at the end of all that we still don't have a majority, we will act as a tiebreaker and internally vote for a winner from the remaining logos. We will retain veto power in case of inappropriate logos. Team members whose submitted entries are amongst the remaining choices will not partake in the potential tiebreaking vote. Cheers, Tony [1]: https://github.com/xmonad/xmonad/discussions/359 [2]: https://en.wikipedia.org/wiki/Instant-runoff_voting From fa-ml at ariis.it Sat Jan 8 18:26:53 2022 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 8 Jan 2022 19:26:53 +0100 Subject: [xmonad] Vote for the new XMonad logo! In-Reply-To: <87v8yunpk2.fsf@hyperspace> References: <87v8yunpk2.fsf@hyperspace> Message-ID: Il 08 gennaio 2022 alle 17:46 Solid ha scritto: > this is a quick reminder that people have one week left to vote for a > new XMonad logo! Since there were some concerns regarding having to > have a GitHub account in order to participate, we'd like to offer an > alternative way of voting—simply reply to this thread. 1. Gradient Patriot 2. Phoenix 3. Constructor 4. miminalist 5. XMondrian From info at mito-space.com Sat Jan 8 21:58:11 2022 From: info at mito-space.com (mito) Date: Sat, 8 Jan 2022 22:58:11 +0100 Subject: [xmonad] Vote for the new XMonad logo! In-Reply-To: <87v8yunpk2.fsf@hyperspace> References: <87v8yunpk2.fsf@hyperspace> Message-ID: <4ad47c77-4d08-0a99-1424-5b57d4060035@mito-space.com> Am 08.01.22 um 17:46 schrieb Solid: > Hi, > > this is a quick reminder that people have one week left to vote for a > new XMonad logo! Since there were some concerns regarding having to > have a GitHub account in order to participate, we'd like to offer an > alternative way of voting—simply reply to this thread. 1. minimalist 2. muelphil's submission 2 3. Crowbar 4. Haskell meets X 5. Gradient Patriot From martin-alpers at web.de Sun Jan 9 13:34:47 2022 From: martin-alpers at web.de (Martin Alpers) Date: Sun, 9 Jan 2022 14:34:47 +0100 Subject: [xmonad] Vote for the new XMonad logo! In-Reply-To: <87v8yunpk2.fsf@hyperspace> References: <87v8yunpk2.fsf@hyperspace> Message-ID: 1. Haskell meets X 2. New Monad 3. >X= 4. curvy wide 5. Crowbar 6. Phoenix 7. minimalist -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From info at mito-space.com Wed Jan 12 21:40:52 2022 From: info at mito-space.com (mito) Date: Wed, 12 Jan 2022 22:40:52 +0100 Subject: [xmonad] managehook: How to shift apps to a screen in dual-head? Message-ID: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> Hi all! I got a proper dual-head xrandr configuration with one monitor in landscape view and one in portrait view. So in xmonad I have 2x10 workspaces, which is fine. Sure I can manually navigate and switch the focus or push clients to a specific monitor/screen by mod+{w,e} etc., no problem. – But how to initially shift programs to workspaces on a specific monitor (in myManageHook)? Cheers From soliditsallgood at mailbox.org Thu Jan 13 06:48:25 2022 From: soliditsallgood at mailbox.org (Solid) Date: Thu, 13 Jan 2022 07:48:25 +0100 Subject: [xmonad] managehook: How to shift apps to a screen in dual-head? In-Reply-To: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> References: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> Message-ID: <87h7a82ksm.fsf@hyperspace> Hi, On Wed, Jan 12 2022 22:40, mito wrote: > I got a proper dual-head xrandr configuration with one monitor in > landscape view and one in portrait view. So in xmonad I have 2x10 > workspaces, which is fine. Are you using IndependentScreens or something? Having more screens for multi-head setups is not the default behaviour. > But how to initially shift programs to workspaces on a specific > monitor (in myManageHook)? There is screenWorkspace[1] to get the workspace of some monitor, which could then be used in a manageHook as normal -- for monitor 1 (≡ the second one; we are 0-indexed) appName =? "my-app" --> maybe mempty doShift =<< liftX (screenWorkspace 1) Tony [1]: https://hackage.haskell.org/package/xmonad-0.17.0/docs/XMonad-Operations.html#v:screenWorkspace From info at mito-space.com Thu Jan 13 15:50:57 2022 From: info at mito-space.com (mito) Date: Thu, 13 Jan 2022 16:50:57 +0100 Subject: [xmonad] managehook: How to shift apps to a screen in dual-head? In-Reply-To: <87h7a82ksm.fsf@hyperspace> References: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> <87h7a82ksm.fsf@hyperspace> Message-ID: <8ea71089-07b8-1cda-9abb-1f888a22c2ff@mito-space.com> Thanks for your response! Am 13.01.22 um 07:48 schrieb Solid: > Hi, > > On Wed, Jan 12 2022 22:40, mito wrote: >> I got a proper dual-head xrandr configuration with one monitor in >> landscape view and one in portrait view. So in xmonad I have 2x10 >> workspaces, which is fine. > Are you using IndependentScreens or something? Well, no, though I read about it. But I do have: import qualified Graphics.X11.Xinerama > Having more screens for multi-head setups is not the default behaviour. Yeah, I am not sure if I understand that completely; it seems to me "screen" is the xmonad term for "monitor" or 'physical display', right? On the other hand, maybe "screen" might be the combined 'view port' of all connected displays I am currently looking at; I guess that's the xinerama thing (and why the same wallpaper is shared [and not repeated on each monitor]). – Call me a dummy, but that's still not quite clear to me though I consulted xmonad docs and configurations; hence I am asking... >> But how to initially shift programs to workspaces on a specific >> monitor (in myManageHook)? > There is screenWorkspace[1] to get the workspace of some monitor, which > could then be used in a manageHook as normal > > -- for monitor 1 (≡ the second one; we are 0-indexed) > appName =? "my-app" --> maybe mempty doShift =<< liftX (screenWorkspace 1) > > Tony > > [1]: https://hackage.haskell.org/package/xmonad-0.17.0/docs/XMonad-Operations.html#v:screenWorkspace > Boy, I am way outdated~ I thought it was rather "className", and "XMonad.Operations" is part of the core module then? So one just optionally needs an additional 'liftX screenWorkspace' hook? Sounds great! And compiles well. – But yet it has no effect, whatever screenWorkspace {0,1} (or {app,class}Name) I choose: the workspace fits, but the monitor selection is ignored. From soliditsallgood at mailbox.org Fri Jan 14 07:42:30 2022 From: soliditsallgood at mailbox.org (Solid) Date: Fri, 14 Jan 2022 08:42:30 +0100 Subject: [xmonad] managehook: How to shift apps to a screen in dual-head? In-Reply-To: <8ea71089-07b8-1cda-9abb-1f888a22c2ff@mito-space.com> References: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> <87h7a82ksm.fsf@hyperspace> <8ea71089-07b8-1cda-9abb-1f888a22c2ff@mito-space.com> Message-ID: <87k0f2rcex.fsf@hyperspace> On Thu, Jan 13 2022 16:50, mito wrote: >>> I got a proper dual-head xrandr configuration with one monitor in >>> landscape view and one in portrait view. So in xmonad I have 2x10 >>> workspaces, which is fine. >> Are you using IndependentScreens or something? > Well, no, though I read about it. > > But I do have: > > import qualified Graphics.X11.Xinerama Then you shouldn't have 2x10 workspaces but only your "original" 10, since both monitors can use them. >> Having more screens for multi-head setups is not the default behaviour. > Yeah, I am not sure if I understand that completely; it seems to me > "screen" is the xmonad term for "monitor" or 'physical display', right? Sorry, I meant to say > Having more _workspaces_ for multi-head setups is not the default > behaviour. But you are correct that, in xmonad, a screen is a monitor. > Boy, I am way outdated~ > I thought it was rather "className", and "XMonad.Operations" is part of > the core module then? `className` is just another way of matching windows, I chose `appName` for no particular reason (the former matches on the first string in WM_CLASS and the latter on the second one). Yes, XMonad.Operations is part of the `xmonad` package itself, not contrib. > So one just optionally needs an additional 'liftX screenWorkspace' hook? > Sounds great! > And compiles well. – But yet it has no effect, whatever screenWorkspace > {0,1} (or {app,class}Name) I choose: the workspace fits, but the monitor > selection is ignored. That's weird, because I just tried it and it actually works for me. Specifically I used something like myManageHook :: ManageHook myManageHook = mconcat [ -- ... other stuff ... , className =? "mpv" --> maybe mempty doShift =<< liftX (screenWorkspace 1) ] for my manageHook and now mpv does indeed seem to always spawn on the currently focused workspace of the second monitor. Tony From info at mito-space.com Mon Jan 17 15:40:58 2022 From: info at mito-space.com (mito) Date: Mon, 17 Jan 2022 16:40:58 +0100 Subject: [xmonad] managehook: How to shift apps to a screen in dual-head? In-Reply-To: <87k0f2rcex.fsf@hyperspace> References: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> <87h7a82ksm.fsf@hyperspace> <8ea71089-07b8-1cda-9abb-1f888a22c2ff@mito-space.com> <87k0f2rcex.fsf@hyperspace> Message-ID: <70528554-20f4-a8dd-c75b-a6004ce0e1b8@mito-space.com> Am 14.01.22 um 08:42 schrieb Solid: > On Thu, Jan 13 2022 16:50, mito wrote: >>>> I got a proper dual-head xrandr configuration with one monitor in >>>> landscape view and one in portrait view. So in xmonad I have 2x10 >>>> workspaces, which is fine. >>> Are you using IndependentScreens or something? >> Well, no, though I read about it. >> >> But I do have: >> >> import qualified Graphics.X11.Xinerama > Then you shouldn't have 2x10 workspaces but only your "original" 10, > since both monitors can use them. OK, now it seems to work as you say – in KDE5/Plasma. My problem was in Trinity, which is KDE3.5; screens are managed a bit different there. So one just optionally needs an additional 'liftX screenWorkspace' hook? On the other side, clients in Trinity don't swap monitors automatically if there was an empty screen; which was handy. They just were sticky if you don't shift them manually. Now in Plasma clients swap monitors again though I changed from "W.greedyView" to "W.view"... >> Sounds great! >> And compiles well. – But yet it has no effect, whatever screenWorkspace >> {0,1} (or {app,class}Name) I choose: the workspace fits, but the monitor >> selection is ignored. > That's weird, because I just tried it and it actually works for me. > Specifically I used something like > > myManageHook :: ManageHook > myManageHook = mconcat > [ -- ... other stuff ... > , className =? "mpv" --> maybe mempty doShift =<< liftX (screenWorkspace 1) > ] > > for my manageHook and now mpv does indeed seem to always spawn on the > currently focused workspace of the second monitor. > > Tony Well, alternatively one could spawn an app via hotkeys with an additional "xdotool key Super_L+{w,e}" (w/ mod4-mask). Is there already a hotkey for toggling 'clients on monitors switching'? (I mean, client A on screen 0 shifts to screen 1 & client B on screen 1 shifts to screen 0 simultaneously.) From info at mito-space.com Mon Jan 17 16:13:22 2022 From: info at mito-space.com (mito) Date: Mon, 17 Jan 2022 17:13:22 +0100 Subject: [xmonad] managehook: How to shift apps to a screen in dual-head? In-Reply-To: <70528554-20f4-a8dd-c75b-a6004ce0e1b8@mito-space.com> References: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> <87h7a82ksm.fsf@hyperspace> <8ea71089-07b8-1cda-9abb-1f888a22c2ff@mito-space.com> <87k0f2rcex.fsf@hyperspace> <70528554-20f4-a8dd-c75b-a6004ce0e1b8@mito-space.com> Message-ID: Edit in addition to last post: Am 17.01.22 um 16:40 schrieb mito: > OK, now it seems to work as you say – in KDE5/Plasma. > My problem was in Trinity, which is KDE3.5; screens are managed a bit > different there. > So one just optionally needs an additional 'liftX screenWorkspace' hook? > > On the other side, clients in Trinity don't swap monitors > automatically if there was an empty screen; which was handy. They just > were sticky if you don't shift them manually. > > Now in Plasma clients swap monitors again though I changed from > "W.greedyView" to "W.view"... > In other words: How to make clients sticky to a monitor/screen (in KDE5/Plasma) when changing workspaces even if the other screen is empty (to not swap them back by an extra mod-{e,w,r})? It's quite frustrating when properly arranged clients are always swapped to the wrong screen after it happened that was empty before on another workspace. From info at mito-space.com Mon Jan 17 17:08:16 2022 From: info at mito-space.com (mito) Date: Mon, 17 Jan 2022 18:08:16 +0100 Subject: [xmonad] managehook: ... dual-head & screen sticking clients In-Reply-To: References: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> <87h7a82ksm.fsf@hyperspace> <8ea71089-07b8-1cda-9abb-1f888a22c2ff@mito-space.com> <87k0f2rcex.fsf@hyperspace> <70528554-20f4-a8dd-c75b-a6004ce0e1b8@mito-space.com> Message-ID: <355e18f5-7a73-0a26-d830-e32720546464@mito-space.com> Additional edit (2): Am 17.01.22 um 17:13 schrieb mito: > Edit in addition to last post: > > Am 17.01.22 um 16:40 schrieb mito: >> OK, now it seems to work as you say – in KDE5/Plasma. >> My problem was in Trinity, which is KDE3.5; screens are managed a bit >> different there. >> So one just optionally needs an additional 'liftX screenWorkspace' hook? >> >> On the other side, clients in Trinity don't swap monitors >> automatically if there was an empty screen; which was handy. They >> just were sticky if you don't shift them manually. >> >> Now in Plasma clients swap monitors again though I changed from >> "W.greedyView" to "W.view"... >> > In other words: How to make clients sticky to a monitor/screen (in > KDE5/Plasma) when changing workspaces even if the other screen is > empty (to not swap them back by an extra mod-{e,w,r})? > > It's quite frustrating when properly arranged clients are always > swapped to the wrong screen after it happened that was empty before on > another workspace. Now (in dual-head), when switching workspaces, only one monitor/screen switches. So it would be of help *all screens* switch, too, and hence the complete workspace's 'view port'. – IMO "import qualified Graphics.X11.Xinerama" should do this, and that module treats both monitors as one in combination. As mentioned earlier, it works in Trinity (a.k.a. TDE=KDE3.5), so am I missing something in KDE5? From allbery.b at gmail.com Mon Jan 17 17:14:21 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 17 Jan 2022 12:14:21 -0500 Subject: [xmonad] managehook: ... dual-head & screen sticking clients In-Reply-To: <355e18f5-7a73-0a26-d830-e32720546464@mito-space.com> References: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> <87h7a82ksm.fsf@hyperspace> <8ea71089-07b8-1cda-9abb-1f888a22c2ff@mito-space.com> <87k0f2rcex.fsf@hyperspace> <70528554-20f4-a8dd-c75b-a6004ce0e1b8@mito-space.com> <355e18f5-7a73-0a26-d830-e32720546464@mito-space.com> Message-ID: On Mon, Jan 17, 2022 at 12:09 PM mito wrote: > Now (in dual-head), when switching workspaces, only one monitor/screen > switches. So it would be of help *all screens* switch, too, and hence > the complete workspace's 'view port'. – IMO "import qualified > Graphics.X11.Xinerama" should do this, and that module treats both > monitors as one in combination. Importing a module in Haskell only makes names available; it does not and can not perform any actions. Additionally, that is a low level module which exposes the X11-layer multiscreen support, not xmonad's. If you really want both screens to switch at the same time, you might be interested in https://hackage.haskell.org/package/xmonad-contrib-0.17.0/docs/XMonad-Actions-DynamicWorkspaceGroups.html. > As mentioned earlier, it works in Trinity (a.k.a. TDE=KDE3.5), so am I > missing something in KDE5? Are you talking about Trinity's window manager, or xmonad? xmonad (and dwm) divide workspaces up between monitors; most window managers treat a workspace as spanning all monitors. -- brandon s allbery kf8nh allbery.b at gmail.com From info at mito-space.com Mon Jan 17 17:20:22 2022 From: info at mito-space.com (mito) Date: Mon, 17 Jan 2022 18:20:22 +0100 Subject: [xmonad] managehook: ... dual-head & screen sticking clients In-Reply-To: References: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> <87h7a82ksm.fsf@hyperspace> <8ea71089-07b8-1cda-9abb-1f888a22c2ff@mito-space.com> <87k0f2rcex.fsf@hyperspace> <70528554-20f4-a8dd-c75b-a6004ce0e1b8@mito-space.com> <355e18f5-7a73-0a26-d830-e32720546464@mito-space.com> Message-ID: <5a910e72-786f-962b-df1e-ae7b57bcd82d@mito-space.com> Am 17.01.22 um 18:14 schrieb Brandon Allbery: > On Mon, Jan 17, 2022 at 12:09 PM mito wrote: >> Now (in dual-head), when switching workspaces, only one monitor/screen >> switches. So it would be of help *all screens* switch, too, and hence >> the complete workspace's 'view port'. – IMO "import qualified >> Graphics.X11.Xinerama" should do this, and that module treats both >> monitors as one in combination. > Importing a module in Haskell only makes names available; it does not > and can not perform any actions. Additionally, that is a low level > module which exposes the X11-layer multiscreen support, not xmonad's. > > If you really want both screens to switch at the same time, you might > be interested in > https://hackage.haskell.org/package/xmonad-contrib-0.17.0/docs/XMonad-Actions-DynamicWorkspaceGroups.html. Thanks, will look into it! ^^ >> As mentioned earlier, it works in Trinity (a.k.a. TDE=KDE3.5), so am I >> missing something in KDE5? > Are you talking about Trinity's window manager, or xmonad? xmonad (and > dwm) divide workspaces up between monitors; most window managers treat > a workspace as spanning all monitors. > Sorry – to be more precisely: Xmonad as the WM (replacing kwin_x11) in Trinity. From info at mito-space.com Mon Jan 17 18:12:55 2022 From: info at mito-space.com (mito) Date: Mon, 17 Jan 2022 19:12:55 +0100 Subject: [xmonad] managehook: ... dual-head & screen sticking clients In-Reply-To: <5a910e72-786f-962b-df1e-ae7b57bcd82d@mito-space.com> References: <1abfcc59-b302-bc2f-c937-710d312d5400@mito-space.com> <87h7a82ksm.fsf@hyperspace> <8ea71089-07b8-1cda-9abb-1f888a22c2ff@mito-space.com> <87k0f2rcex.fsf@hyperspace> <70528554-20f4-a8dd-c75b-a6004ce0e1b8@mito-space.com> <355e18f5-7a73-0a26-d830-e32720546464@mito-space.com> <5a910e72-786f-962b-df1e-ae7b57bcd82d@mito-space.com> Message-ID: <5945c8a8-d928-e626-6733-c57fd1633fde@mito-space.com> Am 17.01.22 um 18:20 schrieb mito: > Am 17.01.22 um 18:14 schrieb Brandon Allbery: >> On Mon, Jan 17, 2022 at 12:09 PM mito wrote: >>> Now (in dual-head), when switching workspaces, only one monitor/screen >>> switches. So it would be of help *all screens* switch, too, and hence >>> the complete workspace's 'view port'. – IMO "import qualified >>> Graphics.X11.Xinerama" should do this, and that module treats both >>> monitors as one in combination. >> Importing a module in Haskell only makes names available; it does not >> and can not perform any actions. Additionally, that is a low level >> module which exposes the X11-layer multiscreen support, not xmonad's. >> >> If you really want both screens to switch at the same time, you might >> be interested in >> https://hackage.haskell.org/package/xmonad-contrib-0.17.0/docs/XMonad-Actions-DynamicWorkspaceGroups.html. >> > Thanks, will look into it! ^^ > Done . . . Looks quite interesting; however Idk if this would solve my issue (or I don't get its purpose exactly). I don't intend to use complete "sets of workspaces" (like topics?), rather switching both screens at once when changing workspaces (to avoid client-screen swapping). Anyway, addRawWSGroup :: WSGroupId -> [(ScreenId , WorkspaceId )] -> X () has drawn my attention . . . >>> As mentioned earlier, it works in Trinity (a.k.a. TDE=KDE3.5), so am I >>> missing something in KDE5? >> Are you talking about Trinity's window manager, or xmonad? xmonad (and >> dwm) divide workspaces up between monitors; most window managers treat >> a workspace as spanning all monitors. >> > Sorry – to be more precisely: Xmonad as the WM (replacing kwin_x11) in > Trinity. And yes, since Plasma wanted to re-invent the virtual desktop, dual-head screens are now seen as two separate ones, which can be individually customized with different wallpapers and bling such as "Activities". -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at mito-space.com Mon Jan 17 19:43:52 2022 From: info at mito-space.com (mito) Date: Mon, 17 Jan 2022 20:43:52 +0100 Subject: [xmonad] Complex hotkeys definition Message-ID: <7bc6cbd9-0e64-aa94-b84f-2be85f593fbb@mito-space.com> Dear all, yet I failed properly occasionally extending "myHotkeys" commands with additional arguments, e.g. like also spawning something when switching workspaces. Say, the default is something like: myHotkeys = [           ...           , ("M-2", windows $ W.view "2")           ...           ] for hitting for changing to workspace "2". But what if I wanted to additionally execute some extra command or app – such as launching "konsole" (just for testing; I am going to do something else)? Simply editing and adding stuff link           , ("M-2", windows $ W.view "2" $ spawn "konsole") or           , ("M-2", windows $ W.view "2" . spawn "konsole") or           , ("M-2", windows $ W.view "2" || spawn "konsole") or           , ("M-2", windows $ W.view "2" <+> spawn "konsole") doesn't work, due to compilation errors. I am no programmer and haven't yet found the right operators or order; or am I missing brackets? And I don't get the error logs in detail really. Thanks in advance! From allbery.b at gmail.com Mon Jan 17 20:10:41 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 17 Jan 2022 15:10:41 -0500 Subject: [xmonad] Complex hotkeys definition In-Reply-To: <7bc6cbd9-0e64-aa94-b84f-2be85f593fbb@mito-space.com> References: <7bc6cbd9-0e64-aa94-b84f-2be85f593fbb@mito-space.com> Message-ID: You have two problems. The first is that `$` extends as far as possible, so `spawn` ends up being grouped with `W.view` instead of with `windows`; fix this by using explicit parentheses instead of `$`, that is `windows (W.view "2")`. The second is that the correct operator to use is either `*>` or `>>`. Although you will then discover a third problem, which is a race condition because `spawn` is asynchronous (Linux is not Windows), meaning sometimes the new window will open on the previously active workspace. You may want to use https://hackage.haskell.org/package/xmonad-contrib-0.17.0/docs/XMonad-Actions-SpawnOn.html#v:spawnOn instead (don't forget to add https://hackage.haskell.org/package/xmonad-contrib-0.17.0/docs/XMonad-Actions-SpawnOn.html#v:manageSpawn to the `manageHook` or it won't work). On Mon, Jan 17, 2022 at 2:44 PM mito wrote: > > Dear all, > > yet I failed properly occasionally extending "myHotkeys" commands with > additional arguments, e.g. like also spawning something when switching > workspaces. > > Say, the default is something like: > > myHotkeys = [ > ... > , ("M-2", windows $ W.view "2") > ... > ] > > for hitting for changing to workspace "2". > > But what if I wanted to additionally execute some extra command or app – > such as launching "konsole" (just for testing; I am going to do > something else)? > > Simply editing and adding stuff link > > , ("M-2", windows $ W.view "2" $ spawn "konsole") > or > , ("M-2", windows $ W.view "2" . spawn "konsole") > or > , ("M-2", windows $ W.view "2" || spawn "konsole") > or > , ("M-2", windows $ W.view "2" <+> spawn "konsole") > > doesn't work, due to compilation errors. > > I am no programmer and haven't yet found the right operators or order; > or am I missing brackets? > And I don't get the error logs in detail really. > > Thanks in advance! > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad -- brandon s allbery kf8nh allbery.b at gmail.com From info at mito-space.com Mon Jan 17 20:44:54 2022 From: info at mito-space.com (mito) Date: Mon, 17 Jan 2022 21:44:54 +0100 Subject: [xmonad] [SOLVED] Re: Complex hotkeys definition In-Reply-To: References: <7bc6cbd9-0e64-aa94-b84f-2be85f593fbb@mito-space.com> Message-ID: <54031efa-a4e9-a278-41a4-665256969c5a@mito-space.com> -- Awesome! , ("M-2", spawn "something" *> windows (W.view "2")) did it! >> race condition: Thanks for the hint; maybe I can use that later. Anyway, in fact I don't want to spawn "konsole" but "xdotool" with a key combo (for some KDE5 action) – and so far it's working great! ^^ Am 17.01.22 um 21:10 schrieb Brandon Allbery: > You have two problems. The first is that `$` extends as far as > possible, so `spawn` ends up being grouped with `W.view` instead of > with `windows`; fix this by using explicit parentheses instead of `$`, > that is `windows (W.view "2")`. The second is that the correct > operator to use is either `*>` or `>>`. > > Although you will then discover a third problem, which is a race > condition because `spawn` is asynchronous (Linux is not Windows), > meaning sometimes the new window will open on the previously active > workspace. You may want to use > https://hackage.haskell.org/package/xmonad-contrib-0.17.0/docs/XMonad-Actions-SpawnOn.html#v:spawnOn > instead (don't forget to add > https://hackage.haskell.org/package/xmonad-contrib-0.17.0/docs/XMonad-Actions-SpawnOn.html#v:manageSpawn > to the `manageHook` or it won't work). > > On Mon, Jan 17, 2022 at 2:44 PM mito wrote: >> Dear all, >> >> yet I failed properly occasionally extending "myHotkeys" commands with >> additional arguments, e.g. like also spawning something when switching >> workspaces. >> >> Say, the default is something like: >> >> myHotkeys = [ >> ... >> , ("M-2", windows $ W.view "2") >> ... >> ] >> >> for hitting for changing to workspace "2". >> >> But what if I wanted to additionally execute some extra command or app – >> such as launching "konsole" (just for testing; I am going to do >> something else)? >> >> Simply editing and adding stuff link >> >> , ("M-2", windows $ W.view "2" $ spawn "konsole") >> or >> , ("M-2", windows $ W.view "2" . spawn "konsole") >> or >> , ("M-2", windows $ W.view "2" || spawn "konsole") >> or >> , ("M-2", windows $ W.view "2" <+> spawn "konsole") >> >> doesn't work, due to compilation errors. >> >> I am no programmer and haven't yet found the right operators or order; >> or am I missing brackets? >> And I don't get the error logs in detail really. >> >> Thanks in advance! >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > >