summaryrefslogtreecommitdiffstats
path: root/2022/captions/emacsconf-2022-wayland--emacs-should-become-a-wayland-compositor--michael-bauer--answers.vtt
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--2022/captions/emacsconf-2022-wayland--emacs-should-become-a-wayland-compositor--michael-bauer--answers.vtt2153
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.
+