diff options
Diffstat (limited to '2022/captions/emacsconf-2022-wayland--emacs-should-become-a-wayland-compositor--michael-bauer--answers.vtt')
| -rw-r--r-- | 2022/captions/emacsconf-2022-wayland--emacs-should-become-a-wayland-compositor--michael-bauer--answers.vtt | 2153 |
1 files changed, 2153 insertions, 0 deletions
diff --git a/2022/captions/emacsconf-2022-wayland--emacs-should-become-a-wayland-compositor--michael-bauer--answers.vtt b/2022/captions/emacsconf-2022-wayland--emacs-should-become-a-wayland-compositor--michael-bauer--answers.vtt new file mode 100644 index 00000000..87f60bd6 --- /dev/null +++ b/2022/captions/emacsconf-2022-wayland--emacs-should-become-a-wayland-compositor--michael-bauer--answers.vtt @@ -0,0 +1,2153 @@ +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. + |