path: root/2022/captions/emacsconf-2022-wayland--emacs-should-become-a-wayland-compositor--michael-bauer--answers.vtt

WEBVTT

00:00:00.000 --> 00:00:03.600
 going to start recording. All right. Thanks, Michael, for

00:00:03.600 --> 00:00:05.040
 the great talk. So

00:00:05.040 --> 00:00:09.070
 the Q&A is live now. Folks can ask questions on IRC or the

00:00:09.070 --> 00:00:10.440
 pad. And then

00:00:10.440 --> 00:00:12.660
 at some later point, we'll also open up this PDB room

00:00:12.660 --> 00:00:13.860
 itself for people to join

00:00:13.860 --> 00:00:16.310
 and ask their questions here if they want. Michael, take it

00:00:16.310 --> 00:00:16.720
 away.

00:00:16.720 --> 00:00:21.470
 Okay, I will start with the first question of etherpad is

00:00:21.470 --> 00:00:22.600
 are you using

00:00:22.600 --> 00:00:28.920
 this as it as a replacement of x ex WM? No, not yet. But I

00:00:28.920 --> 00:00:33.040
'm planning to. I'm a

00:00:33.040 --> 00:00:39.700
 I use x WM since many years like for my main computing

00:00:39.700 --> 00:00:42.400
 environment with Emacs.

00:00:42.400 --> 00:00:47.530
 And I would love to have a replacement and Wayland. I'm not

00:00:47.530 --> 00:00:49.120
 actually that sure

00:00:49.120 --> 00:00:54.390
 if that needed. But I plan on using it. It's not finished.

00:00:54.390 --> 00:00:55.760
 So is this testable?

00:00:55.760 --> 00:01:04.660
 Yes, it is testable. I have gonna provide you the code. At

00:01:04.660 --> 00:01:05.960
 the end of the

00:01:05.960 --> 00:01:10.180
 video, there was a link to my site, but there's no site yet

00:01:10.180 --> 00:01:12.160
. I bought this URL a

00:01:12.160 --> 00:01:16.520
 year ago, and that's a good reason to put something on

00:01:16.520 --> 00:01:18.040
 there. So wait a few

00:01:18.040 --> 00:01:22.250
 days and you can download a git repository. At least that's

00:01:22.250 --> 00:01:23.640
 the plan. And

00:01:23.640 --> 00:01:26.710
 then you can test it. Input handling is still missing, as I

00:01:26.710 --> 00:01:30.560
 said. Yes, that makes

00:01:30.560 --> 00:01:36.390
 it a bit rough. So the input is only guided by where the

00:01:36.390 --> 00:01:39.560
 mouse pointer is. And

00:01:39.560 --> 00:01:43.770
 it's missing in the C part in the C server part. But if

00:01:43.770 --> 00:01:45.160
 this is in there, I

00:01:45.160 --> 00:01:49.450
 think you can use it as a replacement. So it's testable,

00:01:49.450 --> 00:01:50.240
 and it's not a

00:01:50.240 --> 00:01:54.140
 replacement yet. Have you considered contributing to Emacs

00:01:54.140 --> 00:01:55.080
 cores? The next

00:01:55.080 --> 00:02:00.590
 question? Yes. Is it a general question? If I would like to

00:02:00.590 --> 00:02:03.680
 do that? Yeah, I got

00:02:03.680 --> 00:02:07.560
 quite a lot into Emacs core in the last year because I did

00:02:07.560 --> 00:02:08.800
 language work with

00:02:08.800 --> 00:02:13.030
 Lisp and really nerded out and got to know the core. So I

00:02:13.030 --> 00:02:15.360
 like it. Why not? If

00:02:15.360 --> 00:02:18.980
 it's a more specific question, if I would like to

00:02:18.980 --> 00:02:20.840
 contribute the Wayland

00:02:20.840 --> 00:02:24.810
 support to Emacs core, then I'm not that sure if it belongs

00:02:24.810 --> 00:02:27.160
 there. Like at first,

00:02:27.160 --> 00:02:29.660
 I thought, of course, you have to put it in the core. It's

00:02:29.660 --> 00:02:30.520
 C. It has to work

00:02:30.520 --> 00:02:35.120
 together. But after I looked into it a little bit more, how

00:02:35.120 --> 00:02:36.280
 to do a Wayland

00:02:36.280 --> 00:02:39.270
 compositor with Emacs, I found out, okay, there's this Way

00:02:39.270 --> 00:02:40.280
land protocol and

00:02:40.280 --> 00:02:43.970
 all the programs that are working together in a Wayland

00:02:43.970 --> 00:02:45.560
 desktop, they talk

00:02:45.560 --> 00:02:51.150
 in this protocol. And when I got Emacs to talk with the Way

00:02:51.150 --> 00:02:53.320
land protocol, it

00:02:53.320 --> 00:02:57.200
 was solved. And that is in the library, because it's an

00:02:57.200 --> 00:02:58.920
 asynchronous process,

00:02:58.920 --> 00:03:02.440
 like a network connection. And Emacs has an event loop that

00:03:02.440 --> 00:03:05.560
 listens to

00:03:06.480 --> 00:03:06.480


00:03:06.480 --> 00:03:09.490
 messages on the network. So it's integrated into the Emacs

00:03:09.490 --> 00:03:10.360
 core. You

00:03:10.360 --> 00:03:13.870
 don't have to do anything more. But where it gets

00:03:13.870 --> 00:03:15.920
 interesting, again, is this

00:03:15.920 --> 00:03:21.900
 idea I had, maybe we could use it for more in Emacs. Emacs

00:03:21.900 --> 00:03:23.840
 is fundamentally

00:03:23.840 --> 00:03:26.740
 about drawing buffers to a screen and not fundamentally.

00:03:26.740 --> 00:03:27.720
 But the part that's

00:03:27.720 --> 00:03:30.800
 not a Lisp machine, the graphical part, it's drawing buff

00:03:30.800 --> 00:03:32.000
ers to a screen and you

00:03:32.000 --> 00:03:36.060
 have to composite these buffers somehow. And now we're

00:03:36.060 --> 00:03:38.400
 using different desktop

00:03:38.400 --> 00:03:43.640
 toolkits like GTK on the Linux. And maybe we don't have to,

00:03:43.640 --> 00:03:45.000
 we can just draw

00:03:45.000 --> 00:03:49.980
 pixel buffers, like draw into a pixel buffer. Like, I don't

00:03:49.980 --> 00:03:50.880
 know, what do we

00:03:50.880 --> 00:03:55.640
 use for rendering? I forgot, Cairo or something. And this

00:03:55.640 --> 00:03:56.760
 could just write

00:03:56.760 --> 00:03:59.770
 into a pixel buffer. So now we arranged, and Emacs is

00:03:59.770 --> 00:04:01.080
 already a window manager.

00:04:01.080 --> 00:04:03.970
 So it's not that difficult to implement a window manager

00:04:03.970 --> 00:04:05.320
 with Emacs because Emacs

00:04:05.320 --> 00:04:11.060
 is a window manager, pretty good one, I think. And no, I

00:04:11.060 --> 00:04:13.040
 just lost a little bit

00:04:13.040 --> 00:04:16.670
 more train of thought. But so far to contributing to the

00:04:16.670 --> 00:04:17.960
 core and we could do

00:04:17.960 --> 00:04:20.840
 more with it. So next question.

00:04:20.840 --> 00:04:23.960
 - One thing, Michael, quickly. Sorry. Yeah, it would be

00:04:23.960 --> 00:04:25.200
 great if you could also

00:04:25.200 --> 00:04:27.510
 repeat the questions for the stream before you answer them.

00:04:27.510 --> 00:04:28.040
 That would be

00:04:28.040 --> 00:04:28.440
 awesome.

00:04:28.440 --> 00:04:30.120
 - I will do that.

00:04:30.120 --> 00:04:30.920
 - Thank you.

00:04:32.600 --> 00:04:32.600


00:04:32.600 --> 00:04:36.260
 Question. Is this valent compositor in Emacs? What

00:04:36.260 --> 00:04:39.040
 different with XReparent in

00:04:39.040 --> 00:04:45.290
 X11? Okay, this is a little bit difficult for me to

00:04:45.290 --> 00:04:48.520
 understand, but I answered

00:04:48.520 --> 00:04:53.550
 anyway. So first, is this a valent compositor in Emacs? I

00:04:53.550 --> 00:04:54.840
 would say no,

00:04:54.840 --> 00:04:58.870
 because the Emacs doesn't do the valent compositoring. I

00:04:58.870 --> 00:05:00.440
 first planned to do it

00:05:00.440 --> 00:05:03.130
 like this, but it doesn't work out like this because you

00:05:03.130 --> 00:05:06.120
 have to handle file

00:05:06.120 --> 00:05:10.120
 descriptors and Emacs can't handle file descriptors except

00:05:10.120 --> 00:05:11.480
 you go down to the C

00:05:11.480 --> 00:05:19.930
 part. So no, it's not. It's a C, a WL roots valent compos

00:05:19.930 --> 00:05:22.840
itor that talks to

00:05:22.840 --> 00:05:29.290
 Emacs and Emacs is, it's just like a helper compositor. Em

00:05:29.290 --> 00:05:31.160
acs says where to

00:05:31.160 --> 00:05:34.380
 put the windows. It's the window manager. And in the future

00:05:34.380 --> 00:05:35.360
, where to put the

00:05:35.360 --> 00:05:40.170
 inputs so that you can insert Emacs into the input stream

00:05:40.170 --> 00:05:43.320
 like XWM does it. Okay,

00:05:43.320 --> 00:05:49.070
 then what different with XReparent in X11? I don't actually

00:05:49.070 --> 00:05:51.000
 know what XReparent

00:05:51.000 --> 00:05:55.150
 is, so I'm sorry. I have to skip this one. How would

00:05:55.150 --> 00:05:57.000
 multiple monitors be

00:05:57.000 --> 00:05:59.990
 handled? Separate frames? Yes, separate frames. This is

00:05:59.990 --> 00:06:01.160
 already testable. It's

00:06:01.160 --> 00:06:08.540
 implemented. As soon as a new monitor crops up, the Emacs

00:06:08.540 --> 00:06:10.320
 is, the valent

00:06:10.320 --> 00:06:15.490
 protocol informs about a new output event and Emacs then

00:06:15.490 --> 00:06:17.000
 pops up a new frame

00:06:17.000 --> 00:06:22.240
 on this output. And depending on how usable you want to

00:06:22.240 --> 00:06:24.760
 have it, you can just,

00:06:24.760 --> 00:06:27.160
 there could be a menu like where do you want the output? Do

00:06:27.160 --> 00:06:27.840
 you want to have a

00:06:27.840 --> 00:06:30.230
 screen on it or something like that? And then you have

00:06:30.230 --> 00:06:31.480
 output handling. Output

00:06:31.480 --> 00:06:35.100
 handling is already working. So separate frames, one per

00:06:35.100 --> 00:06:37.480
 output because that's

00:06:37.480 --> 00:06:41.010
 the Emacs analog. You have windows, you have frames, frames

00:06:41.010 --> 00:06:42.760
 are like monitors.

00:06:42.760 --> 00:06:45.800
 And the special thing about valent outputs is they don't

00:06:45.800 --> 00:06:46.600
 have to be a whole

00:06:46.600 --> 00:06:49.980
 monitor or hardware device. They can also be like a normal

00:06:49.980 --> 00:06:52.840
 frame. Next question

00:06:52.840 --> 00:06:57.440
 is, could you make it so you can restart Emacs without

00:06:57.440 --> 00:06:59.400
 logging out or switch to

00:06:59.400 --> 00:07:02.640
 non-Emacs buffer while Emacs is blocking? These are the

00:07:02.640 --> 00:07:05.080
 biggest issues with XWM.

00:07:05.080 --> 00:07:13.240
 While Emacs is blocking. Okay, I have to think about this a

00:07:13.240 --> 00:07:14.760
 little bit

00:07:16.120 --> 00:07:19.270
 because right now I have a problem with restarting and the

00:07:19.270 --> 00:07:20.600
 code I wrote. Emacs

00:07:20.600 --> 00:07:25.340
 starts the valent server and then starts to talk to it, the

00:07:25.340 --> 00:07:28.520
 server to Emacs. And

00:07:28.520 --> 00:07:33.070
 as soon as the server terminates, Emacs terminates. Because

00:07:33.070 --> 00:07:34.680
 GTK has this feature

00:07:34.680 --> 00:07:38.550
 and it's a bug since several years and they know it, but

00:07:38.550 --> 00:07:39.880
 apparently it's a

00:07:39.880 --> 00:07:44.830
 feature, not a bug. So as soon as a valent GTK window

00:07:44.830 --> 00:07:47.000
 terminates, it terminates

00:07:47.000 --> 00:07:51.420
 its process. That means if there's an Emacs frame on valent

00:07:51.420 --> 00:07:52.440
 and the frame is

00:07:52.440 --> 00:07:57.610
 powered by GTK as Emacs currently does it, valent termin

00:07:57.610 --> 00:07:59.560
ates the frame, Emacs

00:07:59.560 --> 00:08:02.870
 gets terminated, whole thing is terminated. Well, normally

00:08:02.870 --> 00:08:03.480
 you would like

00:08:03.480 --> 00:08:06.500
 something that like Emacs terminal frame, and then you pop

00:08:06.500 --> 00:08:07.640
 open valent buffer

00:08:07.640 --> 00:08:10.160
 or something like that. And it's just a long running Emacs

00:08:10.160 --> 00:08:11.640
 session, but that's

00:08:11.640 --> 00:08:16.670
 a blocker right now and it's GTK's fault. But we already

00:08:16.670 --> 00:08:18.040
 know the other

00:08:18.040 --> 00:08:22.220
 bug we have since years. And so I don't think this one is

00:08:22.220 --> 00:08:23.640
 resolved either.

00:08:23.640 --> 00:08:29.040
 So what does mean or switch to non-Emacs buffers while Em

00:08:29.040 --> 00:08:31.000
acs is blocking? No,

00:08:31.000 --> 00:08:35.090
 you can't. Okay. Now you can't do this because Emacs does

00:08:35.090 --> 00:08:36.200
 the window managing

00:08:36.200 --> 00:08:43.700
 as in EXWM. So there's a new window or you want to switch a

00:08:43.700 --> 00:08:45.960
 window. So it has

00:08:45.960 --> 00:08:50.640
 to go through Emacs. Emacs gets a request for new window or

00:08:50.640 --> 00:08:52.280
 Emacs just says layout

00:08:52.280 --> 00:08:55.820
 this window at this point. And if Emacs as it's single

00:08:55.820 --> 00:08:58.200
 threaded is blocked, it

00:08:58.200 --> 00:09:05.830
 can't issue this layout request. So yeah, that's not going

00:09:05.830 --> 00:09:09.320
 to work out as long

00:09:09.320 --> 00:09:17.190
 as Emacs is just single threaded. Next question. Did this

00:09:17.190 --> 00:09:19.400
 project can implement

00:09:19.400 --> 00:09:23.680
 mirror of buffer for Emacs different window? Okay. I think

00:09:23.680 --> 00:09:25.320
 I got this question.

00:09:27.320 --> 00:09:31.810
 Can you, okay. In Emacs normally you know how buffers work.

00:09:31.810 --> 00:09:32.760
 Like you have one

00:09:32.760 --> 00:09:35.420
 buffer, you split it, you have two buffers, but it's the

00:09:35.420 --> 00:09:37.000
 same buffer. Then you can

00:09:37.000 --> 00:09:39.320
 take one of the buffers and look at another place in this

00:09:39.320 --> 00:09:42.360
 buffer. You can't do

00:09:42.360 --> 00:09:45.930
 this with Emacs buffers, but you can't do it like an EXWM.

00:09:45.930 --> 00:09:47.080
 You can't do it with

00:09:47.080 --> 00:09:50.980
 the X windows because there's only one view on the X

00:09:50.980 --> 00:09:54.440
 windows. So now the special

00:09:54.440 --> 00:09:57.790
 thing with Valent, you can have multiple views on the same

00:09:57.790 --> 00:10:00.040
 window. And when I got

00:10:00.040 --> 00:10:03.210
 to implement this idea, I was, yeah, of course I'm going to

00:10:03.210 --> 00:10:04.440
 do multiple views,

00:10:04.440 --> 00:10:09.710
 same window as Emacs does it. And I had it implemented. And

00:10:09.710 --> 00:10:11.560
 then I found out, no,

00:10:11.560 --> 00:10:16.660
 this is not going to work. Because a window has always one

00:10:16.660 --> 00:10:18.920
 size. Like you can't,

00:10:18.920 --> 00:10:23.000
 if you have a video open, you can't just tell it, make it

00:10:23.000 --> 00:10:24.680
 this size. Or if you have

00:10:24.680 --> 00:10:29.080
 a web browser open and you can't have different sizes. So

00:10:29.080 --> 00:10:32.360
 it's in principle, it's

00:10:32.360 --> 00:10:37.910
 comfortable with the Emacs model. Like the normal desktop

00:10:37.910 --> 00:10:39.640
 model doesn't work with Emacs. So

00:10:39.640 --> 00:10:44.200
 no, this still doesn't work. You can do a hack. I tried it.

00:10:44.200 --> 00:10:45.320
 You have like one big

00:10:45.320 --> 00:10:48.750
 window that you have other windows and you scale them or

00:10:48.750 --> 00:10:50.600
 you crop them, but this isn't

00:10:50.600 --> 00:10:54.890
 well supported in WL roots. And also it doesn't make a lot

00:10:54.890 --> 00:10:57.720
 of sense actually. So I scrapped it

00:10:57.720 --> 00:11:02.030
 and there's just one view. Okay. So just one view because

00:11:02.030 --> 00:11:04.280
 it doesn't make a lot of sense to have

00:11:04.280 --> 00:11:08.120
 multiple views. How does this next question, how does the

00:11:08.120 --> 00:11:10.840
 single threaded, threaded affects

00:11:10.840 --> 00:11:16.470
 the project? Yeah. And so far as it does affect any Emacs

00:11:16.470 --> 00:11:19.640
 package, like it's not a special

00:11:19.640 --> 00:11:25.400
 problem, not a, not a actual problem. Like the only, only,

00:11:25.400 --> 00:11:26.480
 um, um,

00:11:26.480 --> 00:11:32.850
 there's just one thing where Emacs could block, uh, the

00:11:32.850 --> 00:11:35.720
 other windows. It's when the other window

00:11:35.720 --> 00:11:39.730
 requests a layout, like there's a new program that opened a

00:11:39.730 --> 00:11:42.760
 window or another window opened

00:11:42.760 --> 00:11:46.840
 and Emacs is blocking and can't service this new surface

00:11:46.840 --> 00:11:49.400
 request. So you won't see anything,

00:11:49.400 --> 00:11:53.620
 but except from that, um, if you see the window Emacs hangs

00:11:53.620 --> 00:11:57.320
 like with the EXWVM, you just can use

00:11:57.320 --> 00:12:00.790
 the other program because it's not coupled to Emacs in any

00:12:00.790 --> 00:12:02.120
 significant way.

00:12:03.720 --> 00:12:08.190
 Um, and the good thing is, and that's the short side remark

00:12:08.190 --> 00:12:11.240
. If you want to go further than our

00:12:11.240 --> 00:12:14.000
 single threaded thing, it's like, I think we, we have a

00:12:14.000 --> 00:12:16.200
 talk somewhere in this conference, like,

00:12:16.200 --> 00:12:21.420
 um, how Emacs was always async and is it, is async and Em

00:12:21.420 --> 00:12:24.200
acs is async. Well, we have async

00:12:24.200 --> 00:12:27.670
 processes. We have callbacks, we have network processes we

00:12:27.670 --> 00:12:29.800
 can use asynchronously. And I think

00:12:29.800 --> 00:12:33.820
 that's the way forward for Emacs to don't be blocking, like

00:12:33.820 --> 00:12:35.800
 have worker threads, something

00:12:35.800 --> 00:12:40.140
 like this and have a main thing because it's one big muddle

00:12:40.140 --> 00:12:43.160
 of muddle of code. I don't think you

00:12:43.160 --> 00:12:49.280
 can just separate it. So, but we could lean more into these

00:12:49.280 --> 00:12:53.320
 helpers and workers like Node.js does

00:12:53.320 --> 00:12:57.950
 it or something like that. So next question is this

00:12:57.950 --> 00:13:01.800
 technology. I have a short matter question.

00:13:01.800 --> 00:13:08.200
 Do I have to stop or can I answer all the questions? Um,

00:13:08.200 --> 00:13:09.880
 yeah, I think we can go on for now.

00:13:09.880 --> 00:13:13.420
 And, um, the BBB room is also open for anyone who does want

00:13:13.420 --> 00:13:15.720
 to join here to ask questions directly,

00:13:15.720 --> 00:13:18.420
 um, in case the stream moves on. But I think this is our

00:13:18.420 --> 00:13:20.280
 last talk on the Dev track before the launch

00:13:20.280 --> 00:13:22.850
 break. So yeah, you should be good. Ah, nice. I don't need

00:13:22.850 --> 00:13:24.520
 a lunch break because, uh, uh,

00:13:24.520 --> 00:13:32.110
 in Europe it's already like the next meal. Right. So, um,

00:13:32.110 --> 00:13:34.760
 next question is this technology

00:13:34.760 --> 00:13:38.840
 need right? Valence server. Can it works with GNOME 3?

00:13:38.840 --> 00:13:42.760
 Actually, yes, it needs to write a

00:13:42.760 --> 00:13:47.490
 valence server because valence needs a valence server. And,

00:13:47.490 --> 00:13:49.320
 uh, just for you, what does the

00:13:49.320 --> 00:13:53.900
 server actually do? The server does, um, for example, it is

00:13:53.900 --> 00:13:55.880
 the compositor. The valence

00:13:55.880 --> 00:13:58.680
 compositor is part of the valence compositor. It's like

00:13:58.680 --> 00:14:00.360
 difficult naming they had there.

00:14:00.360 --> 00:14:04.320
 And it does a merging of, of windows. You have, um, you

00:14:04.320 --> 00:14:06.760
 have an application and it draws a window.

00:14:06.760 --> 00:14:09.730
 So you give it a pixel buffer, the application draws in

00:14:09.730 --> 00:14:11.560
 this pixel buffer, and then you put it

00:14:11.560 --> 00:14:16.310
 on the screen and compositor this other surfaces that are

00:14:16.310 --> 00:14:19.560
 on the screen. And, um, you have to look

00:14:19.560 --> 00:14:22.320
 into the frame rate you want to have and stuff like that.

00:14:22.320 --> 00:14:24.360
 So it's really low level stuff. It's,

00:14:24.360 --> 00:14:28.020
 it's, um, that's the thing the valence compositor does. And

00:14:28.020 --> 00:14:30.200
 it does input handling like lip input,

00:14:30.200 --> 00:14:33.760
 and then it receives something and routes it to this

00:14:33.760 --> 00:14:37.320
 surface of that surface, or I think shell

00:14:37.320 --> 00:14:41.340
 it's called. It's a shell that reserves the input. Okay.

00:14:41.340 --> 00:14:44.760
 Can it work with GNOME 3? Yes,

00:14:44.760 --> 00:14:47.930
 maybe. I don't know how open they are and if you can

00:14:47.930 --> 00:14:50.600
 integrate it, but I don't think that's,

00:14:50.600 --> 00:14:55.520
 that's a good direction because what do you want to build?

00:14:55.520 --> 00:15:00.040
 So, ah, just one thing since Emacs can

00:15:00.040 --> 00:15:04.130
 talk valence and is a normal valence client with the

00:15:04.130 --> 00:15:07.880
 library I wrote, it can take, can talk to any

00:15:07.880 --> 00:15:13.520
 other valence program and maybe you can do something useful

00:15:13.520 --> 00:15:16.520
 with GNOME 3 and Emacs as a

00:15:16.520 --> 00:15:19.500
 valence client. Like you can automate parts of your desktop

00:15:19.500 --> 00:15:21.720
 or something like that. Um, yeah,

00:15:21.720 --> 00:15:25.850
 that would be a possibility. Good. I'm going now to the

00:15:25.850 --> 00:15:28.200
 next question that is, could there be an

00:15:28.200 --> 00:15:31.940
 Emacs valence server and just connect with Emacs client?

00:15:31.940 --> 00:15:36.600
 Cool. I named my thing Emacs valence

00:15:36.600 --> 00:15:42.050
 server. So there is already an Emacs valence server. Um,

00:15:42.050 --> 00:15:44.600
 connect with Emacs client.

00:15:44.600 --> 00:15:50.600
 I don't actually get the question, but I think, um, yes, of

00:15:50.600 --> 00:15:53.080
 course you have an Emacs running.

00:15:53.080 --> 00:15:56.070
 It doesn't have to be an Emacs valence server because Emacs

00:15:56.070 --> 00:15:56.920
 is multi-display

00:15:56.920 --> 00:16:01.090
 and then you can just pop open the windows in valence or

00:16:01.090 --> 00:16:04.360
 something like this. Next question is

00:16:04.360 --> 00:16:07.650
 when you share your code, could you provide the equivalent

00:16:07.650 --> 00:16:10.040
 of an X session script for those who

00:16:10.040 --> 00:16:17.920
 are on XWM and want to test? Yes, I can, because it's my

00:16:17.920 --> 00:16:21.720
 goal is to have it run like this for

00:16:21.720 --> 00:16:24.660
 myself. But when I share the code in the coming days, as I

00:16:24.660 --> 00:16:29.640
'm planning, no, you won't run it like

00:16:29.640 --> 00:16:33.910
 this because it's not that polished yet. So a startup is a

00:16:33.910 --> 00:16:36.360
 little bit more involved and I

00:16:36.360 --> 00:16:41.030
 haven't researched all the ways you can make it polished,

00:16:41.030 --> 00:16:44.600
 but it's on the roadmap. So stay tuned.

00:16:46.520 --> 00:16:51.220
 The next question is, I have a demo to show this Emacs val

00:16:51.220 --> 00:16:52.520
ence compositor,

00:16:52.520 --> 00:16:56.900
 even if buggy now, just curious. Yes, there is a demo. Like

00:16:56.900 --> 00:16:59.480
 you just watched one in the video. It

00:16:59.480 --> 00:17:06.370
 was the compositor running. It did the compositing of the

00:17:06.370 --> 00:17:11.080
 video I made. And the other demo is the

00:17:11.080 --> 00:17:16.980
 code I'm planning to release. The code right now is working

00:17:16.980 --> 00:17:21.960
, but there's some documentation also,

00:17:21.960 --> 00:17:26.510
 but it's not finished. So have fun digging in there, but

00:17:26.510 --> 00:17:29.400
 don't expect anything like hyper

00:17:29.400 --> 00:17:33.690
 polished or something like this. More, yeah, I'm looking

00:17:33.690 --> 00:17:36.680
 for feedback and ideas and where to take

00:17:36.680 --> 00:17:42.260
 this thing. Now we're going to get to buffer mirroring. So

00:17:42.260 --> 00:17:44.760
 next question is, so the current

00:17:44.760 --> 00:17:47.950
 limitation is that buffer mirroring doesn't respect

00:17:47.950 --> 00:17:50.360
 different widths or heights. Yeah,

00:17:50.360 --> 00:17:53.530
 the limitation is fundamentally if you have a normal

00:17:53.530 --> 00:17:55.800
 desktop window, look at your browser

00:17:55.800 --> 00:17:59.980
 or your video player, just watching me, you are just

00:17:59.980 --> 00:18:04.600
 watching me. It just has one size. You can't

00:18:04.600 --> 00:18:08.570
 say, please make yourself this size and this size and show

00:18:08.570 --> 00:18:12.040
 me two different parts of your site or

00:18:12.040 --> 00:18:17.520
 that doesn't work. It's not thought like this. So you can

00:18:17.520 --> 00:18:20.680
 hack something up that you have like

00:18:20.680 --> 00:18:24.300
 a big window and then you show a little crop part of it and

00:18:24.300 --> 00:18:26.760
 another buffer. This does actually work,

00:18:27.560 --> 00:18:32.940
 but just a little site or like if you want to do something

00:18:32.940 --> 00:18:38.680
 like this, be prepared. WL roots doesn't,

00:18:38.680 --> 00:18:43.740
 okay. So a Wayland server or compositor has to do its own

00:18:43.740 --> 00:18:47.880
 compositing. That means it has to

00:18:47.880 --> 00:18:51.590
 composite the different buffers or pixel buffer it has in

00:18:51.590 --> 00:18:53.880
 one pixel buffer and put it on the output.

00:18:55.000 --> 00:18:59.600
 That means you have to do that yourself. And there's a

00:18:59.600 --> 00:19:01.960
 helper to do this in WL roots.

00:19:01.960 --> 00:19:07.410
 This is WLR scene as it's called. And it does this for you.

00:19:07.410 --> 00:19:09.720
 You build a scene tree and does

00:19:09.720 --> 00:19:14.510
 damage tracking so it doesn't repaint everything. It saves

00:19:14.510 --> 00:19:16.920
 battery and it's a lot of work to do this

00:19:16.920 --> 00:19:21.710
 and it's ready there. But what is missing in this helper is

00:19:21.710 --> 00:19:24.920
 cropping and resizing. So right now you

00:19:24.920 --> 00:19:28.700
 can't crop and you can't resize. And I would say this is

00:19:28.700 --> 00:19:31.240
 the main blocker for using the thing I

00:19:31.240 --> 00:19:38.100
 built, Wayland compositor is you can't crop windows. And if

00:19:38.100 --> 00:19:42.920
 you, maybe you use MP4 like the

00:19:42.920 --> 00:19:48.310
 video player, it doesn't respect what you tell it, what the

00:19:48.310 --> 00:19:51.480
 size it should get. It just, it keeps its

00:19:51.480 --> 00:19:55.400
 aspect ratio and then just respects and either width or

00:19:55.400 --> 00:19:58.280
 height, but not both if they don't fit.

00:19:58.280 --> 00:20:01.790
 So you want to fit it in a buffer and then it's stay, it's

00:20:01.790 --> 00:20:04.360
 overflows the buffer a little bit. You

00:20:04.360 --> 00:20:09.200
 can see it in the talk video. In my talk, I posted like the

00:20:09.200 --> 00:20:11.720
 little camera picture of me is not always

00:20:11.720 --> 00:20:15.550
 there where it should be. It's over the mode line or

00:20:15.550 --> 00:20:18.680
 something like that. And yeah, there needs to

00:20:18.680 --> 00:20:25.180
 be some cropping. XWVM does cropping. It crops. You can try

00:20:25.180 --> 00:20:28.920
 it out. If someone of you is a XWM

00:20:28.920 --> 00:20:39.560
 user, he can do a full screen video MP4 video, and then

00:20:39.560 --> 00:20:42.200
 just split right. And then you'll see

00:20:42.200 --> 00:20:46.990
 just half the video screen because it's no cropped, but the

00:20:46.990 --> 00:20:49.320
 video player in the background

00:20:49.320 --> 00:20:55.480
 still sends the full screen. Okay. So much for this topic.

00:20:55.480 --> 00:20:59.420
 Ah, okay. And if you want to do cropping, you have to do

00:20:59.420 --> 00:21:03.720
 your own compositor. I asked the real W

00:21:05.080 --> 00:21:09.870
 WL roots. Sorry. That's this W is complicated for me. I

00:21:09.870 --> 00:21:16.120
 asked the WL roots developers on their IRC

00:21:16.120 --> 00:21:19.450
 channel and they told me, yes, we wanted to have this. We

00:21:19.450 --> 00:21:21.400
 have an issue open, but it's not

00:21:21.400 --> 00:21:24.870
 implemented and you have to do it yourself. And yes,

00:21:24.870 --> 00:21:27.320
 whoever wants us has to do it himself. And

00:21:27.320 --> 00:21:32.180
 that's a lot of work in C. Okay. I'll jump in quickly at

00:21:32.180 --> 00:21:33.800
 one thing. Yeah. I think we were about

00:21:33.800 --> 00:21:36.040
 like two minutes break, sorry, two minutes away from our

00:21:36.040 --> 00:21:38.840
 lunch break. At which point I think the

00:21:38.840 --> 00:21:42.160
 stream will be moving on or will be stopped, but this BQB

00:21:42.160 --> 00:21:44.600
 room will be open. So yeah, Michael and

00:21:44.600 --> 00:21:47.250
 anyone else who is participating in the Q&A, you're more

00:21:47.250 --> 00:21:49.160
 than welcome to stay here and continue the

00:21:49.160 --> 00:21:55.160
 question and answer. Okay. Thank you for this announcement.

00:21:55.160 --> 00:21:59.960
 Yeah. I would like to keep answering

00:21:59.960 --> 00:22:05.570
 questions and maybe yeah, until there's no more interest or

00:22:05.570 --> 00:22:08.200
 I am hungry too, but I don't need a

00:22:08.200 --> 00:22:12.600
 lunch as I already. Yep. Okay. Sounds great. Yep. So yeah,

00:22:12.600 --> 00:22:14.840
 the stream will probably be cut off in

00:22:14.840 --> 00:22:17.940
 about a minute or so, but yeah, this room will be open and

00:22:17.940 --> 00:22:20.040
 you and others will be able to stay here

00:22:20.040 --> 00:22:25.160
 and keep asking and answering questions. Okay. Thanks.

00:22:25.160 --> 00:22:29.720
 Thank you. Then let's go on to the next

00:22:29.720 --> 00:22:48.790
 question. I just scrolled. I forgot my place. Okay. Could

00:22:48.790 --> 00:22:51.000
 you use some of the packages with

00:22:51.000 --> 00:22:54.920
 other Wayland compositors? Probably not all of it's way KDE

00:22:54.920 --> 00:22:57.160
, Rivergnome. Yes, you can. And thank

00:22:57.160 --> 00:23:01.680
 you for this idea because I already, I didn't think of this

00:23:01.680 --> 00:23:04.440
 before. You can use it because you

00:23:04.440 --> 00:23:07.620
 can talk to them. Like you can talk to Wayland protocols.

00:23:07.620 --> 00:23:09.560
 You can have a look at them. There's

00:23:09.560 --> 00:23:14.830
 like the core protocol of Wayland is in the core repository

00:23:14.830 --> 00:23:18.120
 of the Wayland project. And there's a

00:23:18.120 --> 00:23:21.680
 Wayland protocols repository. They have like three tier

00:23:21.680 --> 00:23:23.720
 staging, experimental and stable,

00:23:23.720 --> 00:23:26.900
 almost nothing in Wayland is stable. So be prepared for

00:23:26.900 --> 00:23:28.920
 some changes in the future, I think.

00:23:28.920 --> 00:23:35.700
 And you can talk to these protocols. They are not that

00:23:35.700 --> 00:23:39.800
 difficult, but some things are already a bit

00:23:39.800 --> 00:23:43.370
 too complicated. Like you have to take output and then to

00:23:43.370 --> 00:23:45.640
 get the actual width or something like

00:23:45.640 --> 00:23:49.630
 this, you have to request another output. And this one

00:23:49.630 --> 00:23:52.600
 talks to you and the other output says, okay,

00:23:52.600 --> 00:23:55.050
 I'm done or something like this. Some things are a little

00:23:55.050 --> 00:23:58.680
 bit difficult, but it's quite readable

00:23:58.680 --> 00:24:03.520
 and understandable and you can do scripting Sway, but I don

00:24:03.520 --> 00:24:06.120
't have a lot of experience there because

00:24:06.120 --> 00:24:11.930
 like I'm an XWM user. I do it in Emacs. I'm staying on X. I

00:24:11.930 --> 00:24:14.520
 had Sway several years ago,

00:24:14.520 --> 00:24:18.110
 but only a short time. So I'm not that knowledgeable. The

00:24:18.110 --> 00:24:20.040
 next question is,

00:24:20.760 --> 00:24:26.170
 will Wayland support reach feature parity with XWM in the

00:24:26.170 --> 00:24:29.560
 future? Will there be other trade-offs?

00:24:29.560 --> 00:24:35.830
 No, it won't. Okay. But don't think, it's not something

00:24:35.830 --> 00:24:38.760
 usable because I don't think all the

00:24:38.760 --> 00:24:45.530
 features in the EXWM is needed. I want to work spaces as I

00:24:45.530 --> 00:24:49.320
 said in the talk, because yeah,

00:24:49.320 --> 00:24:53.460
 Emacs does work spaces and I won't do this, but I will do

00:24:53.460 --> 00:24:58.200
 everything. Like what's my plan with

00:24:58.200 --> 00:25:01.690
 this thing? It's like the two use cases I already alluded

00:25:01.690 --> 00:25:06.280
 to in the video. The first is you have a

00:25:06.280 --> 00:25:11.030
 Wayland surface and you show it inside an Emacs buffer or

00:25:11.030 --> 00:25:13.160
 an Emacs window. So you have a kind of

00:25:13.160 --> 00:25:22.510
 Wayland buffer, I'm calling it. That's the thing EXWM does.

00:25:22.510 --> 00:25:26.600
 And I think, yeah, it should reach

00:25:26.600 --> 00:25:30.710
 feature parity with it. It also has output management and

00:25:30.710 --> 00:25:32.600
 like the input handling,

00:25:32.600 --> 00:25:37.700
 there's like the simulation keys and I don't know what else

00:25:37.700 --> 00:25:41.080
, but actually I don't have a solution

00:25:41.080 --> 00:25:46.060
 yet for the input handling. It's a thing I haven't looked

00:25:46.060 --> 00:25:49.480
 that much into. Will there be other

00:25:49.480 --> 00:25:53.660
 trade-offs? Yeah, most certainly there are always trade-

00:25:53.660 --> 00:25:56.200
offs, but I can't tell you which.

00:25:56.200 --> 00:26:00.920
 So the next question is, what is the biggest difference

00:26:00.920 --> 00:26:01.880
 between X,

00:26:01.880 --> 00:26:07.000
 Org and Wayland that you have found? Okay, what's the

00:26:07.000 --> 00:26:10.360
 biggest difference?

00:26:10.360 --> 00:26:18.970
 Don't know actually, don't know. First of all, I'm not that

00:26:18.970 --> 00:26:23.320
 knowledgeable in X, Org. I used it,

00:26:23.320 --> 00:26:28.150
 but I have no more programs in X Window Manager. I haven't

00:26:28.150 --> 00:26:30.520
 looked a lot into it, except

00:26:31.400 --> 00:26:37.380
 WEM, I looked into the code, into Elisp code and how it

00:26:37.380 --> 00:26:39.880
 does the communication and

00:26:39.880 --> 00:26:46.750
 took inspiration of course. Yeah, big difference is you don

00:26:46.750 --> 00:26:50.120
't have one monolithic server. Like you

00:26:50.120 --> 00:26:54.390
 have one X, Org server and in Wayland you have lots of

00:26:54.390 --> 00:26:57.800
 servers like GNOME has one, KDE has one,

00:26:58.760 --> 00:27:02.510
 then WL roots is another approach, Swae has an

00:27:02.510 --> 00:27:05.480
 implementation in WL roots and so on.

00:27:05.480 --> 00:27:10.350
 So now it's the last question I find in my path is, did you

00:27:10.350 --> 00:27:13.880
 know EAF? Yes, I know. Of course,

00:27:13.880 --> 00:27:17.000
 like I think we have a talk. We have a talk. We had talks

00:27:17.000 --> 00:27:21.400
 and I never used it. I'm sorry.

00:27:22.440 --> 00:27:29.400
 Maybe it's interesting. It's Python. I don't do a lot of

00:27:29.400 --> 00:27:31.640
 Python and

00:27:31.640 --> 00:27:37.220
 similar use case. It's like, I think it's embedded X

00:27:37.220 --> 00:27:40.200
 widgets. Please correct me if I'm wrong.

00:27:40.200 --> 00:27:47.450
 Yeah, that's all I can say to this topic. But I think like

00:27:47.450 --> 00:27:49.800
 any application framework,

00:27:49.800 --> 00:27:53.920
 you can want to do an Emacs or stuff like that will mesh

00:27:53.920 --> 00:27:57.240
 really good with Emacs compositor that

00:27:57.240 --> 00:28:02.650
 is integrated or like almost integrated in Emacs because

00:28:02.650 --> 00:28:05.640
 now you can use this to do your application

00:28:05.640 --> 00:28:10.070
 framework and paint the windows in Emacs. And I think maybe

00:28:10.070 --> 00:28:12.440
 we can come back to the reparenting

00:28:12.440 --> 00:28:18.450
 X thing, which I don't really understand. So I don't know

00:28:18.450 --> 00:28:21.560
 exactly how X does the X widgets, like

00:28:21.560 --> 00:28:28.190
 no idea. But I think we can do something similar with Way

00:28:28.190 --> 00:28:31.960
land. Like we can just embed the little

00:28:31.960 --> 00:28:36.710
 Wayland surfaces in an Emacs buffer. And that's a thing I

00:28:36.710 --> 00:28:40.440
 wanted to get a discussion started.

00:28:40.440 --> 00:28:45.950
 Someone, yeah, maybe someone has an idea. Maybe someone is

00:28:45.950 --> 00:28:49.000
 already deep down in Emacs internals

00:28:49.000 --> 00:28:54.620
 and knows how these displays stuff works like image display

00:28:54.620 --> 00:28:57.880
, X widget display, and so on.

00:28:57.880 --> 00:29:03.290
 And maybe this person or someone else has an idea how we

00:29:03.290 --> 00:29:05.640
 could do the Wayland surfaces.

00:29:05.640 --> 00:29:09.280
 Right now it's just Emacs receives a request for new

00:29:09.280 --> 00:29:13.160
 surface. Okay. You open a new program.

00:29:13.160 --> 00:29:16.430
 The program says to the Wayland server, "Hey, I'm here. I

00:29:16.430 --> 00:29:19.480
 want to have surface." Wayland server

00:29:19.480 --> 00:29:24.750
 gives it the surface and says to Emacs, "Hey, here's a new

00:29:24.750 --> 00:29:27.880
 surface. You can lay it out." And

00:29:27.880 --> 00:29:31.080
 Emacs then can lay it out or not, however it likes.

00:29:31.080 --> 00:29:33.480
 Normally the default path I choose is

00:29:33.480 --> 00:29:38.490
 Emacs bundles, the surface with a buffer. And if the buffer

00:29:38.490 --> 00:29:40.600
 is shown, it shows the surface.

00:29:40.600 --> 00:29:43.690
 And otherwise it's just hidden. But you can do whatever you

00:29:43.690 --> 00:29:45.800
 want with the surface. You just

00:29:45.800 --> 00:29:49.050
 have to say, please put it at this coordinate and this

00:29:49.050 --> 00:29:52.280
 width and this height. So you can put it in

00:29:52.280 --> 00:29:54.980
 a buffer and you can scroll it in a buffer. But this

00:29:54.980 --> 00:29:57.560
 integration, how to put something in a buffer

00:29:57.560 --> 00:30:00.060
 and scroll it there. I don't know how to do it. And I don't

00:30:00.060 --> 00:30:02.920
 know how to do it. It should be like

00:30:02.920 --> 00:30:06.070
 a good solution. I don't know how to do it. Maybe someone

00:30:06.070 --> 00:30:10.040
 of you has an idea. I'm finished with the

00:30:10.040 --> 00:30:17.190
 questions of the path. I haven't had a look in IRC because

00:30:17.190 --> 00:30:20.600
 yes, I was busy talking.

00:30:20.600 --> 00:30:27.910
 I can either like browse through the IRC if you want, or

00:30:27.910 --> 00:30:31.480
 maybe someone wants to say something or

00:30:31.480 --> 00:30:36.410
 have a look. Ah, thank you. I already answered the IRC

00:30:36.410 --> 00:30:39.880
 questions. So yes, I'm finished.

00:30:39.880 --> 00:30:47.720
 I still see some people in the room. Yeah. Maybe someone,

00:30:47.720 --> 00:30:49.880
 if you have an idea or wants to use it.

00:30:49.880 --> 00:30:58.330
 I don't know how fast I will have it in a usable state. It

00:30:58.330 --> 00:30:58.840
's like,

00:31:01.080 --> 00:31:05.200
 at first I just wanted to do this presentation and show to

00:31:05.200 --> 00:31:09.400
 you the possibility. I already read

00:31:09.400 --> 00:31:13.400
 in the internet some places like Emacs, Devel, Mailindus

00:31:13.400 --> 00:31:16.120
 that was one time and other places that

00:31:16.120 --> 00:31:20.080
 other people's had the same, other person had the same

00:31:20.080 --> 00:31:25.800
 ideas. But I was thinking just to lay out

00:31:25.800 --> 00:31:29.740
 the general idea to you. And then I thought, okay, do an

00:31:29.740 --> 00:31:32.200
 experiment, show if it works. And the

00:31:32.200 --> 00:31:35.870
 experiments spun a little bit. It worked. And so I got

00:31:35.870 --> 00:31:40.520
 further and now I have an almost usable thing,

00:31:40.520 --> 00:31:46.990
 but I already spent like a month with it. So we'll take

00:31:46.990 --> 00:31:49.640
 some more time to finish.

00:31:52.840 --> 00:31:59.040
 Yeah. Thanks that you think, Gary, that you think it's, you

00:31:59.040 --> 00:32:03.800
 are happy to test it. Thank you.

00:32:03.800 --> 00:32:08.870
 I would like to have it like a little bit more flexible

00:32:08.870 --> 00:32:11.240
 than the X solutions, because

00:32:11.240 --> 00:32:16.880
 as I told you can have it nested, like you have a normal Em

00:32:16.880 --> 00:32:20.760
acs and you can just do the embedding

00:32:20.760 --> 00:32:24.710
 and the embedded surfaces. And so in a normal Emacs and you

00:32:24.710 --> 00:32:27.400
 don't have to give Emacs the whole

00:32:27.400 --> 00:32:35.080
 desktop. So you don't have to do XWM. You can just have a

00:32:35.080 --> 00:32:39.080
 normal Emacs window and have all the goodies

00:32:39.080 --> 00:32:45.770
 and features there. Okay. Again, the code will be available

00:32:45.770 --> 00:32:49.080
 on my site. I can post you the link,

00:32:49.080 --> 00:32:54.330
 but there's nothing there yet. Oh, wait a few days. I was

00:32:54.330 --> 00:32:57.480
 thinking of doing it this weekend,

00:32:57.480 --> 00:33:03.190
 but it's EmacsConf and I want to listen to your ideas and

00:33:03.190 --> 00:33:06.360
 participate and don't do coding instead.

00:33:06.360 --> 00:33:15.080
 This is the link. I could put it on another code forge, but

00:33:15.080 --> 00:33:18.120
 I want to do something

00:33:19.880 --> 00:33:19.880


00:33:19.880 --> 00:33:26.340
 myself instead. I have a landing page. If I put it in my

00:33:26.340 --> 00:33:29.320
 browser, it's just,

00:33:29.320 --> 00:33:35.840
 yeah, no connection possible. It's not configured. It's

00:33:35.840 --> 00:33:39.080
 just bought, wait a few days.

00:33:42.120 --> 00:33:46.520
 Okay. Short question for the room. Does anyone know someone

00:33:46.520 --> 00:33:48.280
 else working on stuff like this?

00:33:48.280 --> 00:34:05.250
 Because if, please let them know so we can team up and don

00:34:05.250 --> 00:34:06.840
't do it twice.

00:34:11.800 --> 00:34:14.440
 I had a lot of fun with the Emacs part of the code. I like

00:34:14.440 --> 00:34:17.640
 coding in Elisp in general,

00:34:17.640 --> 00:34:22.480
 but it's not that much fun to work on the C side. It's

00:34:22.480 --> 00:34:26.520
 complex and prone to break.

00:34:26.520 --> 00:34:32.360
 So don't mind collaborating.

00:34:41.560 --> 00:34:45.960
 Why the sad face?

00:34:45.960 --> 00:34:56.920
 Yes, I know the lack of active development.

00:35:02.920 --> 00:35:09.400
 Okay. Because yeah, so no problem. You can't know anyone or

00:35:09.400 --> 00:35:10.120
 a lot of,

00:35:10.120 --> 00:35:15.280
 like, it's a good thing. So I got to start it and I wanted

00:35:15.280 --> 00:35:16.200
 to start,

00:35:16.200 --> 00:35:24.260
 you know, people quitting the XW. I don't have problems yet

00:35:24.260 --> 00:35:26.120
. It's not that I started

00:35:26.120 --> 00:35:28.720
 implementing this because I thought, ah, it's not working

00:35:28.720 --> 00:35:30.840
 anymore. I need something new. It's like,

00:35:30.840 --> 00:35:37.680
 it's works fine. I just did it because I thought, well, why

00:35:37.680 --> 00:35:39.720
 not do something new? And because it

00:35:39.720 --> 00:35:45.180
 opens new possibilities, which weren't there before, or at

00:35:45.180 --> 00:35:47.320
 least I didn't know of them.

00:35:47.320 --> 00:35:58.920
 Okay. How could I put this? Okay. If it's ready for no, as

00:35:58.920 --> 00:36:00.440
 I will promote it. If it's

00:36:00.440 --> 00:36:06.030
 ready for normal usement, like you can just install it and

00:36:06.030 --> 00:36:09.480
 use it for an everyday driver

00:36:09.480 --> 00:36:12.150
 and have you do it. You would X session file and can just

00:36:12.150 --> 00:36:14.840
 start it up. It won't be an X session

00:36:14.840 --> 00:36:18.660
 file because that's X and that's a thing of the past and,

00:36:18.660 --> 00:36:20.200
 but something similar.

00:36:20.200 --> 00:36:26.320
 I could imagine posting, like, I don't know, he makes lists

00:36:26.320 --> 00:36:28.280
, Reddit, something like this, but

00:36:29.160 --> 00:36:33.240
 until then, like the code I will release now, it's just

00:36:33.240 --> 00:36:34.200
 experimental and

00:36:34.200 --> 00:36:41.710
 it's for the people who want to get involved and, or want

00:36:41.710 --> 00:36:43.320
 to do their own thing with it,

00:36:43.320 --> 00:36:48.130
 use the client to automate sway or so for them. It's really

00:36:48.130 --> 00:36:49.640
 interesting.

00:36:50.200 --> 00:36:50.200


00:36:50.200 --> 00:37:00.200
 [inaudible]

00:37:00.200 --> 00:37:02.760
 Yes, I know. Like you,

00:37:02.760 --> 00:42:20.290
 okay, this sway.el, I have to look at it, but I don't think

00:42:20.290 --> 00:37:15.000
 now is a good idea.

00:37:17.160 --> 00:37:21.680
 Maybe something useful there. Thank you, PlasmaStrike and G

00:37:21.680 --> 00:37:22.520
argiola.

00:37:22.520 --> 00:37:28.450
 Yes, people are moving and Valent is the future. That's the

00:37:28.450 --> 00:37:30.680
 point I wanted to say. Like, I think

00:37:30.680 --> 00:37:36.840
 you can stay on X, like in the future, but it's not gonna

00:37:36.840 --> 00:37:38.760
 get that much development and

00:37:38.760 --> 00:37:42.520
 sooner or later, like there will be new features and you

00:37:42.520 --> 00:37:44.200
 won't have it in the old one and stuff

00:37:44.200 --> 00:37:48.690
 like that. And for Emacs to be viable as a window manager

00:37:48.690 --> 00:37:51.560
 in this whole computing environment, or as

00:37:51.560 --> 00:37:56.810
 I said, a Lispy Linux desktop, I think it needs to have

00:37:56.810 --> 00:37:59.000
 this Valent capability and

00:37:59.000 --> 00:38:08.680
 that's the way for it to get it.

00:38:09.960 --> 00:38:09.960


00:38:09.960 --> 00:38:21.960
 [inaudible]

00:38:21.960 --> 00:38:28.510
 I'm just reading the IRC log and someone wrote, I was

00:38:28.510 --> 00:38:32.600
 amazed to see the video inside Emacs.

00:38:32.600 --> 00:38:44.280
 Thank you. That was meant to be amazing. Yeah, thank you.

00:38:45.560 --> 00:38:45.560


00:38:45.560 --> 00:38:45.640
 [inaudible]

00:38:46.920 --> 00:38:46.920


00:38:46.920 --> 00:38:47.000
 [inaudible]

00:38:48.280 --> 00:38:48.280


00:38:48.280 --> 00:38:48.360
 [inaudible]

00:38:49.640 --> 00:38:49.640


00:38:49.640 --> 00:38:49.720
 [inaudible]

00:38:51.000 --> 00:38:51.000


00:38:51.000 --> 00:38:51.080
 [inaudible]

00:38:52.080 --> 00:38:52.240
 [inaudible]

00:38:52.240 --> 00:38:52.400
 [inaudible]

00:38:52.400 --> 00:38:52.480
 [inaudible]

00:38:52.480 --> 00:38:52.640
 [inaudible]

00:38:52.640 --> 00:38:52.720
 [inaudible]

00:38:52.720 --> 00:38:52.800
 [inaudible]

00:38:52.800 --> 00:38:52.880
 [inaudible]

00:38:52.880 --> 00:38:52.960
 [inaudible]

00:38:52.960 --> 00:38:53.040
 [inaudible]

00:38:53.040 --> 00:38:53.120
 [inaudible]

00:38:53.120 --> 00:38:53.200
 [inaudible]

00:38:53.200 --> 00:38:53.200
 [inaudible]

00:38:53.200 --> 00:38:53.280
 [inaudible]

00:38:53.280 --> 00:38:53.360
 [inaudible]

00:38:53.360 --> 00:38:53.440
 [inaudible]

00:38:53.440 --> 00:38:53.520
 [inaudible]

00:38:53.520 --> 00:38:53.600
 [inaudible]

00:38:53.600 --> 00:38:53.680
 [inaudible]

00:38:53.680 --> 00:38:53.760
 [inaudible]

00:38:53.760 --> 00:38:53.840
 [inaudible]

00:38:53.840 --> 00:38:53.920
 [inaudible]

00:38:53.920 --> 00:38:54.000
 [inaudible]

00:38:54.000 --> 00:38:54.080
 [inaudible]

00:38:54.080 --> 00:38:54.160
 [inaudible]

00:38:54.160 --> 00:38:54.160
 [inaudible]

00:38:54.160 --> 00:38:54.240
 [inaudible]

00:38:54.240 --> 00:38:54.240
 [inaudible]

00:38:54.240 --> 00:38:54.320
 [inaudible]

00:38:54.320 --> 00:38:54.400
 [inaudible]

00:38:54.400 --> 00:38:54.480
 [inaudible]

00:38:54.480 --> 00:38:54.560
 [inaudible]

00:38:54.560 --> 00:38:54.640
 [inaudible]

00:38:54.640 --> 00:38:54.640
 [inaudible]

00:38:54.640 --> 00:38:54.720
 [inaudible]

00:38:54.720 --> 00:38:54.720
 [inaudible]

00:38:54.720 --> 00:38:54.800
 [inaudible]

00:38:54.800 --> 00:38:54.880
 [inaudible]

00:38:54.880 --> 00:38:54.960
 [inaudible]

00:38:54.960 --> 00:38:55.040
 [inaudible]

00:38:55.040 --> 00:38:55.120
 [inaudible]

00:38:55.120 --> 00:39:20.000
 [inaudible]

00:39:20.000 --> 00:39:20.080
 [inaudible]

00:39:20.080 --> 00:39:20.160
 [inaudible]

00:39:20.160 --> 00:39:20.240
 [inaudible]

00:39:20.800 --> 00:39:20.800


00:39:20.800 --> 00:39:25.920
 Okay, Emax could already do. I'm just reading the IRC

00:39:25.920 --> 00:39:46.400
 because I don't know what else to say right now.

00:39:46.400 --> 00:39:57.040
 [inaudible]

00:39:57.040 --> 00:40:00.880
 Yeah, it's nice to see so many people saying thank you and

00:40:00.880 --> 00:40:07.600
 at least I read it like two times now. So yeah, I'm pleased

00:40:07.600 --> 00:40:10.160
 to see this and the interest in

00:40:10.160 --> 00:40:16.400
 gender.

00:40:16.400 --> 00:40:26.640
 [inaudible]

00:40:26.640 --> 00:40:38.640
 [inaudible]

00:40:38.640 --> 00:40:49.370
 Okay, I see there's still some people typing and it's a lot

00:40:49.370 --> 00:40:52.240
 of more thank yous and yeah,

00:40:52.240 --> 00:41:00.980
 thank you. I'm pleased and I will publish stuff like if it

00:41:00.980 --> 00:41:06.320
's usable. I want to use it myself,

00:41:06.320 --> 00:41:13.410
 so if you're in luck, you can use it too. And let's see, I

00:41:13.410 --> 00:41:18.160
 think I wrap up this Q&A here and

00:41:18.160 --> 00:41:22.780
 yeah, thank you for the discussion, for your questions and

00:41:22.780 --> 00:41:27.280
 your interest and have a nice rest

00:41:27.280 --> 00:41:48.950
 of EmaxConf. Yeah, bye. I'm just going to leave the room or

00:41:48.950 --> 00:41:51.760
 microphone or go back to EmaxConf.

00:41:55.360 --> 00:41:56.480
 Sounds good. Thanks again.

00:41:56.480 --> 00:42:00.320
 Ah, you're still there.

00:42:00.320 --> 00:42:03.760
 Hey, yeah, I just got back for a second.

00:42:03.760 --> 00:42:05.380
 Okay.

00:42:05.380 --> 00:42:08.960
 Yeah, just wanted to say thanks for the great talk and I'll

00:42:08.960 --> 00:42:10.720
 definitely be watching it and the Q&A.

00:42:10.720 --> 00:42:13.280
 And yeah, it's very exciting stuff.

00:42:13.280 --> 00:42:17.350
 Yeah, thank you. I got the feedback now. It's exciting. I

00:42:17.350 --> 00:42:20.400
 think so too. So yeah,

00:42:20.400 --> 00:42:24.160
 have a nice time at EmaxConf and see you next time. Bye.

00:42:24.160 --> 00:42:27.920
 Thank you. You as well. See you around. Bye.

00:42:27.920 --> 00:42:28.420
 Bye.

00:42:30.420 --> 00:42:30.420


00:42:30.420 --> 00:42:30.920
 Bye.

00:42:32.920 --> 00:42:32.920


00:42:32.920 --> 00:42:33.420
 Bye.

00:42:35.420 --> 00:42:35.420


00:42:35.420 --> 00:42:35.920
 Bye.

00:42:37.920 --> 00:42:37.920


00:42:37.920 --> 00:42:38.420
 Bye.

00:42:38.420 --> 00:42:46.420
 Bye.