diff options
author | Pekka Paalanen <ppaalanen@gmail.com> | 2012-10-24 09:43:10 +0300 |
---|---|---|
committer | Kristian Høgsberg <krh@bitplanet.net> | 2012-10-25 15:00:42 -0400 |
commit | 16b41e442ba42824f7b7bca2208efa8e0572492e (patch) | |
tree | b782285b94da6dfb9d71210b3c214b2e2d659fd6 /notes.txt | |
parent | 9249f93057be9996f8e7e5571228549783984844 (diff) |
Add informal notes file
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.
Feel free to add stuff.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Diffstat (limited to 'notes.txt')
-rw-r--r-- | notes.txt | 77 |
1 files changed, 77 insertions, 0 deletions
diff --git a/notes.txt b/notes.txt new file mode 100644 index 00000000..e49052b8 --- /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 <ppaalanen@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. + +----------------------------------------------------------------------- |