01:38 <szgy> one neat thing that I haven't seem people experimenting with in janet is that you can save an image (like with Smalltalk or CommonLisp) that you can load with a specific environment

04:23 <Nosrep> > I'll be very happy when I finally see all of those hacky scripts that just crop a normal screenshot die

04:23 <Nosrep> why the hate

12:16 <leon-p> because I prefer proper solutions to hacks 🤷

13:50 <ifreund> got janet-wayland integrated into janet's event loop

13:51 <ifreund> now running the equivalent of wl_display_dispatch() from janet no longer uses blocking IO, and one can connect a REPL to the running wayland client

13:52 <leon-p> neat!

13:53 <ifreund> its all single threaded too, which is pretty cool

13:54 <fleischie> river 0.14 rewritten in janet you said? oO

13:55 <ifreund> river will always be in a low level language because I care about latency

13:55 <ifreund> now, my window manager is probably going to be in janet

13:56 <ifreund> being able to do the high level window management logic in a high level language is one of the major motivations for the window management protocol work

16:05 <orangebot> Anyone know the right spot to configure default fonts?

16:06 <leon-p> orangebot: ~/.config/fontconfig/fonts.conf

16:06 <leon-p> you can aliases, f.e. alias "monospace" to your preferred monospace font

16:07 <leon-p> here is an example: https://git.sr.ht/~leon_plickat/river-config/blob/master/fontconfig/fonts.conf

16:07 <orangebot> Didn't realize that fontconfig was still used by Wayland stuff.

16:08 <orangebot> leon-p: thanks for the help

16:09 <vyivel> wdym still

16:10 <vyivel> what else would it use

16:12 <orangebot> ¯\_(ツ)_/¯ Seems like Wayland desktops/WMs need to impliment a lot on it's own where X11 settings were (somewhat) consolidated. Figured fonts were were simmilarly handled by the desktop/WM.

16:13 <vyivel> fonts are competely unrelated to display server

16:14 <vyivel> completely*

16:14 <orangebot> I've never implimented either, so I would not know

16:19 <ifreund> vyivel: not on X11 :P

16:20 <vyivel> i dont think anything uses xft or whatever it was called anymore

16:41 <Nosrep> proper solution as in what like only screenshotting what needs to be screenshotted in the first place?

16:42 <Nosrep> my screenshot script is very cool because in cropping a normal screenshot it effectively freezes the screen at moment of screenshot

16:56 <leon-p> Nosrep: all script solutions fail for cases such as the window being occluded by other windows or not visible at all. that is unavoidable

16:57 <leon-p> the new screen-copy stuff allows getting a screenshot of a windows entire rendered image, regardless of whether and how it is currently displayed

17:04 <ifreund> also single window screen sharing

18:06 <donio> just saw river-window-management-v1.xml in the rwm branch, is it the intention to allow a "window manager client" to have full control over window and keyboard event management?

18:07 <donio> i wonder if this might be a possible path for an exwm-workalike for wayland. exwm is an emacs-based X11 WM

18:37 <FireFly> hm interesting, after updating to river 0.3.10 (I'm guessing due to the wlroots bump) it seems the scale I set for my display with wlr-randr in my init script gets reset when switching to a tty and back

18:38 <leon-p> donio: something like exwm should be possible. The protocol allows full control over window placement, window sizes (with the caveat that the client drawing the window always has the final say in the window size), custom window decoration, window visibility, etc.. You don't have access to raw keyboard events, but you can register keybinds

18:39 <leon-p> FireFly: I wonder if the tty switching causes the output to disappear and re-appear. In that case, from river's PoV it would be like you unplugging and re-plugging your screen, so output settings don't carry over

18:39 <leon-p> try using kanshi

18:40 <FireFly> hm, yeah I should maybe give that a try

18:40 <FireFly> mainly interesting that it seems to have changed with the version bump from what I could tell

18:47 <donio> leon-p: can you send synthetic keyboard events?

18:47 <leon-p> with other protocols kinda

18:48 <leon-p> not really keyboard events, but sending text is possible

18:49 <leon-p> although sending faked keyboard events is arguably Not Good™ and software should just have a proper scripting interface

18:51 <leon-p> if you only care about inputting text though, then either the text-input protocol or one of the various input method protocols may work quite well

20:21 <Nosrep> > the new screen-copy stuff allows getting a screenshot of a windows entire rendered image, regardless of whether and how it is currently displayed

20:21 <Nosrep> i see

20:22 <Nosrep> i think it's been so long since i've had an actual screenshot app i forgot you could do a whole window

21:46 <ifreund> FireFly: yeah, tty switching is handled differently by wlroots 0.19

21:46 <ifreund> kanshi should solve your issue

21:47 <ifreund> leon-p: iirc one of exwm's things is making everything use emacs key bindings, which they do with synthetic key events for things like Firefox that aren't configurable enough

21:48 <ifreund> donio: I think one should be able to achieve that with the rwm protocol in combination with the wlr-virtual-keyboard protocol

21:49 <ifreund> if that doesn't already work I'd be happy to tweak things to make that use case possible

21:53 <ifreund> Nosrep: you can also get screenshots that preserve window transparency for example, which wasnt possible before

21:53 <ifreund> this is nice for e.g. drop shadows