Home freenode/#xmonad: Logs Calendar

Logs: freenode/#xmonad

←Prev  Next→
Page 1 .. 56 57 58 59 60 61 62 63 64 65 66 .. 397
— 39,606 events total
2020-12-27 08:12:46 × growpotkin quits (~growpotki@130-45-30-154.dyn.grandenetworks.net) (Quit: ZNC 1.8.2 - https://znc.in)
2020-12-27 08:17:28 → growpotkin joins (~growpotki@130-45-30-154.dyn.grandenetworks.net)
2020-12-27 08:44:55 × growpotkin quits (~growpotki@130-45-30-154.dyn.grandenetworks.net) (Quit: ZNC 1.8.2 - https://znc.in)
2020-12-27 08:47:57 → growpotkin joins (~growpotki@130-45-30-154.dyn.grandenetworks.net)
2020-12-27 08:51:27 <Solid> ?tell tux1 it doesn't assume any kind of height, it gets the height from _NET_WM_STRUT_PARTIAL or _NET_WM_STRUT, which xmobar sets correctly if you change its height
2020-12-27 08:51:27 <lambdabot> Consider it noted.
2020-12-27 08:55:43 → notis joins (~notis@85.203.44.37)
2020-12-27 08:57:33 × growpotkin quits (~growpotki@130-45-30-154.dyn.grandenetworks.net) (Quit: ZNC 1.8.2 - https://znc.in)
2020-12-27 09:00:02 → growpotkin joins (~growpotki@130-45-30-154.dyn.grandenetworks.net)
2020-12-27 09:15:00 <al3x27> when I load mu xmonad.hs in ghci, it cannot find my own modules(?), but when compiling it does, how to "set" the loadpath for ghci?
2020-12-27 09:16:39 <al3x27> rtfm is ok, just /what/ fm?
2020-12-27 09:20:26 <al3x27> nm, google decided to answer correctly his time
2020-12-27 09:59:30 × gzj quits (~gzj@unaffiliated/gzj) (Ping timeout: 256 seconds)
2020-12-27 10:07:54 × growpotkin quits (~growpotki@130-45-30-154.dyn.grandenetworks.net) (Quit: ZNC 1.8.2 - https://znc.in)
2020-12-27 10:24:45 → gzj joins (~gzj@unaffiliated/gzj)
2020-12-27 10:38:38 × mrbirkov quits (uid453780@gateway/web/irccloud.com/x-xzsphatjpbhjifjh) (Quit: Connection closed for inactivity)
2020-12-27 11:04:35 → ADG1089__ joins (~aditya@223.235.213.117)
2020-12-27 11:05:54 <ADG1089__> I am trying to run alacritty as a named scratchpad in xmonad using `alacritty -n scratchpad`
2020-12-27 11:06:00 <ADG1089__> did they remove the -n flag?
2020-12-27 11:06:49 <ADG1089__> works with --title
2020-12-27 11:13:05 × gzj quits (~gzj@unaffiliated/gzj) (Remote host closed the connection)
2020-12-27 11:13:25 → gzj joins (~gzj@unaffiliated/gzj)
2020-12-27 11:21:09 × hexo quits (~hexo@gateway/tor-sasl/hexo) (Remote host closed the connection)
2020-12-27 11:21:26 → hexo joins (~hexo@gateway/tor-sasl/hexo)
2020-12-27 11:22:25 × ADG1089__ quits (~aditya@223.235.213.117) (Remote host closed the connection)
2020-12-27 11:43:07 × gzj quits (~gzj@unaffiliated/gzj) (Remote host closed the connection)
2020-12-27 11:43:27 → gzj joins (~gzj@unaffiliated/gzj)
2020-12-27 12:03:15 <al3x27> it's brilliant that it's possible to load xmonad.hs in ghci!
2020-12-27 12:09:01 × gzj quits (~gzj@unaffiliated/gzj) (Remote host closed the connection)
2020-12-27 12:09:20 → gzj joins (~gzj@unaffiliated/gzj)
2020-12-27 12:11:07 × gzj quits (~gzj@unaffiliated/gzj) (Remote host closed the connection)
2020-12-27 12:11:26 → gzj joins (~gzj@unaffiliated/gzj)
2020-12-27 12:23:08 <Solid> ?tell ADG1089__ alacritty also has a --class flag, in case you want to set that instead
2020-12-27 12:23:09 <lambdabot> Consider it noted.
2020-12-27 12:40:21 → mc47 joins (~yecinem@141.84.69.87)
2020-12-27 12:48:07 × gzj quits (~gzj@unaffiliated/gzj) (Remote host closed the connection)
2020-12-27 12:48:27 → gzj joins (~gzj@unaffiliated/gzj)
2020-12-27 13:29:07 × gzj quits (~gzj@unaffiliated/gzj) (Read error: Connection reset by peer)
2020-12-27 13:29:27 → gzj joins (~gzj@unaffiliated/gzj)
2020-12-27 13:31:19 → vrs joins (~vrs@unaffiliated/vrs)
2020-12-27 13:35:45 × gzj quits (~gzj@unaffiliated/gzj) (Ping timeout: 240 seconds)
2020-12-27 13:45:17 → ElKowar joins (~Srain@p3e9d26c7.dip0.t-ipconnect.de)
2020-12-27 13:46:29 <ElKowar> Is there already some way to improve how the cursor jumps across screen borders? I have multiple monitors with different resolutions, and I'd love to somehow make the cursor movement be less weird when moving across monitors
2020-12-27 13:47:23 <ElKowar> mainly I'd love to make it always able to jump, even if there technically isn't a screen (as in, if my bottom monitor is wider than the top one, and i want to move from the bottom to the top one while the mouse is that the outer edges of the bottom screen, it won't be able to move up, as there technically isn't a screen above that part ofthe monitor
2020-12-27 13:48:08 <ElKowar> i know about the screen corner thing that can execute code when cursor hits the corners of the screen. if there isn't anything already existing then I'll do it myself, just wanted to check first
2020-12-27 13:51:55 × rabliatu quits (~quassel@143.202.160.84) (Quit: 1)
2020-12-27 14:11:48 <Liskni_si> dunno but I remember I did something similar back when the max framebuffer size was 2048x2048 so you couldn't have two 1280x1024 monitors horizontally, maybe you'll be able to reuse something: https://github.com/liskin/xmousewarp
2020-12-27 14:12:05 <ElKowar> Will look at that, thanks!
2020-12-27 14:12:30 <Liskni_si> 14 f*ing years, omg, I feel old :-/
2020-12-27 14:13:46 <ElKowar> also currently looking at https://github.com/xmonad/xmonad-contrib/issues/369 (No WM_CLASS for window decorations). Do you think it'd be a good idea to just Add a WM_CLASS of "XMonad-Window" or something to everything that's created by XMonad.Util.XUtils.createNewWindow? Then maybe add a createNewWindowWithClass function or something for window-decors and whatever to set their own if they want to be more specific
2020-12-27 14:14:10 <ElKowar> seems like it would only help in rather rare cases, but I'd also not see any reason _not_ do to it
2020-12-27 14:14:18 <ElKowar> lol 14 years ago i was 6
2020-12-27 14:14:20 <ElKowar> ._.
2020-12-27 14:16:32 <Liskni_si> :-)
2020-12-27 14:16:51 <Liskni_si> I was freshman at uni
2020-12-27 14:17:45 × hexo quits (~hexo@gateway/tor-sasl/hexo) (Quit: ZNC 1.8.2 - https://znc.in)
2020-12-27 14:18:10 → hexo joins (~hexo@gateway/tor-sasl/hexo)
2020-12-27 14:21:12 <Liskni_si> re #369, I think it's reasonable to mark these decorations as such in some way
2020-12-27 14:21:35 <Liskni_si> I'd hope there's something more standard than using a custom WM_CLASS tho :-)
2020-12-27 14:22:21 <ElKowar> Not really, the main point of a WM_CLASS _is_ to have applications have a unique identifier that describes what a window is, so using that here is - at least as far as my understanding of X Idioms goes - the thing to do
2020-12-27 14:23:04 <Liskni_si> well what about https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm45760170798096
2020-12-27 14:24:06 <Liskni_si> none of those seem to fit :-/
2020-12-27 14:25:09 <Liskni_si> I'd recommend looking through picom sources to find what conditions it uses to detect "special" windows and see if some of that is close enough to our usecase
2020-12-27 14:26:10 <ElKowar> in Picom the main thing you do is manually configure the excludes by way of WM_CLASS, window name, etc - pretty sure picom doesn't do any detection by itself
2020-12-27 14:26:44 <ElKowar> regardless of the usecase of specifically excluding stuff in picom, setting a WM_CLASS is definitely something we should do
2020-12-27 14:27:30 <Liskni_si> man/compton.1.asciidoc
2020-12-27 14:27:32 <Liskni_si> 50: Enabled client-side shadows on windows. Note desktop windows (windows with '_NET_WM_WINDOW_TYPE_DESKTOP') never get shadow, unless explicitly requested using the wintypes option.
2020-12-27 14:27:45 <Liskni_si> it definitely does look at the window type ^
2020-12-27 14:28:09 <ElKowar> uhh, interesting, didn't know that!
2020-12-27 14:29:22 <ElKowar> uhh that's actually being used already:
2020-12-27 14:29:33 <ElKowar> -- @@@ ugly hack to prevent compositing
2020-12-27 14:29:33 <ElKowar> whenX (return $ isJust m) $ flip catchX (return ()) $ do
2020-12-27 14:29:33 <ElKowar> wINDOW_TYPE <- getAtom "_NET_WM_WINDOW_TYPE"
2020-12-27 14:29:33 <ElKowar> dESKTOP <- getAtom "_NET_WM_WINDOW_TYPE_DESKTOP"
2020-12-27 14:29:33 <ElKowar> io $ changeProperty32 d win wINDOW_TYPE aTOM propModeReplace [fi dESKTOP]
2020-12-27 14:31:00 <ElKowar> so i guess, given that issue, picom only looks at that for _some_ things like shadows, but not for rounded corners?
2020-12-27 14:32:46 <Liskni_si> https://github.com/yshui/picom/blob/bb54da0039ff3c833fbef83bf465847e3a909310/src/config.c#L458
2020-12-27 14:33:09 <Liskni_si> only mentions shadow, so yeah, probably that's the problem
2020-12-27 14:34:01 <Liskni_si> I think GNOME (without xmonad, without picom) actually has rounded corners on its desktop background, so presumably that's something people want …
2020-12-27 14:40:30 <ElKowar> weird,...
2020-12-27 14:42:24 <ElKowar> So my current implementation just adds a new createNewWindowWithClass function to XMonad.Util.XUtils, and makes createNewWindow set a WM_CLASS of "XMonad Window" as the default. Then I'm using that in the Window decoration module to set the WM_CLASS of the decrations to "XMonad decoration". does that sound good? (I'll quickly check if there's any more specific stuff on best-practices for naming of WM_CLASSes etc
2020-12-27 14:49:09 <Liskni_si> I'd prefer if you checked with the picom folks whether there's a generic way to mark these windows
2020-12-27 14:49:20 <Liskni_si> does it round xmobar's corners as well?
2020-12-27 14:53:07 <ElKowar> I'll definitely check! Main point is that X11 definitely "wants" any application to provide the WM_CLASS property, so regardless of that specific rounded-corners issue, we should set the WM_CLASS (see https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS)
2020-12-27 14:55:10 <Liskni_si> if that's the case, do we need a createNewWindow _without_ having to specify a class? :-)
2020-12-27 14:55:53 <Liskni_si> anyway I think you might want to discuss this with geekosaur, I don't have these X11 things ready in working memory :-/
2020-12-27 14:56:43 <ElKowar> I'll check how much changes would be necessary to change the signature of createNewWindow :P
2020-12-27 15:00:33 → geekosaur joins (ae68c070@cpe-174-104-192-112.neo.res.rr.com)
2020-12-27 15:01:01 <ElKowar> wait why/how does DragPane use an actual Window :o I thought it was just a different TwoPane, or am i mixing that up with somethign
2020-12-27 15:03:06 <ElKowar> So the only modules that make use of XMonad.Util.XUtils.createNewWindow seem to be Layout.DragPane, Actions.ShowText, Layout.BinarySpacePartitioning (for borders? kinda confused on the implementation there), and Layout.Decoration. Requiring a WM_CLASS to be provided seems like the sensible choice
2020-12-27 15:03:43 <Liskni_si> dragpane needs a window to capture the mouse clicks for resizing
2020-12-27 15:03:52 <Liskni_si> MouseResizableTile does that as well I think
2020-12-27 15:04:01 <Liskni_si> (possibly reusing the code from DragPane or something)
2020-12-27 15:04:18 <Liskni_si> no idea why BSP does it
2020-12-27 15:04:53 <ElKowar> MouseResizableTile just creates a window using Graphics.X11.XLib.Window directly
2020-12-27 15:06:30 <Liskni_si> oh
2020-12-27 15:09:59 <ElKowar> So the X11 spec expects there to be two WM_CLASS values, one that specifies the concrete "instance" inside of the application that the window belongs to (i'd say that should be used for specifying "Decoration" vs "Popup" etc) and one for the application (should in our case just always be "XMonad"). technically, that first part is supposed to be dependant on how the user starts the application, i.e. giving an explicit instance name (i.e. w
2020-12-27 15:09:59 <ElKowar> hen starting a terminal with --name "something", etc,...) - which doesn't really apply in our case
2020-12-27 15:10:00 <geekosaur> WM_CLASS should be [Xmonad,xmonad], and WM_WINDOW_ROLE should be used for things like indicating decorations
2020-12-27 15:10:12 <geekosaur> or XMonad, yeh
←Prev  Next→
Page 1 .. 56 57 58 59 60 61 62 63 64 65 66 .. 397

All times are in UTC.