Logs on 2022-05-01 (liberachat/#xmonad)
| 00:42:59 | → | jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 00:48:13 | <jakeStateless-Fa> | @geekosaur that error just reoccurred, I haven't changed it to the hook version, and I'm away from my desktop now, but .xmonad/xmonad-errors doesn't have anything relevant and .xsession-errors is nonexistant on my system |
| 00:48:13 | <lambdabot> | Unknown command, try @list |
| 00:48:43 | <jakeStateless-Fa> | I am still not sure why it's erroring like that |
| 00:50:16 | <jakeStateless-Fa> | the hypothesis of it being layout related still remains, as I was able to open up apps and gridselect when I was there |
| 00:56:47 | <abastro[m]> | Perhaps you could try logging to separate file |
| 00:56:55 | <abastro[m]> | So that xmonad stuffs would be reported separately |
| 01:00:08 | → | abastro joins (~abab9579@220.75.216.63) |
| 01:02:13 | → | rekahsoft joins (~rekahsoft@cpe001b21a2fd89-cm64777ddc63a0.cpe.net.cable.rogers.com) |
| 01:05:29 | × | rekahsoft quits (~rekahsoft@cpe001b21a2fd89-cm64777ddc63a0.cpe.net.cable.rogers.com) (Remote host closed the connection) |
| 01:05:54 | → | rekahsoft joins (~rekahsoft@cpe001b21a2fd89-cm64777ddc63a0.cpe.net.cable.rogers.com) |
| 01:11:09 | → | c209e6dc-4d76-47 joins (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) |
| 01:12:36 | × | c209e6dc-4d76-47 quits (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) (Read error: Connection reset by peer) |
| 01:12:52 | → | c209e6dc-4d76-47 joins (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) |
| 01:33:50 | × | stackdroid18 quits (14094@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 01:56:07 | × | c209e6dc-4d76-47 quits (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) (Quit: Konversation terminated!) |
| 02:03:49 | × | banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 256 seconds) |
| 02:22:44 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 02:30:42 | × | rekahsoft quits (~rekahsoft@cpe001b21a2fd89-cm64777ddc63a0.cpe.net.cable.rogers.com) (Ping timeout: 272 seconds) |
| 02:31:57 | × | td_ quits (~td@muedsl-82-207-238-189.citykom.de) (Ping timeout: 276 seconds) |
| 02:32:25 | × | abastro quits (~abab9579@220.75.216.63) (Remote host closed the connection) |
| 02:33:29 | → | td_ joins (~td@94.134.91.80) |
| 03:00:19 | × | jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 03:02:00 | → | c209e6dc-4d76-47 joins (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) |
| 03:02:15 | → | jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 03:19:35 | × | c209e6dc-4d76-47 quits (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) (Quit: Konversation terminated!) |
| 03:27:02 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::aa1d) |
| 03:37:36 | × | steve__ quits (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 276 seconds) |
| 04:17:42 | × | jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 246 seconds) |
| 04:33:31 | → | steve__ joins (~steve@ool-182c2b80.dyn.optonline.net) |
| 05:07:22 | → | Ether17 joins (~Ether17@45.248.151.250) |
| 05:18:03 | × | Ether17 quits (~Ether17@45.248.151.250) (Quit: Client closed) |
| 05:54:09 | → | Ether17 joins (~Ether17@45.248.151.250) |
| 05:54:32 | × | Ether17 quits (~Ether17@45.248.151.250) (Client Quit) |
| 07:20:34 | → | gauge joins (~gauge@user/gauge) |
| 07:52:24 | × | mvk quits (~mvk@2607:fea8:5ce3:8500::aa1d) (Ping timeout: 248 seconds) |
| 09:00:11 | × | jmac123[m] quits (~jmac123ma@2001:470:69fc:105::1:eaf0) (Quit: You have been kicked for being idle) |
| 09:00:12 | × | robinhood0018[m] quits (~robinhood@2001:470:69fc:105::1:4dca) (Quit: You have been kicked for being idle) |
| 09:00:15 | × | ctx[m] quits (~ctxkungfu@2001:470:69fc:105::1:95dd) (Quit: You have been kicked for being idle) |
| 09:44:32 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 272 seconds) |
| 09:48:32 | × | Xioulious quits (~yourname@193.32.249.137) (Quit: leaving) |
| 09:54:07 | → | abastro joins (~abab9579@192.249.26.173) |
| 11:18:10 | × | abastro quits (~abab9579@192.249.26.173) (Remote host closed the connection) |
| 11:35:01 | × | td_ quits (~td@94.134.91.80) (Ping timeout: 256 seconds) |
| 11:36:31 | → | td_ joins (~td@94.134.91.69) |
| 11:46:48 | → | jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 13:12:24 | × | jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 248 seconds) |
| 13:33:16 | → | Xioulious joins (~yourname@193.32.249.137) |
| 13:36:14 | <Xioulious> | i've got a piece of code that makes it so with multiplescreens, when i move my mouse to a different screen that has an empty workspace, that screen/workspace gets focussed, this works as it should.. but then when i try to do the float and move with my mouse (the default modkey+buton1) and move the window to an other screen it often freaks out (starts jumping around) and sometimes goes invisible.. not |
| 13:36:20 | <Xioulious> | sure whats wrong with my code, could anyone take a look at it? |
| 13:36:36 | <Xioulious> | move a window* |
| 13:38:15 | <geekosaur> | you should probably pastebin the code so someone can look at it, rather than asking to ask |
| 13:38:19 | <geekosaur> | @where paste |
| 13:38:19 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 13:38:48 | <geekosaur> | I don't know how long I'll be around today, I'm waiting on my sister as usual for a Sunday |
| 13:41:50 | <Xioulious> | should i put my full xmonad.hs there or just the piece of code thats bugging out? guessing the xmonad.hs might be easier? |
| 13:41:54 | <geekosaur> | aaaand there she is |
| 13:42:04 | <geekosaur> | yes, seeing how it integrates in is often helpful |
| 13:42:17 | <Xioulious> | haha, enjoy your day with your sis! |
| 13:42:20 | <Xioulious> | ok, will do |
| 13:42:27 | <geekosaur> | \might want to use gist in that case. (many of us host our xmonad.hs-s on github or gitlab to make this easier) |
| 13:42:45 | <geekosaur> | well, I hae around an hour; she just texted me |
| 13:43:18 | <geekosaur> | *have |
| 13:43:27 | <Xioulious> | yeah i already got my xmonad.hs on my gitlab, though i do get some errors in my xsession-error file which could be helpfull |
| 13:46:42 | <Xioulious> | https://paste.tomsmeding.com/T6dIGYxa thats the stack.yaml and the error log, https://gitlab.com/Shadu/dotfiles/-/blob/main/.config/xmonad/xmonad.hs is the xmonad.hs |
| 13:48:26 | <Xioulious> | if i comment out the multiScreenFocusHook then it doesnt happen, but ofc then it wont focus on an empty workspace automatically |
| 13:49:16 | <geekosaur> | it never rains but it pours :) I wonder if this is the one we hit yesterday (BadValue on request 91/XLookupColor) |
| 13:50:23 | <Xioulious> | yeah, during normal use that error also pops up sometimes, but when i do that specific thing then it just floods it |
| 13:51:05 | <geekosaur> | and there's WindowNavigation, which might be the cause |
| 13:53:32 | <Xioulious> | hmm then i wonder about something, the person i got that script from didnt really encounter the problem, but i didnt take their layout setup.. let me check if they use windownavigation |
| 13:54:39 | <Xioulious> | nope, they aren't using it |
| 13:58:11 | <geekosaur> | that is likely to be the cause of the errors in the log, from our debugging over the past several hours of someone else's config |
| 13:58:51 | <geekosaur> | but I suspect your dragging problem is because you have both draggingVisualizer and multiScreenFocusHook and they're fighting each other |
| 13:58:59 | <Xioulious> | the freaking out still occurs even if i comment out the windownavigation import and the part in the layout |
| 14:00:30 | <Xioulious> | for some reason it seems to want to stretch the window downwards, atleast the size of the window changes when it does that |
| 14:02:27 | <Xioulious> | also seems to only do it when i drag a window to an empty workspace |
| 14:04:20 | <Xioulious> | got some better errors this time, but thats with a firefox crash: https://paste.tomsmeding.com/WOW4bhC2 |
| 14:11:24 | <geekosaur> | the getWindowAttributes errors are sadly normal. BadAlloc looks bad, though |
| 14:11:47 | <geekosaur> | what happens if you disable DraggingVisualizer? |
| 14:12:51 | <Xioulious> | still the same behavior |
| 14:13:15 | <geekosaur> | okay, so it's not a conflict there |
| 14:20:18 | <Xioulious> | if i do the same but with a thunar window, it also freaks out, but i dont get the badalloc error, so am thinking the badalloc is an error on firefox side? |
| 14:20:47 | <geekosaur> | except it's xmonad reporting it (note the start of the line) |
| 14:21:02 | <Xioulious> | it also doesnt add any errors to the xsession-error file in the case of thunar |
| 14:21:34 | <geekosaur> | ConfigureWindow |
| 14:21:41 | <Xioulious> | true, just thought that if there are some x11 errors that arent caused by xmonad but by a program running that xmonad would be reporting it or something |
| 14:22:07 | <geekosaur> | no, xmonad wouldn't receive those errors |
| 14:22:27 | <geekosaur> | ConfigureWindow error would match with your remark about the window resizing |
| 14:26:23 | <Xioulious> | could that have something to do with having 2 different resolutions? (monitor 1 being 1920x1200, monitor 2 being 1920x1080) |
| 14:26:57 | × | thunderrd quits (~thunderrd@183.182.110.239) (Remote host closed the connection) |
| 14:27:55 | <geekosaur> | yes. xmonad stores relative sizes (see RationalRect) and will resize (in your case, downward) when you move a window to a different monitor |
| 14:28:02 | → | thunderrd joins (~thunderrd@183.182.110.239) |
| 14:28:37 | <geekosaur> | I think your hook needs to verify that it is not inside a window at the time |
| 14:29:57 | <geekosaur> | it's not enough to check that there are no windows "on the screen" because the window you're moving won't be registered as on that screen until its origin is there |
| 14:30:15 | <geekosaur> | that is, its (0,0) |
| 14:30:22 | <geekosaur> | upper left corner |
| 14:30:34 | <geekosaur> | and may not be actually moved until the drag stops |
| 14:32:03 | <Xioulious> | so the hook for the focus thing should only activate when the cursor itself isnt over a window instead of checking if the screen has any windows |
| 14:32:49 | <geekosaur> | right, because "screen has any windows" will be incorrect mid-drag |
| 14:34:35 | <geekosaur> | queryPointer should inform you both of the pointer location and what window it's currently in |
| 14:35:04 | <Xioulious> | and then the hook will try to focus the workspace but then when i drag some more i throw the focus back to the window and it will constantly jump between those 2 and things freak out, sounds logical yeah, now to figure out how to implement it |
| 14:37:58 | → | cfricke joins (~cfricke@user/cfricke) |
| 14:38:28 | <geekosaur> | https://hackage.haskell.org/package/X11-1.10.2/docs/Graphics-X11-Xlib-Misc.html#v:queryPointer https://tronche.com/gui/x/xlib/window-information/XQueryPointer.html |
| 14:38:53 | <geekosaur> | the Haskell wrapper is pretty raw, it maps directly to the Xlib call |
| 14:39:16 | <geekosaur> | so you can just check if the returned window ID (not root window ID) is 0 |
| 14:40:26 | <abastro[m]> | Interesting how such direct translation is possible |
| 14:40:29 | <Xioulious> | okay, let me make a note of that, time to learn some haskell |
| 14:43:56 | <Xioulious> | also another bug that im having, though its with xmobar, is when I have my TV that is connected to my pc turned on but disabled through xrandr (or well, nvidia settings) and my 2 monitors go into standby, when i wake the monitors back up the xmobars are stretched across both screens |
| 14:44:52 | <geekosaur> | that would imply that xrandr information is wrong. I think we've seen that a few times with nvidia |
| 14:45:33 | <geekosaur> | sometimes affects xmonad as well, the xrandr information is inconsistent and different programs use different parts of it |
| 14:46:12 | <abastro[m]> | X & multiscreen? |
| 14:46:56 | <Xioulious> | so when that occurs i should check what xrandr is saying? i usually just do a recompile and restart of xmonad and that fixes it, but rather have it not occur ofc |
| 14:46:58 | <geekosaur> | multiscreen is a horrid hack, it's amazing that it works we well as it does |
| 14:47:53 | <abastro[m]> | I am glad I only have this laptop with single screen |
| 14:47:56 | <geekosaur> | X supports multiscreen natively but assumes every screen has its own framebuffer so windows can't be moved between them or etc., because that's how things worked in the 1980s |
| 14:48:37 | <Xioulious> | mhm, seems with nvidia it just makes 1 big screen and divides it up in 2 spaces |
| 14:49:38 | <abastro[m]> | Linux distros do not usually depend on X, right |
| 14:49:43 | <geekosaur> | that's how the multiscreen hack works,m yes. not just nvidia |
| 14:50:18 | <geekosaur> | it means different monitor resolutions don't work right, and various other shortcomings |
| 14:50:35 | <abastro[m]> | Nvidia? |
| 14:50:58 | <geekosaur> | alll the big linux distros still depend on X. we're expecting it to still be supported through 2030 because of contractual obligations on Red Hat's commercial offerings |
| 14:51:06 | <Xioulious> | that also causes the issues of different refreshrates, sadly wayland isnt ready yet for daily use for me, but xmonad feels way more comfy than i3 so far |
| 14:52:51 | <geekosaur> | abastro[m], as I said, not just nvidia |
| 14:53:00 | <abastro[m]> | Is xmonad that good? |
| 14:53:04 | → | c209e6dc-4d76-47 joins (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) |
| 14:53:19 | <geekosaur> | that;s something of a personal question, I think :) |
| 14:53:45 | <abastro[m]> | geekosaur: on "not just nvidia": Does that mean even Windows does not get it right? |
| 14:54:26 | <geekosaur> | Windows (and Wayland) use a different screen model. in particular Windows gets it more correct than any Linux environment including current Wayland |
| 14:54:28 | <Xioulious> | he meant that amd, intel and nvidia make 1 big screen for all your monitors and then divide spaces in that screen that each monitor/display gets assigned in X |
| 14:54:45 | <geekosaur> | ^ which is X's fault |
| 14:55:06 | <geekosaur> | X simply can't do this right becuase its core was designed in the 1980s when things worked differently |
| 14:55:55 | <Xioulious> | about xmonad, i like the way you configure it and what you can make it do, you can get pretty far with just grabbig stuff from other people's configs to get it to do what you want it to do, but when you want to adjust it a bit on your own it becomes hard unless you already know haskell |
| 14:56:33 | <Solid> | sounds like a perfect excuse to learn haskell :) |
| 14:56:52 | <abastro[m]> | Wait, so you mean the drivers |
| 14:56:57 | <Xioulious> | yeah, i need to start learning it now to make my hook work for my situation |
| 14:57:41 | <abastro[m]> | geekosaur: Yea, sad that this kind of problem could only be fixed with money being put in |
| 14:58:23 | <Xioulious> | even with money that would be a lot of money needed for anyone to dive that deep into the X code to adjust it, especially now that wayland is becoming bigger |
| 14:59:11 | <abastro[m]> | Well I meant how Windows handles it better |
| 15:00:40 | <Xioulious> | i dont think wayland will be that far behind windows in that aspect with time, as more distro's swap over to it more attention and improvements will go to it i hope |
| 15:05:03 | <abastro[m]> | I see |
| 15:05:28 | <abastro[m]> | In that case, xmonad would also eventually transfer to wayland I guess |
| 15:06:56 | <Xioulious> | when i read about that a bit ago somewhere it was mentioned that moving xmonad to wayland would require a big rewrite of stuff, also wouldnt be called xmonad (as the X in xmonad stands for X11) there was already some work done on a wayland version but it hasnt been updated in a bit if i remember right |
| 15:08:19 | <geekosaur> | X11 needs more than just money put in, it needs a complete redesign to make it more like Wayland |
| 15:08:29 | <geekosaur> | wouldn't be so much X12 as Y1 |
| 15:08:57 | <geekosaur> | but wayland is here now. it just needs to mature a bit (well, a lot) |
| 15:09:08 | <Xioulious> | X11 is also very insecure, while wayland is way better at that part |
| 15:09:28 | <geekosaur> | yes, its security model is as 1980s as the rest of it |
| 15:10:24 | <Solid> | i feel like most of the "security" features of wayland (like how something akin to xdotool could never work as well) are more of a theater show and actually very detrimental to user experience |
| 15:11:13 | <Xioulious> | currently, agreed, like screensharing, but programs are starting to implement things so that it works, thats part of the lots of maturing it still has to do |
| 15:11:50 | <Solid> | programs will also have to implement it n times, where n is the number of compositors they want to support |
| 15:11:57 | <Solid> | sounds like a lot of fun |
| 15:12:12 | <abastro[m]> | Xd |
| 15:12:44 | <geekosaur> | that also is arguably part of the maturing, compositors need to agree on some standards |
| 15:13:57 | <geekosaur> | sadly, given current linux politics that probably means everyone being railroaded into accepting weston as *the* standard |
| 15:14:11 | <Solid> | GNOME and KDE agreeing on a standard? I'll bevlieve it when I see it |
| 15:14:37 | <geekosaur> | they did, once |
| 15:14:44 | <geekosaur> | that's where ewmh came from |
| 15:15:06 | <Xioulious> | hope supporting nvidia with wayland will also become easier to do for them |
| 15:16:27 | <liskin> | Nvidia & Wayland should kinda just work with the latest drivers, I thought? Perhaps there are bugs but the missing apis are already there |
| 15:17:19 | <Xioulious> | you can run it, but yeah quite some bugs, mostly for me parts of certain windows flickering and believe i read somewhere that that was due to vsync related issues though could be remembering wrong |
| 15:17:44 | <Xioulious> | and figuring out what is exactly causing that problem becomes hard when you can only see one side of the code |
| 15:17:57 | <liskin> | Oh I see. Never tried it myself. |
| 15:18:40 | <Xioulious> | i also had worse performance in games, but thats more so an xwayland problem i think |
| 15:19:45 | <liskin> | Solid, mc47: have you guys already got a hotel reservation for ZuriHac, btw? |
| 15:21:04 | <abastro[m]> | Did not know display standard would be as hard as entire OS |
| 15:23:20 | <abastro[m]> | How can I "learn" wayland and its philosophy alike how I learn linux kernel |
| 15:23:31 | <Solid> | liskin: yeah, all done already |
| 15:28:02 | × | c209e6dc-4d76-47 quits (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) (Quit: Konversation terminated!) |
| 15:32:54 | <liskin> | Hm, okay, perhaps I should as well then. How far from the venue are you? |
| 15:32:55 | <abastro[m]> | ""A display server using the Wayland protocol is called a Wayland compositor, because it additionally performs the task of a compositing window manager."" |
| 15:33:49 | <Solid> | liskin: walking distance; like 800m or so if I remember correctly |
| 15:34:25 | <geekosaur> | right, while X11 is built around the window manager and a compositor is an add-on, wayland is built around the compositor and makes window management the not-quite-add-on |
| 15:34:56 | <geekosaur> | this actually makes sense functionally; compositing is yet another hack in the X11 world, but it *really* ought to be part of the display server |
| 15:36:39 | <abastro[m]> | geekosaur: Interesting, btw doesn't this mean Wayland WM should implement compositor? |
| 15:37:01 | <abastro[m]> | geekosaur: (also is it okay to have multiple convos in an irc channel) |
| 15:37:05 | <geekosaur> | no. consider that window management is a plugin in gnome |
| 15:37:14 | <geekosaur> | it's okay, it just gets confusing at times |
| 15:37:38 | <geekosaur> | window management is not about operation, it's about policy |
| 15:38:10 | <geekosaur> | so having it as a plugin is reasonable (and in fact it is in some sense a plugin in the X11 world as well) |
| 15:38:31 | <geekosaur> | you can actually operate an X server without a window manager, it just sucks a whole lot |
| 15:39:08 | <abastro[m]> | Ohh |
| 15:39:26 | <abastro[m]> | So xmonad is also about the policy, I guess |
| 15:39:41 | <abastro[m]> | (Tho some might create DM out of xmonad) |
| 15:39:48 | <geekosaur> | all you need is an open terminal and you run everything from that and manually provide -geometry parameters to place the windows |
| 15:41:15 | <abastro[m]> | XD |
| 15:41:45 | <abastro[m]> | In that case, why would it be quite hard to port xmonad on wayland? |
| 15:41:56 | <abastro[m]> | If it is going to be a plugin |
| 15:42:00 | <geekosaur> | I've done that while debugging xmonad crashes, for instance |
| 15:42:27 | <geekosaur> | because xmonad's internals are really tightly tied to Xlib APIs |
| 15:42:36 | <geekosaur> | we couldn't even move it to xcb sanely |
| 15:43:12 | <abastro[m]> | Xlib APIs? |
| 15:43:37 | <abastro[m]> | Oh right, wm plugins should at least be able to move stuffs around |
| 15:43:51 | <abastro[m]> | Which means interfacing with the protocol |
| 15:44:36 | <liskin> | If we had a well-maintained compositor with an API for window-manager plugins, porting the core parts of xmonad wouldn't be hard. |
| 15:44:47 | <liskin> | xmonad-contrib is another story though |
| 15:44:55 | <geekosaur> | right |
| 15:45:15 | <abastro[m]> | Xmonad-contrib, that sounds like manpower problem |
| 15:45:40 | <abastro[m]> | Oh wait. So wayland does not yet gave good APIs for WM? |
| 15:45:58 | <abastro[m]> | Wayland compositors does not yet provide APIs* |
| 15:46:08 | <liskin> | The existing compositors happen to be WMs as well |
| 15:46:23 | <abastro[m]> | Oh no |
| 15:46:28 | <abastro[m]> | *Whi* |
| 15:46:47 | <liskin> | So GNOME has its own, KDE its own, sway its own. |
| 15:46:53 | <abastro[m]> | I guess ppl love such coupling.. |
| 15:47:13 | <liskin> | Although that was the case with X11 as well, but you could mix and match. Now you can't. |
| 15:47:59 | <liskin> | Coupling saves you development time. Less communication, less protocol design committees. |
| 15:49:06 | <abastro[m]> | Yea.. |
| 15:49:27 | <abastro[m]> | So that might be why xmonad could have less place |
| 15:49:42 | <abastro[m]> | Was waymonad project trying to make a whole compositor, then? |
| 15:49:53 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::aa1d) |
| 15:50:56 | <abastro[m]> | (..wait I guess I myself also likes coupling, once I tried to put a status bar into xmonad executable) |
| 15:54:57 | <abastro[m]> | geekosaur: Was waymonad an entire wayland compositor? |
| 15:56:07 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 15:57:59 | <abastro[m]> | Hmm wayland protocol is.. asynchronous object-oriented protocol |
| 15:58:04 | <abastro[m]> | Meh |
| 16:00:19 | × | liskin[m] quits (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 16:02:13 | → | Anexploringbot[m joins (~wybpipmat@2001:470:69fc:105::1:f452) |
| 16:02:14 | ← | Anexploringbot[m parts (~wybpipmat@2001:470:69fc:105::1:f452) () |
| 16:14:02 | × | cfricke quits (~cfricke@user/cfricke) (Ping timeout: 272 seconds) |
| 16:44:53 | <liskin> | abastro[m]: Yes, waymonad is a whole compositor/window-manager in one process. |
| 16:45:05 | → | liskin[m] joins (~liskinmat@2001:470:69fc:105::768) |
| 16:45:26 | <liskin> | The compositor part is largely implemented using the wlroots library, so it's not an entirely separate implementation, though. |
| 16:46:19 | <liskin> | But my knowledge ends about here, unfortunately. |
| 17:44:05 | <yuu[m]> | <abastro[m]> "Meh..." <- why? |
| 18:02:01 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 18:36:45 | <Xioulious> | according to https://github.com/xmonad/xmonad/issues/104 i shouldn't need a function to focus an empty workspace when i move my cursor there, or is this somehow reverted? as i added a function to get that functionality |
| 18:51:54 | → | benin joins (~benin@183.82.204.110) |
| 19:16:19 | → | jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 19:25:56 | × | steve__ quits (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 272 seconds) |
| 19:29:45 | × | benin quits (~benin@183.82.204.110) (Quit: The Lounge - https://thelounge.chat) |
| 20:14:35 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.4.1) |
| 20:48:25 | → | stackdroid18 joins (14094@user/stackdroid) |
| 21:56:15 | <geekosaur> | Xioulious, do you know that you needed to add a function? Often things are cargo-culted and copied around for years when they're not needed any more. |
| 22:09:36 | <Xioulious> | without that focus function that you looked at the workspace focus switching on an empty workspace isnt working, could ofcourse be something wrong with my config |
| 22:16:20 | <Xioulious> | i should grab some default config from somewhere that has multiscreen with independent screens worked into it to test if its my config |
| 22:41:36 | <abastro[m]> | liskin: so ever to continue waymonad, wlroots need to be studied.. :P |
| 22:41:57 | <liskin> | abastro[m]: yes |
| 22:42:40 | <liskin> | there's a #waymonad channel on matrix if you want to talk with the people currently in charge of the lastly active fork of waymonad |
| 22:43:04 | <liskin> | last time I spoke with Las, he said something about having plans to refactor the wlroots bindings some time in summer or something |
| 22:43:19 | <liskin> | unfortunately we have very different views on where the project should go :-/ |
| 22:46:16 | <liskin> | (I think *monad should stay minimal and plug into a separate compositor, probably written in C or Rust and maintained separately, and he thinks it's a good idea to do it all in Haskell and run as a single process; both approaches are valid and have slightly different outcomes in terms of what features are possible and what performance/stability you get out of it) |
| 23:24:23 | <abastro[m]> | Yea I myself would also like separate compositor approach |
| 23:25:00 | <abastro[m]> | Tho, would one bother with C to write those... |
| 23:25:41 | <abastro[m]> | (You don't mean *monad going C, right?) |
| 23:26:48 | <liskin> | Well the idea was that someone else should write the C compositor anyway :-) |
| 23:27:41 | <liskin> | Ideally that would involve standardising a wayland protocol for speaking to a window manager, and *monad would then just implement that. |
| 23:29:39 | <liskin> | I'm not entirely sure how the wayland security model works. Presumably the compositor can decide that certain clients are higher privilege than others and speak a wider range of protocols with them to allow them to control stuff like window placement or xdotool-ish things. |
| 23:30:14 | <liskin> | (I read Drew DeVault's Wayland book in summer but it's more of a draft than an actual book.) |
| 23:38:33 | → | Xdoct0r joins (~Xdoct0r@131.72.69.18) |
| 23:39:14 | × | Xdoct0r quits (~Xdoct0r@131.72.69.18) (Client Quit) |
| 23:41:30 | <abastro[m]> | Yea, I see |
| 23:41:50 | <abastro[m]> | Sad that standard might not even care about Window Managers |
| 23:42:34 | <abastro[m]> | Since wayland is OOP anyway, C++ could be good fit for it I guess |
All times are in UTC on 2022-05-01.