going to start recording. All right. Thanks, Michael, for
the great talk. So
the Q&A is live now. Folks can ask questions on IRC or the
pad. And then
at some later point, we'll also open up this PDB room
itself for people to join
and ask their questions here if they want. Michael, take it
away.
Okay, I will start with the first question of etherpad is
are you using
this as it as a replacement of x ex WM? No, not yet. But I
'm planning to. I'm a
I use x WM since many years like for my main computing
environment with Emacs.
And I would love to have a replacement and Wayland. I'm not
actually that sure
if that needed. But I plan on using it. It's not finished.
So is this testable?
Yes, it is testable. I have gonna provide you the code. At
the end of the
video, there was a link to my site, but there's no site yet
. I bought this URL a
year ago, and that's a good reason to put something on
there. So wait a few
days and you can download a git repository. At least that's
the plan. And
then you can test it. Input handling is still missing, as I
said. Yes, that makes
it a bit rough. So the input is only guided by where the
mouse pointer is. And
it's missing in the C part in the C server part. But if
this is in there, I
think you can use it as a replacement. So it's testable,
and it's not a
replacement yet. Have you considered contributing to Emacs
cores? The next
question? Yes. Is it a general question? If I would like to
do that? Yeah, I got
quite a lot into Emacs core in the last year because I did
language work with
Lisp and really nerded out and got to know the core. So I
like it. Why not? If
it's a more specific question, if I would like to
contribute the Wayland
support to Emacs core, then I'm not that sure if it belongs
there. Like at first,
I thought, of course, you have to put it in the core. It's
C. It has to work
together. But after I looked into it a little bit more, how
to do a Wayland
compositor with Emacs, I found out, okay, there's this Way
land protocol and
all the programs that are working together in a Wayland
desktop, they talk
in this protocol. And when I got Emacs to talk with the Way
land protocol, it
was solved. And that is in the library, because it's an
asynchronous process,
like a network connection. And Emacs has an event loop that
listens to
messages on the network. So it's integrated into the Emacs
core. You
don't have to do anything more. But where it gets
interesting, again, is this
idea I had, maybe we could use it for more in Emacs. Emacs
is fundamentally
about drawing buffers to a screen and not fundamentally.
But the part that's
not a Lisp machine, the graphical part, it's drawing buff
ers to a screen and you
have to composite these buffers somehow. And now we're
using different desktop
toolkits like GTK on the Linux. And maybe we don't have to,
we can just draw
pixel buffers, like draw into a pixel buffer. Like, I don't
know, what do we
use for rendering? I forgot, Cairo or something. And this
could just write
into a pixel buffer. So now we arranged, and Emacs is
already a window manager.
So it's not that difficult to implement a window manager
with Emacs because Emacs
is a window manager, pretty good one, I think. And no, I
just lost a little bit
more train of thought. But so far to contributing to the
core and we could do
more with it. So next question.
- One thing, Michael, quickly. Sorry. Yeah, it would be
great if you could also
repeat the questions for the stream before you answer them.
That would be
awesome.
- I will do that.
- Thank you.
Question. Is this valent compositor in Emacs? What
different with XReparent in
X11? Okay, this is a little bit difficult for me to
understand, but I answered
anyway. So first, is this a valent compositor in Emacs? I
would say no,
because the Emacs doesn't do the valent compositoring. I
first planned to do it
like this, but it doesn't work out like this because you
have to handle file
descriptors and Emacs can't handle file descriptors except
you go down to the C
part. So no, it's not. It's a C, a WL roots valent compos
itor that talks to
Emacs and Emacs is, it's just like a helper compositor. Em
acs says where to
put the windows. It's the window manager. And in the future
, where to put the
inputs so that you can insert Emacs into the input stream
like XWM does it. Okay,
then what different with XReparent in X11? I don't actually
know what XReparent
is, so I'm sorry. I have to skip this one. How would
multiple monitors be
handled? Separate frames? Yes, separate frames. This is
already testable. It's
implemented. As soon as a new monitor crops up, the Emacs
is, the valent
protocol informs about a new output event and Emacs then
pops up a new frame
on this output. And depending on how usable you want to
have it, you can just,
there could be a menu like where do you want the output? Do
you want to have a
screen on it or something like that? And then you have
output handling. Output
handling is already working. So separate frames, one per
output because that's
the Emacs analog. You have windows, you have frames, frames
are like monitors.
And the special thing about valent outputs is they don't
have to be a whole
monitor or hardware device. They can also be like a normal
frame. Next question
is, could you make it so you can restart Emacs without
logging out or switch to
non-Emacs buffer while Emacs is blocking? These are the
biggest issues with XWM.
While Emacs is blocking. Okay, I have to think about this a
little bit
because right now I have a problem with restarting and the
code I wrote. Emacs
starts the valent server and then starts to talk to it, the
server to Emacs. And
as soon as the server terminates, Emacs terminates. Because
GTK has this feature
and it's a bug since several years and they know it, but
apparently it's a
feature, not a bug. So as soon as a valent GTK window
terminates, it terminates
its process. That means if there's an Emacs frame on valent
and the frame is
powered by GTK as Emacs currently does it, valent termin
ates the frame, Emacs
gets terminated, whole thing is terminated. Well, normally
you would like
something that like Emacs terminal frame, and then you pop
open valent buffer
or something like that. And it's just a long running Emacs
session, but that's
a blocker right now and it's GTK's fault. But we already
know the other
bug we have since years. And so I don't think this one is
resolved either.
So what does mean or switch to non-Emacs buffers while Em
acs is blocking? No,
you can't. Okay. Now you can't do this because Emacs does
the window managing
as in EXWM. So there's a new window or you want to switch a
window. So it has
to go through Emacs. Emacs gets a request for new window or
Emacs just says layout
this window at this point. And if Emacs as it's single
threaded is blocked, it
can't issue this layout request. So yeah, that's not going
to work out as long
as Emacs is just single threaded. Next question. Did this
project can implement
mirror of buffer for Emacs different window? Okay. I think
I got this question.
Can you, okay. In Emacs normally you know how buffers work.
Like you have one
buffer, you split it, you have two buffers, but it's the
same buffer. Then you can
take one of the buffers and look at another place in this
buffer. You can't do
this with Emacs buffers, but you can't do it like an EXWM.
You can't do it with
the X windows because there's only one view on the X
windows. So now the special
thing with Valent, you can have multiple views on the same
window. And when I got
to implement this idea, I was, yeah, of course I'm going to
do multiple views,
same window as Emacs does it. And I had it implemented. And
then I found out, no,
this is not going to work. Because a window has always one
size. Like you can't,
if you have a video open, you can't just tell it, make it
this size. Or if you have
a web browser open and you can't have different sizes. So
it's in principle, it's
comfortable with the Emacs model. Like the normal desktop
model doesn't work with Emacs. So
no, this still doesn't work. You can do a hack. I tried it.
You have like one big
window that you have other windows and you scale them or
you crop them, but this isn't
well supported in WL roots. And also it doesn't make a lot
of sense actually. So I scrapped it
and there's just one view. Okay. So just one view because
it doesn't make a lot of sense to have
multiple views. How does this next question, how does the
single threaded, threaded affects
the project? Yeah. And so far as it does affect any Emacs
package, like it's not a special
problem, not a, not a actual problem. Like the only, only,
um, um,
there's just one thing where Emacs could block, uh, the
other windows. It's when the other window
requests a layout, like there's a new program that opened a
window or another window opened
and Emacs is blocking and can't service this new surface
request. So you won't see anything,
but except from that, um, if you see the window Emacs hangs
like with the EXWVM, you just can use
the other program because it's not coupled to Emacs in any
significant way.
Um, and the good thing is, and that's the short side remark
. If you want to go further than our
single threaded thing, it's like, I think we, we have a
talk somewhere in this conference, like,
um, how Emacs was always async and is it, is async and Em
acs is async. Well, we have async
processes. We have callbacks, we have network processes we
can use asynchronously. And I think
that's the way forward for Emacs to don't be blocking, like
have worker threads, something
like this and have a main thing because it's one big muddle
of muddle of code. I don't think you
can just separate it. So, but we could lean more into these
helpers and workers like Node.js does
it or something like that. So next question is this
technology. I have a short matter question.
Do I have to stop or can I answer all the questions? Um,
yeah, I think we can go on for now.
And, um, the BBB room is also open for anyone who does want
to join here to ask questions directly,
um, in case the stream moves on. But I think this is our
last talk on the Dev track before the launch
break. So yeah, you should be good. Ah, nice. I don't need
a lunch break because, uh, uh,
in Europe it's already like the next meal. Right. So, um,
next question is this technology
need right? Valence server. Can it works with GNOME 3?
Actually, yes, it needs to write a
valence server because valence needs a valence server. And,
uh, just for you, what does the
server actually do? The server does, um, for example, it is
the compositor. The valence
compositor is part of the valence compositor. It's like
difficult naming they had there.
And it does a merging of, of windows. You have, um, you
have an application and it draws a window.
So you give it a pixel buffer, the application draws in
this pixel buffer, and then you put it
on the screen and compositor this other surfaces that are
on the screen. And, um, you have to look
into the frame rate you want to have and stuff like that.
So it's really low level stuff. It's,
it's, um, that's the thing the valence compositor does. And
it does input handling like lip input,
and then it receives something and routes it to this
surface of that surface, or I think shell
it's called. It's a shell that reserves the input. Okay.
Can it work with GNOME 3? Yes,
maybe. I don't know how open they are and if you can
integrate it, but I don't think that's,
that's a good direction because what do you want to build?
So, ah, just one thing since Emacs can
talk valence and is a normal valence client with the
library I wrote, it can take, can talk to any
other valence program and maybe you can do something useful
with GNOME 3 and Emacs as a
valence client. Like you can automate parts of your desktop
or something like that. Um, yeah,
that would be a possibility. Good. I'm going now to the
next question that is, could there be an
Emacs valence server and just connect with Emacs client?
Cool. I named my thing Emacs valence
server. So there is already an Emacs valence server. Um,
connect with Emacs client.
I don't actually get the question, but I think, um, yes, of
course you have an Emacs running.
It doesn't have to be an Emacs valence server because Emacs
is multi-display
and then you can just pop open the windows in valence or
something like this. Next question is
when you share your code, could you provide the equivalent
of an X session script for those who
are on XWM and want to test? Yes, I can, because it's my
goal is to have it run like this for
myself. But when I share the code in the coming days, as I
'm planning, no, you won't run it like
this because it's not that polished yet. So a startup is a
little bit more involved and I
haven't researched all the ways you can make it polished,
but it's on the roadmap. So stay tuned.
The next question is, I have a demo to show this Emacs val
ence compositor,
even if buggy now, just curious. Yes, there is a demo. Like
you just watched one in the video. It
was the compositor running. It did the compositing of the
video I made. And the other demo is the
code I'm planning to release. The code right now is working
, but there's some documentation also,
but it's not finished. So have fun digging in there, but
don't expect anything like hyper
polished or something like this. More, yeah, I'm looking
for feedback and ideas and where to take
this thing. Now we're going to get to buffer mirroring. So
next question is, so the current
limitation is that buffer mirroring doesn't respect
different widths or heights. Yeah,
the limitation is fundamentally if you have a normal
desktop window, look at your browser
or your video player, just watching me, you are just
watching me. It just has one size. You can't
say, please make yourself this size and this size and show
me two different parts of your site or
that doesn't work. It's not thought like this. So you can
hack something up that you have like
a big window and then you show a little crop part of it and
another buffer. This does actually work,
but just a little site or like if you want to do something
like this, be prepared. WL roots doesn't,
okay. So a Wayland server or compositor has to do its own
compositing. That means it has to
composite the different buffers or pixel buffer it has in
one pixel buffer and put it on the output.
That means you have to do that yourself. And there's a
helper to do this in WL roots.
This is WLR scene as it's called. And it does this for you.
You build a scene tree and does
damage tracking so it doesn't repaint everything. It saves
battery and it's a lot of work to do this
and it's ready there. But what is missing in this helper is
cropping and resizing. So right now you
can't crop and you can't resize. And I would say this is
the main blocker for using the thing I
built, Wayland compositor is you can't crop windows. And if
you, maybe you use MP4 like the
video player, it doesn't respect what you tell it, what the
size it should get. It just, it keeps its
aspect ratio and then just respects and either width or
height, but not both if they don't fit.
So you want to fit it in a buffer and then it's stay, it's
overflows the buffer a little bit. You
can see it in the talk video. In my talk, I posted like the
little camera picture of me is not always
there where it should be. It's over the mode line or
something like that. And yeah, there needs to
be some cropping. XWVM does cropping. It crops. You can try
it out. If someone of you is a XWM
user, he can do a full screen video MP4 video, and then
just split right. And then you'll see
just half the video screen because it's no cropped, but the
video player in the background
still sends the full screen. Okay. So much for this topic.
Ah, okay. And if you want to do cropping, you have to do
your own compositor. I asked the real W
WL roots. Sorry. That's this W is complicated for me. I
asked the WL roots developers on their IRC
channel and they told me, yes, we wanted to have this. We
have an issue open, but it's not
implemented and you have to do it yourself. And yes,
whoever wants us has to do it himself. And
that's a lot of work in C. Okay. I'll jump in quickly at
one thing. Yeah. I think we were about
like two minutes break, sorry, two minutes away from our
lunch break. At which point I think the
stream will be moving on or will be stopped, but this BQB
room will be open. So yeah, Michael and
anyone else who is participating in the Q&A, you're more
than welcome to stay here and continue the
question and answer. Okay. Thank you for this announcement.
Yeah. I would like to keep answering
questions and maybe yeah, until there's no more interest or
I am hungry too, but I don't need a
lunch as I already. Yep. Okay. Sounds great. Yep. So yeah,
the stream will probably be cut off in
about a minute or so, but yeah, this room will be open and
you and others will be able to stay here
and keep asking and answering questions. Okay. Thanks.
Thank you. Then let's go on to the next
question. I just scrolled. I forgot my place. Okay. Could
you use some of the packages with
other Wayland compositors? Probably not all of it's way KDE
, Rivergnome. Yes, you can. And thank
you for this idea because I already, I didn't think of this
before. You can use it because you
can talk to them. Like you can talk to Wayland protocols.
You can have a look at them. There's
like the core protocol of Wayland is in the core repository
of the Wayland project. And there's a
Wayland protocols repository. They have like three tier
staging, experimental and stable,
almost nothing in Wayland is stable. So be prepared for
some changes in the future, I think.
And you can talk to these protocols. They are not that
difficult, but some things are already a bit
too complicated. Like you have to take output and then to
get the actual width or something like
this, you have to request another output. And this one
talks to you and the other output says, okay,
I'm done or something like this. Some things are a little
bit difficult, but it's quite readable
and understandable and you can do scripting Sway, but I don
't have a lot of experience there because
like I'm an XWM user. I do it in Emacs. I'm staying on X. I
had Sway several years ago,
but only a short time. So I'm not that knowledgeable. The
next question is,
will Wayland support reach feature parity with XWM in the
future? Will there be other trade-offs?
No, it won't. Okay. But don't think, it's not something
usable because I don't think all the
features in the EXWM is needed. I want to work spaces as I
said in the talk, because yeah,
Emacs does work spaces and I won't do this, but I will do
everything. Like what's my plan with
this thing? It's like the two use cases I already alluded
to in the video. The first is you have a
Wayland surface and you show it inside an Emacs buffer or
an Emacs window. So you have a kind of
Wayland buffer, I'm calling it. That's the thing EXWM does.
And I think, yeah, it should reach
feature parity with it. It also has output management and
like the input handling,
there's like the simulation keys and I don't know what else
, but actually I don't have a solution
yet for the input handling. It's a thing I haven't looked
that much into. Will there be other
trade-offs? Yeah, most certainly there are always trade-
offs, but I can't tell you which.
So the next question is, what is the biggest difference
between X,
Org and Wayland that you have found? Okay, what's the
biggest difference?
Don't know actually, don't know. First of all, I'm not that
knowledgeable in X, Org. I used it,
but I have no more programs in X Window Manager. I haven't
looked a lot into it, except
WEM, I looked into the code, into Elisp code and how it
does the communication and
took inspiration of course. Yeah, big difference is you don
't have one monolithic server. Like you
have one X, Org server and in Wayland you have lots of
servers like GNOME has one, KDE has one,
then WL roots is another approach, Swae has an
implementation in WL roots and so on.
So now it's the last question I find in my path is, did you
know EAF? Yes, I know. Of course,
like I think we have a talk. We have a talk. We had talks
and I never used it. I'm sorry.
Maybe it's interesting. It's Python. I don't do a lot of
Python and
similar use case. It's like, I think it's embedded X
widgets. Please correct me if I'm wrong.
Yeah, that's all I can say to this topic. But I think like
any application framework,
you can want to do an Emacs or stuff like that will mesh
really good with Emacs compositor that
is integrated or like almost integrated in Emacs because
now you can use this to do your application
framework and paint the windows in Emacs. And I think maybe
we can come back to the reparenting
X thing, which I don't really understand. So I don't know
exactly how X does the X widgets, like
no idea. But I think we can do something similar with Way
land. Like we can just embed the little
Wayland surfaces in an Emacs buffer. And that's a thing I
wanted to get a discussion started.
Someone, yeah, maybe someone has an idea. Maybe someone is
already deep down in Emacs internals
and knows how these displays stuff works like image display
, X widget display, and so on.
And maybe this person or someone else has an idea how we
could do the Wayland surfaces.
Right now it's just Emacs receives a request for new
surface. Okay. You open a new program.
The program says to the Wayland server, "Hey, I'm here. I
want to have surface." Wayland server
gives it the surface and says to Emacs, "Hey, here's a new
surface. You can lay it out." And
Emacs then can lay it out or not, however it likes.
Normally the default path I choose is
Emacs bundles, the surface with a buffer. And if the buffer
is shown, it shows the surface.
And otherwise it's just hidden. But you can do whatever you
want with the surface. You just
have to say, please put it at this coordinate and this
width and this height. So you can put it in
a buffer and you can scroll it in a buffer. But this
integration, how to put something in a buffer
and scroll it there. I don't know how to do it. And I don't
know how to do it. It should be like
a good solution. I don't know how to do it. Maybe someone
of you has an idea. I'm finished with the
questions of the path. I haven't had a look in IRC because
yes, I was busy talking.
I can either like browse through the IRC if you want, or
maybe someone wants to say something or
have a look. Ah, thank you. I already answered the IRC
questions. So yes, I'm finished.
I still see some people in the room. Yeah. Maybe someone,
if you have an idea or wants to use it.
I don't know how fast I will have it in a usable state. It
's like,
at first I just wanted to do this presentation and show to
you the possibility. I already read
in the internet some places like Emacs, Devel, Mailindus
that was one time and other places that
other people's had the same, other person had the same
ideas. But I was thinking just to lay out
the general idea to you. And then I thought, okay, do an
experiment, show if it works. And the
experiments spun a little bit. It worked. And so I got
further and now I have an almost usable thing,
but I already spent like a month with it. So we'll take
some more time to finish.
Yeah. Thanks that you think, Gary, that you think it's, you
are happy to test it. Thank you.
I would like to have it like a little bit more flexible
than the X solutions, because
as I told you can have it nested, like you have a normal Em
acs and you can just do the embedding
and the embedded surfaces. And so in a normal Emacs and you
don't have to give Emacs the whole
desktop. So you don't have to do XWM. You can just have a
normal Emacs window and have all the goodies
and features there. Okay. Again, the code will be available
on my site. I can post you the link,
but there's nothing there yet. Oh, wait a few days. I was
thinking of doing it this weekend,
but it's EmacsConf and I want to listen to your ideas and
participate and don't do coding instead.
This is the link. I could put it on another code forge, but
I want to do something
myself instead. I have a landing page. If I put it in my
browser, it's just,
yeah, no connection possible. It's not configured. It's
just bought, wait a few days.
Okay. Short question for the room. Does anyone know someone
else working on stuff like this?
Because if, please let them know so we can team up and don
't do it twice.
I had a lot of fun with the Emacs part of the code. I like
coding in Elisp in general,
but it's not that much fun to work on the C side. It's
complex and prone to break.
So don't mind collaborating.
Why the sad face?
Yes, I know the lack of active development.
Okay. Because yeah, so no problem. You can't know anyone or
a lot of,
like, it's a good thing. So I got to start it and I wanted
to start,
you know, people quitting the XW. I don't have problems yet
. It's not that I started
implementing this because I thought, ah, it's not working
anymore. I need something new. It's like,
it's works fine. I just did it because I thought, well, why
not do something new? And because it
opens new possibilities, which weren't there before, or at
least I didn't know of them.
Okay. How could I put this? Okay. If it's ready for no, as
I will promote it. If it's
ready for normal usement, like you can just install it and
use it for an everyday driver
and have you do it. You would X session file and can just
start it up. It won't be an X session
file because that's X and that's a thing of the past and,
but something similar.
I could imagine posting, like, I don't know, he makes lists
, Reddit, something like this, but
until then, like the code I will release now, it's just
experimental and
it's for the people who want to get involved and, or want
to do their own thing with it,
use the client to automate sway or so for them. It's really
interesting.
[inaudible]
Yes, I know. Like you,
okay, this sway.el, I have to look at it, but I don't think
now is a good idea.
Maybe something useful there. Thank you, PlasmaStrike and G
argiola.
Yes, people are moving and Valent is the future. That's the
point I wanted to say. Like, I think
you can stay on X, like in the future, but it's not gonna
get that much development and
sooner or later, like there will be new features and you
won't have it in the old one and stuff
like that. And for Emacs to be viable as a window manager
in this whole computing environment, or as
I said, a Lispy Linux desktop, I think it needs to have
this Valent capability and
that's the way for it to get it.
[inaudible]
I'm just reading the IRC log and someone wrote, I was
amazed to see the video inside Emacs.
Thank you. That was meant to be amazing. Yeah, thank you.
[inaudible]
Okay, Emax could already do. I'm just reading the IRC
because I don't know what else to say right now.
[inaudible]
Yeah, it's nice to see so many people saying thank you and
at least I read it like two times now. So yeah, I'm pleased
to see this and the interest in
gender.
[inaudible]
Okay, I see there's still some people typing and it's a lot
of more thank yous and yeah,
thank you. I'm pleased and I will publish stuff like if it
's usable. I want to use it myself,
so if you're in luck, you can use it too. And let's see, I
think I wrap up this Q&A here and
yeah, thank you for the discussion, for your questions and
your interest and have a nice rest
of EmaxConf. Yeah, bye. I'm just going to leave the room or
microphone or go back to EmaxConf.
Sounds good. Thanks again.
Ah, you're still there.
Hey, yeah, I just got back for a second.
Okay.
Yeah, just wanted to say thanks for the great talk and I'll
definitely be watching it and the Q&A.
And yeah, it's very exciting stuff.
Yeah, thank you. I got the feedback now. It's exciting. I
think so too. So yeah,
have a nice time at EmaxConf and see you next time. Bye.
Thank you. You as well. See you around. Bye.
Bye.