On Mon, Jul 29, 2013 at 03:08:44AM -0700, Michael Forney wrote:
> 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.
First of all, thanks a lot for these explanations!
> > 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.
So the reason you would not want dwm to be a shell plugin for Weston is
that Weston is too focused on fancy modern features, correct?
> 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.
It sounds to me like implementing a simple blitting compositor from
scratch would be useful not only for the suckless projects, but other
people not caring about those "modern" compositing features you
mentioned as well.
If there was such a simple blitting compositor, one could then write dwm
as a shell plugin for it. That way one could retain some modularity while
not having to use any of these modern features of Weston.
> 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.
Implementing a proxy wl_shell for this hypothetical blitting compositor
and having dwm as a separate process communicating with it would be
another possible approach.
Please note that I have no idea how difficult it would be to implement
a blitting wayland compositor in ~4000 lines of code.
- application/pgp-signature attachment: stored
Received on Mon Jul 29 2013 - 12:47:49 CEST