notes.txt

   1 This file is a collection of informal notes, with references to where
   2 they were originally written. Each note should have a source and date
   3 mentioned. Let's keep these in date order, newest first.
   4
   5
   6
   7 -----------------------------------------------------------------------
   8 2015-04-14; Pekka Paalanen <ppaalanen@gmail.com>
   9 http://lists.freedesktop.org/archives/wayland-devel/2015-April/021309.html
  10
  11 Never destroy weston_views or weston_surfaces from animation hooks.
  12 Never destroy weston_views from weston_view signals.
  13
  14 Basically, never manipulate a list while transversing it.
  15
  16
  17 -----------------------------------------------------------------------
  18 2012-10-23; Pekka Paalanen <ppaalanen@gmail.com>
  19 http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html
  20
  21 For anyone wanting to port or write their own window manager to Wayland:
  22
  23 Most likely you have a desktop window manager. A quick way to get
  24 started, is to fork Weston's desktop-shell plugin and start hacking it.
  25 Qt could be another good choice, but I am not familiar with it.
  26
  27 You also need to understand some concepts. I'm repeating things I wrote
  28 to the wayland-devel list earlier, a little rephrased.
  29
  30 We need to distinguish three different things here (towards Wayland
  31 clients):
  32
  33 - compositors (servers)
  34         All Wayland compositors are indistinguishable by definition,
  35         since they are Wayland compositors. They only differ in the
  36         global interfaces they advertise, and for general purpose
  37         compositors, we should aim to support the same minimum set of
  38         globals everywhere. For instance, all desktop compositors
  39         should implement wl_shell. In X, this component corresponds to
  40         the X server with a built-in compositing manager.
  41
  42 - shells
  43         This is a new concept compared to an X stack. A shell defines
  44         how a user and applications interact. The most familiar is a
  45         desktop (environment). If KDE, Gnome, and XFCE are desktop
  46         environments, they all fall under the *same* shell: the desktop
  47         shell. You can have applications in windows, several visible at
  48         the same time, you have keyboards and mice, etc.
  49
  50         An example of something that is not a desktop shell
  51         could be a TV user interface. TV is profoundly different:
  52         usually no mouse, no keyboard, but you have a remote control
  53         with some buttons. Freely floating windows probably do not make
  54         sense. You may have picture-in-picture, but usually not several
  55         applications showing at once. Most importantly, trying to run
  56         desktop applications here does not work due to the
  57         incompatible application and user interface paradigms.
  58
  59         On protocol level, a shell is the public shell interface(s),
  60         currently for desktop it is the wl_shell.
  61
  62 - "window managers"
  63         The X Window Managers correspond to different wl_shell
  64         implementations, not different shells, since they practically
  65         all deal with a desktop environment. You also want all desktop
  66         applications to work with all window managers, so you need to
  67         implement wl_shell anyway.
  68
  69 I understand there could be special purpose X Window Managers, that
  70 would better correspond to their own shells. These window managers
  71 might not implement e.g. EWMH by the spec.
  72
  73 When you implement your own window manager, you want to keep the public
  74 desktop shell interface (wl_shell). You can offer new public
  75 interfaces, too, but keep in mind, that someone needs to make
  76 applications use them.
  77
  78 In Weston, a shell implementation has two parts: a weston plugin, and a
  79 special client. For desktop shell (wl_shell) these are src/shell.c and
  80 clients/desktop-shell.c. The is also a private protocol extension that
  81 these two can explicitly communicate with.
  82
  83 The plugin does window management, and the client does most of user
  84 interaction: draw backgrounds, panels, buttons, lock screen dialog,
  85 basically everything that is on screen.
  86
  87 -----------------------------------------------------------------------