<div>Kristian,</div>
<div> </div>
<div>What do you have in mind as a real documentation? Are you thinking of a 100+ pages user manual? If so, I can envision the following problems with this route:</div>
<div> </div>
<div>(1) Your developers' time is a precious resource. Someone in your team will have to stop development work to write it.</div>
<div>(2) The longer the documentation, the fewer people will actually have time to read it.</div>
<div>(3) Wayland protocol is still evolving, so the big documentation will quickly become outdated.</div>
<div> </div>
<div>I don't mean to tell anyone what to do and how to do it. I'm just thinking of more useful alternatives: </div>
<div> </div>
<div>Would it actually be better to host a wiki on <a href="http://www.freedesktop.org/wiki/">http://www.freedesktop.org/wiki/</a> and populate it with short articles like the one posted by Pekka? When an article becomes outdated it can simply be deleted. And as new additions are made (tablet shell, android, multi-threading, debugging strategies etc) developers can simply add a small article to describe the intended protocol or client usage while it is still fresh in their memory. It seems like it will be easier on developers and signal-to-noise ratio of such articles is much higher than lengthy user guides.</div>
<div> </div>
<div>There are of course downsides to the wiki: information may be spread around. But then again, it is easier to assemble a full user guide out of these articles than it is to write it all from scratch.</div>
<div> </div>
<div>Nick</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div class="gmail_quote">On Thu, Oct 25, 2012 at 12:02 PM, Kristian Høgsberg <span dir="ltr"><<a href="mailto:hoegsberg@gmail.com" target="_blank">hoegsberg@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">On Wed, Oct 24, 2012 at 09:43:10AM +0300, Pekka Paalanen wrote:<br>> By request on the wayland-devel mailing list, we could start collecting<br>
> useful writings here.<br>><br>> However, this is not meant to be a substitute to proper documentation,<br>> though I understand it may very well become one. Better than nothing, I<br>> guess, and hopefully helps in writing real documentation.<br>
<br>I suppose we can do this, but it becomes hard to manage pretty fast.<br>Ideally we'd work this into the documentation instead. Over time a<br>lot of small snippets like this becomes hard to search or make sense of.<br>
<br>This and the previous 5 patches committed.<br><br>Kristian<br><br>> Feel free to add stuff.<br>><br>> Signed-off-by: Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>><br>> ---<br>
> notes.txt | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>> 1 files changed, 77 insertions(+), 0 deletions(-)<br>> create mode 100644 notes.txt<br>><br>> diff --git a/notes.txt b/notes.txt<br>
> new file mode 100644<br>> index 0000000..e49052b<br>> --- /dev/null<br>> +++ b/notes.txt<br>> @@ -0,0 +1,77 @@<br>> +This file is a collection of informal notes, with references to where<br>> +they were originally written. Each note should have a source and date<br>
> +mentioned. Let's keep these in date order, newest first.<br>> +<br>> +<br>> +<br>> +-----------------------------------------------------------------------<br>> +2012-10-23; Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>><br>
> +<a href="http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html</a><br>> +<br>> +For anyone wanting to port or write their own window manager to Wayland:<br>
> +<br>> +Most likely you have a desktop window manager. A quick way to get<br>> +started, is to fork Weston's desktop-shell plugin and start hacking it.<br>> +Qt could be another good choice, but I am not familiar with it.<br>
> +<br>> +You also need to understand some concepts. I'm repeating things I wrote<br>> +to the wayland-devel list earlier, a little rephrased.<br>> +<br>> +We need to distinguish three different things here (towards Wayland<br>
> +clients):<br>> +<br>> +- compositors (servers)<br>> + All Wayland compositors are indistinguishable by definition,<br>> + since they are Wayland compositors. They only differ in the<br>> + global interfaces they advertise, and for general purpose<br>
> + compositors, we should aim to support the same minimum set of<br>> + globals everywhere. For instance, all desktop compositors<br>> + should implement wl_shell. In X, this component corresponds to<br>
> + the X server with a built-in compositing manager.<br>> +<br>> +- shells<br>> + This is a new concept compared to an X stack. A shell defines<br>> + how a user and applications interact. The most familiar is a<br>
> + desktop (environment). If KDE, Gnome, and XFCE are desktop<br>> + environments, they all fall under the *same* shell: the desktop<br>> + shell. You can have applications in windows, several visible at<br>
> + the same time, you have keyboards and mice, etc.<br>> +<br>> + An example of something that is not a desktop shell<br>> + could be a TV user interface. TV is profoundly different:<br>> + usually no mouse, no keyboard, but you have a remote control<br>
> + with some buttons. Freely floating windows probably do not make<br>> + sense. You may have picture-in-picture, but usually not several<br>> + applications showing at once. Most importantly, trying to run<br>
> + desktop applications here does not work due to the<br>> + incompatible application and user interface paradigms.<br>> +<br>> + On protocol level, a shell is the public shell interface(s),<br>> + currently for desktop it is the wl_shell.<br>
> +<br>> +- "window managers"<br>> + The X Window Managers correspond to different wl_shell<br>> + implementations, not different shells, since they pratically<br>> + all deal with a desktop environment. You also want all desktop<br>
> + applications to work with all window managers, so you need to<br>> + implement wl_shell anyway.<br>> +<br>> +I understand there could be special purpose X Window Managers, that<br>> +would better correspond to their own shells. These window managers<br>
> +might not implement e.g. EWMH by the spec.<br>> +<br>> +When you implement your own window manager, you want to keep the public<br>> +desktop shell interface (wl_shell). You can offer new public<br>> +interfaces, too, but keep in mind, that someone needs to make<br>
> +applications use them.<br>> +<br>> +In Weston, a shell implementation has two parts: a weston plugin, and a<br>> +special client. For desktop shell (wl_shell) these are src/shell.c and<br>> +clients/desktop-shell.c. The is also a private protocol extension that<br>
> +these two can explicitly communicate with.<br>> +<br>> +The plugin does window management, and the client does most of user<br>> +interaction: draw backgrounds, panels, buttons, lock screen dialog,<br>> +basically everything that is on screen.<br>
> +<br>> +-----------------------------------------------------------------------<br>> --<br>> 1.7.8.6<br>><br>_______________________________________________<br>wayland-devel mailing list<br><a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br></blockquote></div><br>