Logs: liberachat/#xmonad
| 2022-05-01 14:52:51 | <geekosaur> | abastro[m], as I said, not just nvidia |
| 2022-05-01 14:53:00 | <abastro[m]> | Is xmonad that good? |
| 2022-05-01 14:53:04 | → | c209e6dc-4d76-47 joins (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) |
| 2022-05-01 14:53:19 | <geekosaur> | that;s something of a personal question, I think :) |
| 2022-05-01 14:53:45 | <abastro[m]> | geekosaur: on "not just nvidia": Does that mean even Windows does not get it right? |
| 2022-05-01 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 |
| 2022-05-01 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 |
| 2022-05-01 14:54:45 | <geekosaur> | ^ which is X's fault |
| 2022-05-01 14:55:06 | <geekosaur> | X simply can't do this right becuase its core was designed in the 1980s when things worked differently |
| 2022-05-01 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 |
| 2022-05-01 14:56:33 | <Solid> | sounds like a perfect excuse to learn haskell :) |
| 2022-05-01 14:56:52 | <abastro[m]> | Wait, so you mean the drivers |
| 2022-05-01 14:56:57 | <Xioulious> | yeah, i need to start learning it now to make my hook work for my situation |
| 2022-05-01 14:57:41 | <abastro[m]> | geekosaur: Yea, sad that this kind of problem could only be fixed with money being put in |
| 2022-05-01 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 |
| 2022-05-01 14:59:11 | <abastro[m]> | Well I meant how Windows handles it better |
| 2022-05-01 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 |
| 2022-05-01 15:05:03 | <abastro[m]> | I see |
| 2022-05-01 15:05:28 | <abastro[m]> | In that case, xmonad would also eventually transfer to wayland I guess |
| 2022-05-01 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 |
| 2022-05-01 15:08:19 | <geekosaur> | X11 needs more than just money put in, it needs a complete redesign to make it more like Wayland |
| 2022-05-01 15:08:29 | <geekosaur> | wouldn't be so much X12 as Y1 |
| 2022-05-01 15:08:57 | <geekosaur> | but wayland is here now. it just needs to mature a bit (well, a lot) |
| 2022-05-01 15:09:08 | <Xioulious> | X11 is also very insecure, while wayland is way better at that part |
| 2022-05-01 15:09:28 | <geekosaur> | yes, its security model is as 1980s as the rest of it |
| 2022-05-01 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 |
| 2022-05-01 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 |
| 2022-05-01 15:11:50 | <Solid> | programs will also have to implement it n times, where n is the number of compositors they want to support |
| 2022-05-01 15:11:57 | <Solid> | sounds like a lot of fun |
| 2022-05-01 15:12:12 | <abastro[m]> | Xd |
| 2022-05-01 15:12:44 | <geekosaur> | that also is arguably part of the maturing, compositors need to agree on some standards |
| 2022-05-01 15:13:57 | <geekosaur> | sadly, given current linux politics that probably means everyone being railroaded into accepting weston as *the* standard |
| 2022-05-01 15:14:11 | <Solid> | GNOME and KDE agreeing on a standard? I'll bevlieve it when I see it |
| 2022-05-01 15:14:37 | <geekosaur> | they did, once |
| 2022-05-01 15:14:44 | <geekosaur> | that's where ewmh came from |
| 2022-05-01 15:15:06 | <Xioulious> | hope supporting nvidia with wayland will also become easier to do for them |
| 2022-05-01 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 |
| 2022-05-01 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 |
| 2022-05-01 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 |
| 2022-05-01 15:17:57 | <liskin> | Oh I see. Never tried it myself. |
| 2022-05-01 15:18:40 | <Xioulious> | i also had worse performance in games, but thats more so an xwayland problem i think |
| 2022-05-01 15:19:45 | <liskin> | Solid, mc47: have you guys already got a hotel reservation for ZuriHac, btw? |
| 2022-05-01 15:21:04 | <abastro[m]> | Did not know display standard would be as hard as entire OS |
| 2022-05-01 15:23:20 | <abastro[m]> | How can I "learn" wayland and its philosophy alike how I learn linux kernel |
| 2022-05-01 15:23:31 | <Solid> | liskin: yeah, all done already |
| 2022-05-01 15:28:02 | × | c209e6dc-4d76-47 quits (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) (Quit: Konversation terminated!) |
| 2022-05-01 15:32:54 | <liskin> | Hm, okay, perhaps I should as well then. How far from the venue are you? |
| 2022-05-01 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."" |
| 2022-05-01 15:33:49 | <Solid> | liskin: walking distance; like 800m or so if I remember correctly |
| 2022-05-01 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 |
| 2022-05-01 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 |
| 2022-05-01 15:36:39 | <abastro[m]> | geekosaur: Interesting, btw doesn't this mean Wayland WM should implement compositor? |
| 2022-05-01 15:37:01 | <abastro[m]> | geekosaur: (also is it okay to have multiple convos in an irc channel) |
| 2022-05-01 15:37:05 | <geekosaur> | no. consider that window management is a plugin in gnome |
| 2022-05-01 15:37:14 | <geekosaur> | it's okay, it just gets confusing at times |
| 2022-05-01 15:37:38 | <geekosaur> | window management is not about operation, it's about policy |
| 2022-05-01 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) |
| 2022-05-01 15:38:31 | <geekosaur> | you can actually operate an X server without a window manager, it just sucks a whole lot |
| 2022-05-01 15:39:08 | <abastro[m]> | Ohh |
| 2022-05-01 15:39:26 | <abastro[m]> | So xmonad is also about the policy, I guess |
| 2022-05-01 15:39:41 | <abastro[m]> | (Tho some might create DM out of xmonad) |
| 2022-05-01 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 |
| 2022-05-01 15:41:15 | <abastro[m]> | XD |
| 2022-05-01 15:41:45 | <abastro[m]> | In that case, why would it be quite hard to port xmonad on wayland? |
| 2022-05-01 15:41:56 | <abastro[m]> | If it is going to be a plugin |
| 2022-05-01 15:42:00 | <geekosaur> | I've done that while debugging xmonad crashes, for instance |
| 2022-05-01 15:42:27 | <geekosaur> | because xmonad's internals are really tightly tied to Xlib APIs |
| 2022-05-01 15:42:36 | <geekosaur> | we couldn't even move it to xcb sanely |
| 2022-05-01 15:43:12 | <abastro[m]> | Xlib APIs? |
| 2022-05-01 15:43:37 | <abastro[m]> | Oh right, wm plugins should at least be able to move stuffs around |
| 2022-05-01 15:43:51 | <abastro[m]> | Which means interfacing with the protocol |
| 2022-05-01 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. |
| 2022-05-01 15:44:47 | <liskin> | xmonad-contrib is another story though |
| 2022-05-01 15:44:55 | <geekosaur> | right |
| 2022-05-01 15:45:15 | <abastro[m]> | Xmonad-contrib, that sounds like manpower problem |
| 2022-05-01 15:45:40 | <abastro[m]> | Oh wait. So wayland does not yet gave good APIs for WM? |
| 2022-05-01 15:45:58 | <abastro[m]> | Wayland compositors does not yet provide APIs* |
| 2022-05-01 15:46:08 | <liskin> | The existing compositors happen to be WMs as well |
| 2022-05-01 15:46:23 | <abastro[m]> | Oh no |
| 2022-05-01 15:46:28 | <abastro[m]> | *Whi* |
| 2022-05-01 15:46:47 | <liskin> | So GNOME has its own, KDE its own, sway its own. |
| 2022-05-01 15:46:53 | <abastro[m]> | I guess ppl love such coupling.. |
| 2022-05-01 15:47:13 | <liskin> | Although that was the case with X11 as well, but you could mix and match. Now you can't. |
| 2022-05-01 15:47:59 | <liskin> | Coupling saves you development time. Less communication, less protocol design committees. |
| 2022-05-01 15:49:06 | <abastro[m]> | Yea.. |
| 2022-05-01 15:49:27 | <abastro[m]> | So that might be why xmonad could have less place |
| 2022-05-01 15:49:42 | <abastro[m]> | Was waymonad project trying to make a whole compositor, then? |
| 2022-05-01 15:49:53 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::aa1d) |
| 2022-05-01 15:50:56 | <abastro[m]> | (..wait I guess I myself also likes coupling, once I tried to put a status bar into xmonad executable) |
| 2022-05-01 15:54:57 | <abastro[m]> | geekosaur: Was waymonad an entire wayland compositor? |
| 2022-05-01 15:56:07 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-05-01 15:57:59 | <abastro[m]> | Hmm wayland protocol is.. asynchronous object-oriented protocol |
| 2022-05-01 15:58:04 | <abastro[m]> | Meh |
| 2022-05-01 16:00:19 | × | liskin[m] quits (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 2022-05-01 16:02:13 | → | Anexploringbot[m joins (~wybpipmat@2001:470:69fc:105::1:f452) |
| 2022-05-01 16:02:14 | ← | Anexploringbot[m parts (~wybpipmat@2001:470:69fc:105::1:f452) () |
| 2022-05-01 16:14:02 | × | cfricke quits (~cfricke@user/cfricke) (Ping timeout: 272 seconds) |
| 2022-05-01 16:44:53 | <liskin> | abastro[m]: Yes, waymonad is a whole compositor/window-manager in one process. |
| 2022-05-01 16:45:05 | → | liskin[m] joins (~liskinmat@2001:470:69fc:105::768) |
| 2022-05-01 16:45:26 | <liskin> | The compositor part is largely implemented using the wlroots library, so it's not an entirely separate implementation, though. |
All times are in UTC.