On Wed, Oct 24, 2012 at 09:43:10AM +0300, Pekka Paalanen wrote: > By request on the wayland-devel mailing list, we could start collecting > useful writings here. > > However, this is not meant to be a substitute to proper documentation, > though I understand it may very well become one. Better than nothing, I > guess, and hopefully helps in writing real documentation.
I suppose we can do this, but it becomes hard to manage pretty fast. Ideally we'd work this into the documentation instead. Over time a lot of small snippets like this becomes hard to search or make sense of. This and the previous 5 patches committed. Kristian > Feel free to add stuff. > > Signed-off-by: Pekka Paalanen <ppaala...@gmail.com> > --- > notes.txt | 77 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 77 insertions(+), 0 deletions(-) > create mode 100644 notes.txt > > diff --git a/notes.txt b/notes.txt > new file mode 100644 > index 0000000..e49052b > --- /dev/null > +++ b/notes.txt > @@ -0,0 +1,77 @@ > +This file is a collection of informal notes, with references to where > +they were originally written. Each note should have a source and date > +mentioned. Let's keep these in date order, newest first. > + > + > + > +----------------------------------------------------------------------- > +2012-10-23; Pekka Paalanen <ppaala...@gmail.com> > +http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html > + > +For anyone wanting to port or write their own window manager to Wayland: > + > +Most likely you have a desktop window manager. A quick way to get > +started, is to fork Weston's desktop-shell plugin and start hacking it. > +Qt could be another good choice, but I am not familiar with it. > + > +You also need to understand some concepts. I'm repeating things I wrote > +to the wayland-devel list earlier, a little rephrased. > + > +We need to distinguish three different things here (towards Wayland > +clients): > + > +- compositors (servers) > + All Wayland compositors are indistinguishable by definition, > + since they are Wayland compositors. They only differ in the > + global interfaces they advertise, and for general purpose > + compositors, we should aim to support the same minimum set of > + globals everywhere. For instance, all desktop compositors > + should implement wl_shell. In X, this component corresponds to > + the X server with a built-in compositing manager. > + > +- shells > + This is a new concept compared to an X stack. A shell defines > + how a user and applications interact. The most familiar is a > + desktop (environment). If KDE, Gnome, and XFCE are desktop > + environments, they all fall under the *same* shell: the desktop > + shell. You can have applications in windows, several visible at > + the same time, you have keyboards and mice, etc. > + > + An example of something that is not a desktop shell > + could be a TV user interface. TV is profoundly different: > + usually no mouse, no keyboard, but you have a remote control > + with some buttons. Freely floating windows probably do not make > + sense. You may have picture-in-picture, but usually not several > + applications showing at once. Most importantly, trying to run > + desktop applications here does not work due to the > + incompatible application and user interface paradigms. > + > + On protocol level, a shell is the public shell interface(s), > + currently for desktop it is the wl_shell. > + > +- "window managers" > + The X Window Managers correspond to different wl_shell > + implementations, not different shells, since they pratically > + all deal with a desktop environment. You also want all desktop > + applications to work with all window managers, so you need to > + implement wl_shell anyway. > + > +I understand there could be special purpose X Window Managers, that > +would better correspond to their own shells. These window managers > +might not implement e.g. EWMH by the spec. > + > +When you implement your own window manager, you want to keep the public > +desktop shell interface (wl_shell). You can offer new public > +interfaces, too, but keep in mind, that someone needs to make > +applications use them. > + > +In Weston, a shell implementation has two parts: a weston plugin, and a > +special client. For desktop shell (wl_shell) these are src/shell.c and > +clients/desktop-shell.c. The is also a private protocol extension that > +these two can explicitly communicate with. > + > +The plugin does window management, and the client does most of user > +interaction: draw backgrounds, panels, buttons, lock screen dialog, > +basically everything that is on screen. > + > +----------------------------------------------------------------------- > -- > 1.7.8.6 > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
