On Mon, 29 Jul 2013 09:59:06 +0200, Silvan Jegen <s.jegen_AT_gmail.com> wrote:
> I am very interested in st (as well as other suckless projects)
> on weston/wayland as well.
>
> The wayland protocol seems to be very concise and it certainly does not
> come with all of the legacy baggage of X. That said, I noticed that the
> wayland port of the st code is around 70 lines longer than the X
> version[1]. I have not investigated way that is though.
It's mostly because of the many event handlers. In Wayland, you don't
have to register listeners for objects, but if you do, you have to
implement all of it's events. Mostly this is okay, but in a few places,
there were some events that I didn't use, like the drag and drop
facilities in wl_data_device. Also, Wayland uses separate events for
button/key press/release as well as axis (which required a new axis
binding shortcut list in config.h and handling in st.c).
These little changes add up (function prototypes as well as
definitions), which account for the difference in code size. However,
nearly all of this is cosmetic and doesn't really affect the code's
complexity.
> As far as I know dwm would have to be ported as a wayland-compositor
> (which does not do any composing). Does anyone know of a
> dwm-port/suckless-compositor for the wayland protocol that is still
> being actively developed?
Making dwm act as a Wayland shell (what Wayland calls a window manager),
wouldn't be too difficult. Many of the X11 related bits correspond
fairly closely to wl_shell bits, and the ones that don't probably aren't
even necessary under Wayland.
However, the compositor part is tricky. The easiest method would be to
make dwm a shell plugin for Weston. I don't like this approach because
Weston seems to be focusing on a more "modern" desktop features like
animation, transparency, window decorations, etc. I also dislike the
idea of dwm being loaded as a plugin.
I don't think that implementing a compositor from scratch (which would
do nothing more than blit the windows onto your screen, and maybe draw
some borders) is out of the question. I'm estimating that it could be
done in ~4000 lines (maybe more, maybe less). The question in this
scenario is where does the window manager fit in? I don't like the idea
of the window manager being in the same project as the compositor, as
they do two different jobs and other window managers should be able to
make use of it as well.
However, there has to be some implementation of wl_shell on the
compositor side. One solution would be to make a protocol extension
(which are really easy to do) and use it to communicate with a separate
window manager process. This would be similar to how an X window manager
works, but it would require implementing a wl_shell that kind of acts as
a proxy. Another option would be to make the compositor into a library
that a window manager can link with. The wl_shell implementation would
be more direct but then we would have to deal with giving the window
manager/compositor special privileges (Weston does this by using a suid
launcher which does stuff like open input devices and manage drm master
through a socket pair). Another problem is that we would have a single
program which does quite a lot of stuff.
I'd love to hear other people's opinions on this topic.
--
Michael Forney <mforney_AT_mforney.org>
Received on Mon Jul 29 2013 - 12:08:44 CEST