Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On 02/23/2012 07:58 AM, Peter Hutterer wrote: Includes rudimentary styling only. Signed-off-by: Peter Hutterer --- A few things to note: - I'm not a designer - Having a html version of the protocol makes it a lot easier to read, and it certainly reveals missing bits of documentation in the protocol - the .css file is the one from wayland.freedesktop.org, someone could easily fix it to prettify the result a bit. I concur we need a prettier way to read the protocol. But what do you think about the idea of dumping the whole protocol in a separate section of main.tex instead? http://lists.freedesktop.org/archives/wayland-devel/2012-February/002168.html the protocol could be printed out there verbatim or with more descriptions instead; depends what we want. My point is, given we have already to maintain main.tex, then we should try to centralize the documentation and not have another document just hanging around. Tiago ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Thu, 23 Feb 2012 11:57:31 +0200 Tiago Vignatti wrote: > On 02/23/2012 07:58 AM, Peter Hutterer wrote: > > Includes rudimentary styling only. > > > > Signed-off-by: Peter Hutterer > > --- > > A few things to note: > > - I'm not a designer > > - Having a html version of the protocol makes it a lot easier to read, and > >it certainly reveals missing bits of documentation in the protocol IIRC there was a plan to make wayland-scanner require protocol documentation, once all protocol was documented. > > - the .css file is the one from wayland.freedesktop.org, someone could > >easily fix it to prettify the result a bit. > > I concur we need a prettier way to read the protocol. But what do you > think about the idea of dumping the whole protocol in a separate section > of main.tex instead? > > http://lists.freedesktop.org/archives/wayland-devel/2012-February/002168.html > > the protocol could be printed out there verbatim or with more > descriptions instead; depends what we want. My point is, given we have > already to maintain main.tex, then we should try to centralize the > documentation and not have another document just hanging around. Were there plans to convert documentation to docbook or something? I recall someone at least mentioning docbook once. In the XSLT approach I like the TOC with links approach, easily gives an overview of the protocol. In LaTeX you would use hyperref to achieve that. I've been using QXmlEdit with the attached style file for reading the protocol XML files. Thanks, pq wayland.style Description: Binary data ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On 23/02/12 19:57 , Tiago Vignatti wrote: On 02/23/2012 07:58 AM, Peter Hutterer wrote: Includes rudimentary styling only. Signed-off-by: Peter Hutterer --- A few things to note: - I'm not a designer - Having a html version of the protocol makes it a lot easier to read, and it certainly reveals missing bits of documentation in the protocol - the .css file is the one from wayland.freedesktop.org, someone could easily fix it to prettify the result a bit. I concur we need a prettier way to read the protocol. But what do you think about the idea of dumping the whole protocol in a separate section of main.tex instead? largely depends on what you expect the canonical source to be. shouldn't be that hard to knock up another xslt that converts the xml into latex. http://lists.freedesktop.org/archives/wayland-devel/2012-February/002168.html the protocol could be printed out there verbatim or with more descriptions instead; depends what we want. My point is, given we have already to maintain main.tex, then we should try to centralize the documentation and not have another document just hanging around. note that the xslt is just the conversion, the html would be read-only and re-generated whenever the protocol changes. I'm definitely not suggesting that the html be a source. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] shell: don't assign output for surface of type none
If map is called with a surface of type none it will call weston_surface_assign_output, even though the surface will not be mapped. --- src/shell.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/shell.c b/src/shell.c index 3d5dfd9..8628462 100644 --- a/src/shell.c +++ b/src/shell.c @@ -1427,6 +1427,7 @@ map(struct weston_shell *base, struct weston_surface *surface, do_configure = 0; break; case SHELL_SURFACE_NONE: + do_configure = 0; break; default: /* everything else just below the panel */ -- 1.7.5.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] compositor: assign output to drag surfaces
Otherwise we endup with a surface that is mapped but with outtup nil.
---
src/compositor.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index 5a424fa..97f7c3e 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1797,6 +1797,7 @@ weston_input_update_drag_surface(struct wl_input_device
*input_device,
device->drag_surface->buffer) {
wl_list_insert(weston_compositor_top(device->compositor),
&device->drag_surface->link);
+ weston_surface_assign_output(device->drag_surface);
}
if (!dx && !dy)
--
1.7.5.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC] Cursor sprites as regular surfaces
Here's an RFC for implementing the cursor sprites as regular surfaces change we have been talking about. This removes the input_device.attach request and adds two new ones: set_pointer_surface and set_hotspot. Each client can set a pointer surface that is displayed when it has pointer focus. The position of this surface will be the cursor location offset by the hotspot set by set_hotspot. For now surface transformation is ignored. surface_attach has the same behavior as with regular surfaces, i.e., sx and sy are relative to the surfaces top-left corner. The hotspot is updated though, so that the cursor position does not move. One of the changes to clients/window.c is done to test surface_attachs to a pointer surface with sx,sy != 0 and is not really necessary. This set does not implement these changes on wayland backend. It does include the two fixes I just sent to the list. Protocol changes: - Ander Conselvan de Oliveira (1): protocol: make pointer images regular surfaces protocol/wayland.xml | 27 ++- 1 files changed, 18 insertions(+), 9 deletions(-) Weston Changes: --- Ander Conselvan de Oliveira (3): shell: don't assign output for surface of type none compositor: assign output to drag surfaces compositor: implement new pointer surface protocol clients/window.c | 25 +++- src/compositor.c | 181 -- src/compositor.h | 10 +++ src/shell.c |1 + 4 files changed, 181 insertions(+), 36 deletions(-) -- 1.7.5.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] protocol: make pointer images regular surfaces
Replace the input_device.attach request with requests for setting a pointer surface and a hotspot. This surface is client specific and will be showed as the cursor sprite when one of the clients surfaces has pointer focus. --- protocol/wayland.xml | 27 ++- 1 files changed, 18 insertions(+), 9 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index a40e4b0..c72bf62 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -579,17 +579,26 @@ pointer_focus. - - - Set the pointer's image. This request only takes effect if - the pointer focus for this device is one of the requesting - clients surfaces. + + + Set the supplied client surface as the pointer surface for the + requesting client. When the pointer focus is on one of the + requesting clients surface, this pointer surface will be + displayed at the cursor location, offset by a hotspot that + may be set with the set_hotspot request. - - - - + + + + + + When this surface is displayed at the cursor location, its + position will be displaced by -x, -y. + + + + -- 1.7.5.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/4] shell: don't assign output for surface of type none
If map is called with a surface of type none it will call weston_surface_assign_output, even though the surface will not be mapped. --- src/shell.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/shell.c b/src/shell.c index 3d5dfd9..8628462 100644 --- a/src/shell.c +++ b/src/shell.c @@ -1427,6 +1427,7 @@ map(struct weston_shell *base, struct weston_surface *surface, do_configure = 0; break; case SHELL_SURFACE_NONE: + do_configure = 0; break; default: /* everything else just below the panel */ -- 1.7.5.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 3/4] compositor: assign output to drag surfaces
Otherwise we endup with a surface that is mapped but with outtup nil.
---
src/compositor.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index 5a424fa..97f7c3e 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1797,6 +1797,7 @@ weston_input_update_drag_surface(struct wl_input_device
*input_device,
device->drag_surface->buffer) {
wl_list_insert(weston_compositor_top(device->compositor),
&device->drag_surface->link);
+ weston_surface_assign_output(device->drag_surface);
}
if (!dx && !dy)
--
1.7.5.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 4/4] compositor: implement new pointer surface protocol
---
clients/window.c | 25 +++-
src/compositor.c | 180 --
src/compositor.h | 10 +++
3 files changed, 179 insertions(+), 36 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index ac26f52..e503182 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -159,6 +159,7 @@ struct input {
struct wl_input_device *input_device;
struct window *pointer_focus;
struct window *keyboard_focus;
+ struct wl_surface *pointer_surface;
uint32_t current_pointer_image;
uint32_t modifiers;
int32_t sx, sy;
@@ -1875,10 +1876,12 @@ input_set_pointer_image(struct input *input, uint32_t
time, int pointer)
struct display *display = input->display;
struct wl_buffer *buffer;
cairo_surface_t *surface;
+ int old_pointer;
if (pointer == input->current_pointer_image)
return;
+ old_pointer = input->current_pointer_image;
input->current_pointer_image = pointer;
surface = display->pointer_surfaces[pointer];
@@ -1886,9 +1889,20 @@ input_set_pointer_image(struct input *input, uint32_t
time, int pointer)
return;
buffer = display_get_buffer_for_surface(display, surface);
- wl_input_device_attach(input->input_device, time, buffer,
- pointer_images[pointer].hotspot_x,
- pointer_images[pointer].hotspot_y);
+ if (old_pointer == POINTER_UNSET) {
+ wl_input_device_set_hotspot(input->input_device,
+ pointer_images[pointer].hotspot_x,
+ pointer_images[pointer].hotspot_y);
+ wl_surface_attach(input->pointer_surface, buffer, 0, 0);
+ }
+ else {
+ int dx = pointer_images[old_pointer].hotspot_x -
+ pointer_images[pointer].hotspot_x;
+ int dy = pointer_images[old_pointer].hotspot_y -
+ pointer_images[pointer].hotspot_y;
+
+ wl_surface_attach(input->pointer_surface, buffer, dx, dy);
+ }
}
struct wl_data_device *
@@ -2650,6 +2664,11 @@ display_add_input(struct display *d, uint32_t id)
input->input_device);
wl_data_device_add_listener(input->data_device,
&data_device_listener, input);
+
+ input->current_pointer_image = POINTER_UNSET;
+ input->pointer_surface = wl_compositor_create_surface(d->compositor);
+ wl_input_device_set_pointer_surface(input->input_device,
+ input->pointer_surface);
}
static void
diff --git a/src/compositor.c b/src/compositor.c
index 97f7c3e..a84f52f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -929,6 +929,7 @@ weston_output_repaint(struct weston_output *output, int
msecs)
overlap, surface_overlap;
int32_t width, height;
+ weston_compositor_update_cursor_sprites(ec);
weston_compositor_update_drag_surfaces(ec);
width = output->current->width +
@@ -1107,15 +1108,23 @@ weston_surface_assign_output(struct weston_surface *es)
}
}
+static struct weston_pointer_surface *
+device_client_pointer_surface(struct weston_input_device *device,
+ struct wl_client *client);
+
static void
surface_attach(struct wl_client *client,
struct wl_resource *resource,
struct wl_resource *buffer_resource, int32_t sx, int32_t sy)
{
struct weston_surface *es = resource->data;
+ struct weston_input_device *device = (struct weston_input_device *)
+ es->compositor->input_device;
struct weston_shell *shell = es->compositor->shell;
struct wl_buffer *buffer;
+ struct weston_pointer_surface *ps;
+
if (!buffer_resource && !es->output)
return;
@@ -1152,6 +1161,17 @@ surface_attach(struct wl_client *client,
buffer->width, buffer->height);
}
+ ps = device_client_pointer_surface(device, client);
+ if (ps && es == ps->surface) {
+ ps->hotspot_x -= sx;
+ ps->hotspot_y -= sy;
+
+ if (ps->surface == device->sprite) {
+ device->hotspot_x = ps->hotspot_x;
+ device->hotspot_y = ps->hotspot_y;
+ }
+ }
+
weston_buffer_attach(buffer, &es->surface);
}
@@ -1666,47 +1686,74 @@ notify_touch(struct wl_input_device *device, uint32_t
time, int touch_id,
}
static void
-input_device_attach(struct wl_client *client,
- struct wl_resource *resource,
- uint32_t time,
- struct wl_resource *buffer_resource, int32_t x, int32_t y)
+pointer_surface_destroy(struct weston_pointer_surface *ps)
+{
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Thu, 2012-02-23 at 21:20 +1000, Peter Hutterer wrote: > On 23/02/12 19:57 , Tiago Vignatti wrote: > > On 02/23/2012 07:58 AM, Peter Hutterer wrote: > >> Includes rudimentary styling only. > >> > >> Signed-off-by: Peter Hutterer > >> --- > >> A few things to note: > >> - I'm not a designer > >> - Having a html version of the protocol makes it a lot easier to read, > >> and > >> it certainly reveals missing bits of documentation in the protocol > >> - the .css file is the one from wayland.freedesktop.org, someone could > >> easily fix it to prettify the result a bit. > > > > I concur we need a prettier way to read the protocol. But what do you > > think about the idea of dumping the whole protocol in a separate section > > of main.tex instead? > > largely depends on what you expect the canonical source to be. shouldn't > be that hard to knock up another xslt that converts the xml into latex. I would prefer HTML over Latex. Especially if the resulting HTML is hosted as some form of online documentation. regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Touch events
Chase Douglas wrote: The client won't see the third finger if it touches outside its window. In the wayland case, only the WM has all the info needed to determine if a touch is part of a global gesture. The WM needs to make the decision, not the client. I'm pretty certain all touch events *MUST* go to the same surface until all touches are released. Otherwise it will be quite impossible to do gestures reliably, like the user could not do them to objects near the edge of a window. If the clients can look at things first, this would allow the compositor to do things like "one finger can be used to change desktops if the underlying program does not use it". That would be bad UI design because then global gestures would fire only sometimes. Further, it would break global gestures if touches occur over a broken application. I consider it bad design that global actions are "complex" (like needing 3 fingers) or global shortcuts require lots of shift keys held down, just to avoid collisions with applications. I also think you are making up "user confusion" that does not exist in the real world to make an excuse for this. Users will find it pretty obvious if the same action that scrolls a document also scrolls the entire screen if you don't touch a document, IMHO. I think we can look at other OSes as case studies. iOS and OS X employ effective global gestures imo, and they take precedence over the application receiving touch or gesture events. I think it is pretty clear that "what other OS's do" is not always what Wayland wants to do. Most of them copied ideas from X. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Touch events
On 02/23/2012 12:22 PM, Bill Spitzak wrote: Chase Douglas wrote: The client won't see the third finger if it touches outside its window. In the wayland case, only the WM has all the info needed to determine if a touch is part of a global gesture. The WM needs to make the decision, not the client. I'm pretty certain all touch events *MUST* go to the same surface until all touches are released. Otherwise it will be quite impossible to do gestures reliably, like the user could not do them to objects near the edge of a window. No? I'm not sure what to say other than this is plainly incorrect. For a touchscreen device, the user may be interacting with two separate applications at the same time. Imagine you have your web browser open on the left side of the screen, and you have your spreadsheet open on the right side. You then want to scroll both side by side as you compare numbers. To do this, you need to send touch events to each client separately. I'm fairly certain that no window system in major use behaves as you suggest. If the clients can look at things first, this would allow the compositor to do things like "one finger can be used to change desktops if the underlying program does not use it". That would be bad UI design because then global gestures would fire only sometimes. Further, it would break global gestures if touches occur over a broken application. I consider it bad design that global actions are "complex" (like needing 3 fingers) or global shortcuts require lots of shift keys held down, just to avoid collisions with applications. My belief is that it is considered, universally (meaning >95% of people), that global gestures should behave consistently across applications, and should not be inhibited by broken applications. I also believe that 3 or more finger global gestures are not bad design, especially since the iPad uses them. Maybe individuals like yourself don't like them, but very many do. I'm not trying to start an argument about what is the best design of global gestures. However, I think it is a requirement that the window system allows for consistent global gesture behavior, and that three or more touch gestures are valid for global gestures. I also think you are making up "user confusion" that does not exist in the real world to make an excuse for this. Users will find it pretty obvious if the same action that scrolls a document also scrolls the entire screen if you don't touch a document, IMHO. How would it not be confusing if you have a global "alt-tab" gesture work when performed over your spreadsheet but not your browser? I think we can look at other OSes as case studies. iOS and OS X employ effective global gestures imo, and they take precedence over the application receiving touch or gesture events. I think it is pretty clear that "what other OS's do" is not always what Wayland wants to do. Most of them copied ideas from X. That's why I said we should look at them as case studies... -- Chase ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Thu, Feb 23, 2012 at 03:58:37PM +1000, Peter Hutterer wrote:
> Includes rudimentary styling only.
>
> Signed-off-by: Peter Hutterer
> ---
> A few things to note:
> - I'm not a designer
> - Having a html version of the protocol makes it a lot easier to read, and
> it certainly reveals missing bits of documentation in the protocol
> - the .css file is the one from wayland.freedesktop.org, someone could
> easily fix it to prettify the result a bit.
That is very nice. As part of 1.0, we need to figure out a way to
combine the protocol and the spec document into something like docbook
and make pdf and html versions. I don't think we want to stick with latex.
Anyway, for now, this is great and definitely highlights the missing
documentation. Committed, and I'll try to setup a push hook to put
the html on the web site.
thanks,
Kristian
> Makefile.am |2 +-
> configure.ac |6 +-
> protocol/Makefile.am |7 ++
> protocol/protocol.xsl | 204
> +
> protocol/wayland.css | 41 ++
> 5 files changed, 258 insertions(+), 2 deletions(-)
> create mode 100644 protocol/Makefile.am
> create mode 100644 protocol/protocol.xsl
> create mode 100644 protocol/wayland.css
>
> diff --git a/Makefile.am b/Makefile.am
> index 4461e48..016bb76 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -1,4 +1,4 @@
> -SUBDIRS = src
> +SUBDIRS = src protocol
>
> ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
>
> diff --git a/configure.ac b/configure.ac
> index a1c9d2a..fc623e8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -48,9 +48,13 @@ if test "x$enable_scanner" = "xyes"; then
> AC_SUBST(EXPAT_LIBS)
> fi
>
> +AC_PATH_PROG(XSLTPROC, xsltproc)
> +AM_CONDITIONAL([HAVE_XSLTPROC], [test $XSLTPROC != ""])
> +
> AC_CONFIG_FILES([Makefile
>wayland-scanner.m4
>src/Makefile
>src/wayland-server.pc
> - src/wayland-client.pc])
> + src/wayland-client.pc
> + protocol/Makefile])
> AC_OUTPUT
> diff --git a/protocol/Makefile.am b/protocol/Makefile.am
> new file mode 100644
> index 000..9b57441
> --- /dev/null
> +++ b/protocol/Makefile.am
> @@ -0,0 +1,7 @@
> +if HAVE_XSLTPROC
> +doc_DATA = wayland.html wayland.css
> +
> +wayland.html: wayland.xml protocol.xsl
> + $(AM_V_GEN)$(XSLTPROC) protocol.xsl wayland.xml > $@
> +
> +endif
> diff --git a/protocol/protocol.xsl b/protocol/protocol.xsl
> new file mode 100644
> index 000..b2867f0
> --- /dev/null
> +++ b/protocol/protocol.xsl
> @@ -0,0 +1,204 @@
> +
> + xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
> +
> +
> +
> +
> +
> +
> +
> +Wayland
> +
> +
> +
> +Wayland Protocol Specification
> +
> +
> +
> +
> +
> +
> +
> +
> + mode="interface_description" />
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +Table of Contents
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + Requests:
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + Events:
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + Enums:
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + #
> +
> + -
> +
> + -
> +
> +
> +
> +
> + - select="description/@summary"/>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + -
> +
> +
> +Version:
> +
> +
> +
> + Requests
> +
> +
> +
> +
> +
> +
> +
> + Events
> +
> +
> +
> +
> +
> +
> +
> + Enums
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + :: select="@name" />
> +
> + -
> +
> +
> +
> +
> + Arguments:
> +
> +
> +
> +
> +
> + Values:
> +
> +
> +
> +
> +
> +
> +
> +
> +
> diff --git a/protocol/wayland.css b/protocol/wayland.css
> new file mode 100644
> index 000..91f458a
> --- /dev/null
> +++ b/protocol/wayland.css
> @@ -0,0 +1,41 @@
> +body { padding: 0px 150px; }
> +h1 { margin: 40px 0px; color: #aaa; }
> +p { margin: 20px 0px; }
> +h1 img { vertical-align: middle; border-width: 0px; }
> +h2 { font-family: sans; color: #888; }
> +h3 { font-family: sans; color: #888; font-style: italic; }
> +a { color: #444; }
> +a:hover { color: #888; }
> +a:visited { color: #666; }
> +li { margin: 10px 0px };
> +table { border: 1px solid gray;}
> +
> +.version { font-size: small }
> +div.interface { padding: 2% }
> +
> +div.reques
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Thu, 2012-02-23 at 16:26 -0500, Kristian Hoegsberg wrote: > On Thu, Feb 23, 2012 at 03:58:37PM +1000, Peter Hutterer wrote: > > Includes rudimentary styling only. > > > > Signed-off-by: Peter Hutterer > > --- > > A few things to note: > > - I'm not a designer > > - Having a html version of the protocol makes it a lot easier to read, and > > it certainly reveals missing bits of documentation in the protocol > > - the .css file is the one from wayland.freedesktop.org, someone could > > easily fix it to prettify the result a bit. > > That is very nice. As part of 1.0, we need to figure out a way to > combine the protocol and the spec document into something like docbook > and make pdf and html versions. I don't think we want to stick with latex. Mallard comes to mind: http://projectmallard.org/ regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Thu, Feb 23, 2012 at 4:26 PM, Kristian Hoegsberg wrote:
> On Thu, Feb 23, 2012 at 03:58:37PM +1000, Peter Hutterer wrote:
>> Includes rudimentary styling only.
>>
>> Signed-off-by: Peter Hutterer
>> ---
>> A few things to note:
>> - I'm not a designer
>> - Having a html version of the protocol makes it a lot easier to read, and
>> it certainly reveals missing bits of documentation in the protocol
>> - the .css file is the one from wayland.freedesktop.org, someone could
>> easily fix it to prettify the result a bit.
>
> That is very nice. As part of 1.0, we need to figure out a way to
> combine the protocol and the spec document into something like docbook
> and make pdf and html versions. I don't think we want to stick with latex.
>
> Anyway, for now, this is great and definitely highlights the missing
> documentation. Committed, and I'll try to setup a push hook to put
> the html on the web site.
I put it here:
http://wayland.freedesktop.org/protocol.html
Kristian
> thanks,
> Kristian
>
>> Makefile.am | 2 +-
>> configure.ac | 6 +-
>> protocol/Makefile.am | 7 ++
>> protocol/protocol.xsl | 204
>> +
>> protocol/wayland.css | 41 ++
>> 5 files changed, 258 insertions(+), 2 deletions(-)
>> create mode 100644 protocol/Makefile.am
>> create mode 100644 protocol/protocol.xsl
>> create mode 100644 protocol/wayland.css
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 4461e48..016bb76 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -1,4 +1,4 @@
>> -SUBDIRS = src
>> +SUBDIRS = src protocol
>>
>> ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
>>
>> diff --git a/configure.ac b/configure.ac
>> index a1c9d2a..fc623e8 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -48,9 +48,13 @@ if test "x$enable_scanner" = "xyes"; then
>> AC_SUBST(EXPAT_LIBS)
>> fi
>>
>> +AC_PATH_PROG(XSLTPROC, xsltproc)
>> +AM_CONDITIONAL([HAVE_XSLTPROC], [test $XSLTPROC != ""])
>> +
>> AC_CONFIG_FILES([Makefile
>> wayland-scanner.m4
>> src/Makefile
>> src/wayland-server.pc
>> - src/wayland-client.pc])
>> + src/wayland-client.pc
>> + protocol/Makefile])
>> AC_OUTPUT
>> diff --git a/protocol/Makefile.am b/protocol/Makefile.am
>> new file mode 100644
>> index 000..9b57441
>> --- /dev/null
>> +++ b/protocol/Makefile.am
>> @@ -0,0 +1,7 @@
>> +if HAVE_XSLTPROC
>> +doc_DATA = wayland.html wayland.css
>> +
>> +wayland.html: wayland.xml protocol.xsl
>> + $(AM_V_GEN)$(XSLTPROC) protocol.xsl wayland.xml > $@
>> +
>> +endif
>> diff --git a/protocol/protocol.xsl b/protocol/protocol.xsl
>> new file mode 100644
>> index 000..b2867f0
>> --- /dev/null
>> +++ b/protocol/protocol.xsl
>> @@ -0,0 +1,204 @@
>> +
>> +> xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + Wayland
>> +
>> +
>> +
>> + Wayland Protocol Specification
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + > mode="interface_description" />
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + Table of Contents
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + Requests:
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + Events:
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + Enums:
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + #
>> +
>> + -
>> +
>> + -
>> +
>> +
>> +
>> +
>> + - > select="description/@summary"/>
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + -
>> +
>> +
>> + Version:
>> +
>> +
>> +
>> + Requests
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + Events
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + Enums
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + ::> select="@name" />
>> +
>> + -
>> +
>> +
>> +
>> +
>> + Arguments:
>> +
>> +
>> +
>> +
>> +
>> + Values:
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> diff --git a/protocol/wayland.css b/protocol/wayland.css
>> new file mode 100644
>> index 000..91f458a
>> --- /dev/null
>> +++ b/protocol/wayland.css
>> @@ -0,0 +1,41 @@
>> +body { padding: 0px 150px; }
>> +h1 { margin: 40px 0px; color:
Re: [PATCH] Fix pointer position clipping.
On Wed, Feb 22, 2012 at 01:57:51PM -0700, Scott Moreau wrote:
Yup, good fix, applied.
Kristian
> ---
> src/compositor.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index 5a424fa..1963322 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -1304,10 +1304,10 @@ notify_motion(struct wl_input_device *device,
> uint32_t time, int x, int y)
> weston_compositor_activity(ec);
>
> wl_list_for_each(output, &ec->output_list, link) {
> - if (output->x <= x && x <= output->x + output->current->width)
> + if (output->x <= x && x < output->x + output->current->width)
> x_valid = 1;
>
> - if (output->y <= y && y <= output->y + output->current->height)
> + if (output->y <= y && y < output->y + output->current->height)
> y_valid = 1;
>
> /* FIXME: calculate this only on output addition/deletion */
> @@ -1317,9 +1317,9 @@ notify_motion(struct wl_input_device *device, uint32_t
> time, int x, int y)
> min_y = output->y;
>
> if (output->x + output->current->width > max_x)
> - max_x = output->x + output->current->width;
> + max_x = output->x + output->current->width - 1;
> if (output->y + output->current->height > max_y)
> - max_y = output->y + output->current->height;
> + max_y = output->y + output->current->height - 1;
> }
>
> if (!x_valid) {
> --
> 1.7.4.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v4] Introduce output zoom.
On Wed, Feb 22, 2012 at 02:21:41PM -0700, Scott Moreau wrote:
> Ideally, we would want to use +Scroll binding but that will have
> to wait for axis events. For now we just use keybindings. Zoom in/out with
> Super+Up/Down.
Applied with a minor edit to really fix the code-before-declaration
thing. With your change we still end up with
weston_output_update_zoom(struct weston_output *output, int x, int y)
{
if (output->zoom.level <= 0)
return;
float ratio;
...
That is, the ratio variable is declared after the if statement.
That's what we don't want.
Anyway, enough nit-picking, it works well where, but we need to fix
the binding issue. We need to swallow the key press that triggers the
binding and we also need to swallow the corresponding key up. What
I've been thinking is that we could let the binding handler return a
value to indicate whether or not to swallow the event. The tricky
part is going to be swallowing the release event, since that may come
many key events later. We could just maintain a per-device list of
"keys that are down, and we need to swallow the release event", but
that's kinda gross. I don't really think there's a nicer way though.
And all this applies to pointer buttons as well.
Kristian
> ---
> src/compositor.c | 68
> ++
> src/compositor.h | 14 +++
> src/shell.c | 48 ++
> 3 files changed, 120 insertions(+), 10 deletions(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index 5a424fa..1566753 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -743,7 +743,7 @@ weston_surface_draw(struct weston_surface *es, struct
> weston_output *output)
> glUniform1f(es->shader->texwidth_uniform,
> (GLfloat)es->geometry.width / es->pitch);
>
> - if (es->transform.enabled)
> + if (es->transform.enabled || output->zoom.active)
> filter = GL_LINEAR;
> else
> filter = GL_NEAREST;
> @@ -979,6 +979,9 @@ weston_output_repaint(struct weston_output *output, int
> msecs)
>&total_damage, &es->transform.opaque);
> }
>
> + if (output->dirty)
> + weston_output_update_matrix(output);
> +
> output->repaint(output);
>
> pixman_region32_fini(&total_damage);
> @@ -1341,6 +1344,11 @@ notify_motion(struct wl_input_device *device, uint32_t
> time, int x, int y)
> device->x = x;
> device->y = y;
>
> + wl_list_for_each(output, &ec->output_list, link)
> + if (output->zoom.active &&
> + pixman_region32_contains_point(&output->region, x, y, NULL))
> + weston_output_update_zoom(output, x, y);
> +
> weston_device_repick(device, time);
> interface = device->pointer_grab->interface;
> interface->motion(device->pointer_grab, time,
> @@ -1941,17 +1949,29 @@ weston_output_destroy(struct weston_output *output)
> }
>
> WL_EXPORT void
> -weston_output_move(struct weston_output *output, int x, int y)
> +weston_output_update_zoom(struct weston_output *output, int x, int y)
> {
> - int flip;
> + if (output->zoom.level <= 0)
> + return;
>
> - output->x = x;
> - output->y = y;
> + float ratio;
>
> - pixman_region32_init(&output->previous_damage);
> - pixman_region32_init_rect(&output->region, x, y,
> - output->current->width,
> - output->current->height);
> + output->zoom.magnification = 1 / output->zoom.level;
> + ratio = 1 - (1 / output->zoom.magnification);
> +
> + output->zoom.trans_x = (((float)(x - output->x) /
> output->current->width) * (ratio * 2)) - ratio;
> + output->zoom.trans_y = (((float)(y - output->y) /
> output->current->height) * (ratio * 2)) - ratio;
> +
> + output->dirty = 1;
> + weston_output_damage(output);
> +}
> +
> +WL_EXPORT void
> +weston_output_update_matrix(struct weston_output *output)
> +{
> + int flip;
> + struct weston_matrix camera;
> + struct weston_matrix modelview;
>
> weston_matrix_init(&output->matrix);
> weston_matrix_translate(&output->matrix,
> @@ -1962,8 +1982,28 @@ weston_output_move(struct weston_output *output, int
> x, int y)
> weston_matrix_scale(&output->matrix,
> 2.0 / (output->current->width + output->border.left
> + output->border.right),
> flip * 2.0 / (output->current->height +
> output->border.top + output->border.bottom), 1);
> + if (output->zoom.active) {
> + weston_matrix_init(&camera);
> + weston_matrix_init(&modelview);
> + weston_matrix_translate(&camera, output->zoom.trans_x, flip *
> output->zoom.trans_y, 0);
> + weston_matrix_invert(&modelview, &camera);
> + weston_matrix_scale(&modelvi
Re: Touch events
Hi, On 23 February 2012 20:22, Bill Spitzak wrote: > Chase Douglas wrote: >> The client won't see the third finger if it touches outside its window. >> In the wayland case, only the WM has all the info needed to determine if >> a touch is part of a global gesture. The WM needs to make the decision, >> not the client. > > I'm pretty certain all touch events *MUST* go to the same surface until all > touches are released. Otherwise it will be quite impossible to do gestures > reliably, like the user could not do them to objects near the edge of a > window. On touchpads, yes. On touchscreens, no. >> That would be bad UI design because then global gestures would fire only >> sometimes. Further, it would break global gestures if touches occur over >> a broken application. > > > I consider it bad design that global actions are "complex" (like needing 3 > fingers) or global shortcuts require lots of shift keys held down, just to > avoid collisions with applications. Needing three fingers isn't complex. My grandparents can understand it, and regularly use three-finger gestures. >> I think we can look at other OSes as case studies. iOS and OS X employ >> effective global gestures imo, and they take precedence over the >> application receiving touch or gesture events. > > I think it is pretty clear that "what other OS's do" is not always what > Wayland wants to do. Most of them copied ideas from X. Not really. X's input system is pretty unique (and pretty uniquely broken), and I think it's safe to say that no-one -- least of all iOS -- has copied it. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Fix pointer position clipping.
On Thu, Feb 23, 2012 at 3:47 PM, Kristian Hoegsberg wrote: > On Wed, Feb 22, 2012 at 01:57:51PM -0700, Scott Moreau wrote: > > Yup, good fix, applied. > > Kristian > Applied but not pushed? I don't see it in the current weston log history. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v4] Introduce output zoom.
On Thu, Feb 23, 2012 at 3:54 PM, Kristian Hoegsberg wrote:
> On Wed, Feb 22, 2012 at 02:21:41PM -0700, Scott Moreau wrote:
> > Ideally, we would want to use +Scroll binding but that will
> have
> > to wait for axis events. For now we just use keybindings. Zoom in/out
> with
> > Super+Up/Down.
>
> Applied with a minor edit to really fix the code-before-declaration
> thing. With your change we still end up with
>
> weston_output_update_zoom(struct weston_output *output, int x, int y)
> {
> if (output->zoom.level <= 0)
> return;
>
>float ratio;
>...
>
> That is, the ratio variable is declared after the if statement.
> That's what we don't want.
>
Ah ok. So all declarations should come before code. Clearly I didn't pay
attention to the meaning of code-before-declaration.
>
> Anyway, enough nit-picking, it works well where, but we need to fix
> the binding issue. We need to swallow the key press that triggers the
> binding and we also need to swallow the corresponding key up. What
> I've been thinking is that we could let the binding handler return a
> value to indicate whether or not to swallow the event. The tricky
> part is going to be swallowing the release event, since that may come
> many key events later. We could just maintain a per-device list of
> "keys that are down, and we need to swallow the release event", but
> that's kinda gross. I don't really think there's a nicer way though.
> And all this applies to pointer buttons as well.
>
> Kristian
>
Yes, this is a problem with all keybindings currently. I was thinking the
same about eating the actual keybinding when the pressed/clicked but I
hadn't given much thought about the corresponding release event(s). It does
seem like we'd need some kind of state tracking for this. I haven't looked
into it yet but maybe when a binding is detected, we could set something
(possibly on the binding list or similar?) to listen for release of the
events involved. I haven't given much thought to this nor have I looked
into it yet but will do so.
Also, is this a blocker? I don't see the patch in weston yet.
Thanks,
Scott
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Restructure output zoom key handling.
This effectively eats the keybinding events, as we don't want them sent to
clients.
---
src/shell.c | 60 +++---
1 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index ee71dcc..d949d0c 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -119,6 +119,10 @@ struct weston_move_grab {
int32_t dx, dy;
};
+struct weston_zoom_grab {
+ struct wl_keyboard_grab grab;
+};
+
struct rotate_grab {
struct wl_pointer_grab grab;
struct shell_surface *surface;
@@ -1035,18 +1039,36 @@ resize_binding(struct wl_input_device *device, uint32_t
time,
}
static void
-zoom_in_binding(struct wl_input_device *device, uint32_t time,
- uint32_t key, uint32_t button, uint32_t state, void *data)
+zoom_grab_key(struct wl_keyboard_grab *grab,
+ uint32_t time, uint32_t key, int32_t state)
{
+ struct wl_input_device *device = grab->input_device;
struct weston_input_device *wd = (struct weston_input_device *) device;
struct weston_compositor *compositor = wd->compositor;
struct weston_output *output;
+ struct weston_zoom_grab *zoom;
+
+ if (!(wd->modifier_state & MODIFIER_SUPER)) {
+ zoom = container_of(grab, struct weston_zoom_grab, grab);
+ wl_input_device_end_keyboard_grab(device, time);
+ free(zoom);
+ return;
+ }
wl_list_for_each(output, &compositor->output_list, link) {
if (pixman_region32_contains_point(&output->region,
device->x, device->y, NULL)) {
- output->zoom.active = 1;
- output->zoom.level -= output->zoom.increment;
+ if (state && key == KEY_UP) {
+ output->zoom.active = 1;
+ output->zoom.level -= output->zoom.increment;
+ }
+ if (state && key == KEY_DOWN)
+ output->zoom.level += output->zoom.increment;
+
+ if (output->zoom.level >= 1.0) {
+ output->zoom.active = 0;
+ output->zoom.level = 1.0;
+ }
if (output->zoom.level < output->zoom.increment)
output->zoom.level = output->zoom.increment;
@@ -1056,26 +1078,24 @@ zoom_in_binding(struct wl_input_device *device,
uint32_t time,
}
}
+static const struct wl_keyboard_grab_interface zoom_grab = {
+ zoom_grab_key,
+};
+
static void
-zoom_out_binding(struct wl_input_device *device, uint32_t time,
+zoom_binding(struct wl_input_device *device, uint32_t time,
uint32_t key, uint32_t button, uint32_t state, void *data)
{
struct weston_input_device *wd = (struct weston_input_device *) device;
- struct weston_compositor *compositor = wd->compositor;
- struct weston_output *output;
+ struct weston_zoom_grab *zoom;
- wl_list_for_each(output, &compositor->output_list, link) {
- if (pixman_region32_contains_point(&output->region,
- device->x, device->y, NULL)) {
- output->zoom.level += output->zoom.increment;
- if (output->zoom.level >= 1.0) {
- output->zoom.active = 0;
- output->zoom.level = 1.0;
- }
+ zoom = malloc(sizeof *zoom);
+ if (!zoom)
+ return;
- weston_output_update_zoom(output, device->x, device->y);
- }
- }
+ zoom->grab.interface = &zoom_grab;
+
+ wl_input_device_start_keyboard_grab(&wd->input_device, &zoom->grab,
time);
}
static void
@@ -1878,9 +1898,9 @@ shell_init(struct weston_compositor *ec)
weston_compositor_add_binding(ec, 0, BTN_LEFT, 0,
click_to_activate_binding, ec);
weston_compositor_add_binding(ec, KEY_UP, 0, MODIFIER_SUPER,
- zoom_in_binding, shell);
+ zoom_binding, shell);
weston_compositor_add_binding(ec, KEY_DOWN, 0, MODIFIER_SUPER,
- zoom_out_binding, shell);
+ zoom_binding, shell);
weston_compositor_add_binding(ec, 0, BTN_LEFT,
MODIFIER_SUPER | MODIFIER_ALT,
rotate_binding, NULL);
--
1.7.4.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Thu, Feb 23, 2012 at 04:26:23PM -0500, Kristian Hoegsberg wrote:
> On Thu, Feb 23, 2012 at 03:58:37PM +1000, Peter Hutterer wrote:
> > Includes rudimentary styling only.
> >
> > Signed-off-by: Peter Hutterer
> > ---
> > A few things to note:
> > - I'm not a designer
> > - Having a html version of the protocol makes it a lot easier to read, and
> > it certainly reveals missing bits of documentation in the protocol
> > - the .css file is the one from wayland.freedesktop.org, someone could
> > easily fix it to prettify the result a bit.
>
> That is very nice. As part of 1.0, we need to figure out a way to
> combine the protocol and the spec document into something like docbook
> and make pdf and html versions. I don't think we want to stick with latex.
I've played around a bit today and the result is this:
http://people.freedesktop.org/~whot/Wayland/tmp/en-US/html/
I've copied over the Wayland Architecture page from the current website just
to have a proper chapter in there, the protocol documentation generated from
a modification of the xsl.
The whole lot is generated with publican, I've been assured that publican
can also produce pdf, epub, etc. And the source was relatively trivial, even
for someone with little docbook experience.
With a bit of targeted styling, I think this could become quite useful but
before I invest any more time in this I'd like to hear a yay/nay.
Cheers,
Peter
> Anyway, for now, this is great and definitely highlights the missing
> documentation. Committed, and I'll try to setup a push hook to put
> the html on the web site.
>
> thanks,
> Kristian
>
> > Makefile.am |2 +-
> > configure.ac |6 +-
> > protocol/Makefile.am |7 ++
> > protocol/protocol.xsl | 204
> > +
> > protocol/wayland.css | 41 ++
> > 5 files changed, 258 insertions(+), 2 deletions(-)
> > create mode 100644 protocol/Makefile.am
> > create mode 100644 protocol/protocol.xsl
> > create mode 100644 protocol/wayland.css
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 4461e48..016bb76 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -1,4 +1,4 @@
> > -SUBDIRS = src
> > +SUBDIRS = src protocol
> >
> > ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
> >
> > diff --git a/configure.ac b/configure.ac
> > index a1c9d2a..fc623e8 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -48,9 +48,13 @@ if test "x$enable_scanner" = "xyes"; then
> > AC_SUBST(EXPAT_LIBS)
> > fi
> >
> > +AC_PATH_PROG(XSLTPROC, xsltproc)
> > +AM_CONDITIONAL([HAVE_XSLTPROC], [test $XSLTPROC != ""])
> > +
> > AC_CONFIG_FILES([Makefile
> > wayland-scanner.m4
> > src/Makefile
> > src/wayland-server.pc
> > -src/wayland-client.pc])
> > +src/wayland-client.pc
> > +protocol/Makefile])
> > AC_OUTPUT
> > diff --git a/protocol/Makefile.am b/protocol/Makefile.am
> > new file mode 100644
> > index 000..9b57441
> > --- /dev/null
> > +++ b/protocol/Makefile.am
> > @@ -0,0 +1,7 @@
> > +if HAVE_XSLTPROC
> > +doc_DATA = wayland.html wayland.css
> > +
> > +wayland.html: wayland.xml protocol.xsl
> > + $(AM_V_GEN)$(XSLTPROC) protocol.xsl wayland.xml > $@
> > +
> > +endif
> > diff --git a/protocol/protocol.xsl b/protocol/protocol.xsl
> > new file mode 100644
> > index 000..b2867f0
> > --- /dev/null
> > +++ b/protocol/protocol.xsl
> > @@ -0,0 +1,204 @@
> > +
> > + > xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +Wayland
> > +
> > +
> > +
> > +Wayland Protocol Specification
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > + > mode="interface_description" />
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +Table of Contents
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > + Requests:
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > + Events:
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > + Enums:
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > + #
> > +
> > + -
> > +
> > + -
> > +
> > +
> > +
> > +
> > +- > select="description/@summary"/>
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > + -
> > +
> > +
> > +Version:
> > +
> > +
> > +
> > + Requests
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > + Events
> > +
> > +
> > +
> > +
