Commit df969706 authored by Peter Hutterer's avatar Peter Hutterer Committed by Simon Ser

Replace initial 8 spaces with a tab for all xml files

This is the style used in wayland.xml which is the only file we really
care about for git blame information. So let's adjust all others to that
style for consistency and fix editorconfig to avoid messing this up in
the future.
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
parent cc8b6aa3
Pipeline #139693 passed with stage
in 2 minutes and 9 seconds
......@@ -10,7 +10,7 @@ indent_size = 8
max_line_length = 80
[*.xml]
indent_style = space
indent_style = tab
indent_size = 2
tab_width = 8
......
......@@ -28,9 +28,9 @@
<imagedata fileref="images/wayland.png" format="PNG" />
</imageobject>
<textobject>
<phrase>
Wayland logo
</phrase>
<phrase>
Wayland logo
</phrase>
</textobject>
</inlinemediaobject>
</corpauthor>
......
......@@ -61,8 +61,8 @@
<para>
Possible examples for session compositors include
<itemizedlist>
<listitem>
<para>
<listitem>
<para>
gnome-shell
</para>
</listitem>
......
......@@ -22,7 +22,7 @@
<literallayout>
Yours,
the Wayland open-source community
November 2012
the Wayland open-source community
November 2012
</literallayout>
</preface>
......@@ -33,9 +33,9 @@
<imagedata fileref="images/x-architecture.png" format="PNG" />
</imageobject>
<textobject>
<phrase>
X architecture diagram
</phrase>
<phrase>
X architecture diagram
</phrase>
</textobject>
</mediaobject>
<para>
......@@ -96,9 +96,9 @@
<imagedata fileref="images/wayland-architecture.png" format="PNG" />
</imageobject>
<textobject>
<phrase>
Wayland architecture diagram
</phrase>
<phrase>
Wayland architecture diagram
</phrase>
</textobject>
</mediaobject>
<para>
......
......@@ -15,6 +15,6 @@
<literallayout>
Best,
Kristian Høgsberg
Kristian Høgsberg
</literallayout>
</preface>
......@@ -78,11 +78,11 @@
<figure>
<title>Xwayland architecture diagram</title>
<mediaobjectco>
<imageobjectco>
<imageobject>
<imagedata fileref="images/xwayland-architecture.png" format="PNG" />
</imageobject>
</imageobjectco>
<imageobjectco>
<imageobject>
<imagedata fileref="images/xwayland-architecture.png" format="PNG" />
</imageobject>
</imageobjectco>
</mediaobjectco>
</figure>
<para>
......@@ -150,20 +150,20 @@
<section id="sect-X11-Application-Support-xwm-window-identification">
<title>Window identification</title>
<para>
In Xwayland, an X11 window may have a corresponding wl_surface object
in Wayland. The wl_surface object is used for input and output: it is
referenced by input events and used to provide the X11 window content
to the Wayland compositor. The X11 window and the wl_surface live in
different protocol streams, and they need to be matched for XWM to do
its job.
In Xwayland, an X11 window may have a corresponding wl_surface object
in Wayland. The wl_surface object is used for input and output: it is
referenced by input events and used to provide the X11 window content
to the Wayland compositor. The X11 window and the wl_surface live in
different protocol streams, and they need to be matched for XWM to do
its job.
</para>
<para>
When Xwayland creates a wl_surface on Wayland, it will also send an X11
ClientMessage of type atom "WL_SURFACE_ID" to the X11 window carrying
the wl_surface Wayland object ID as the first 32-bit data element. This
is how XWM can associate a wl_surface with an X11 window. Note that
the request to create a wl_surface and the ID message may arrive in any
order in the Wayland compositor.
When Xwayland creates a wl_surface on Wayland, it will also send an X11
ClientMessage of type atom "WL_SURFACE_ID" to the X11 window carrying
the wl_surface Wayland object ID as the first 32-bit data element. This
is how XWM can associate a wl_surface with an X11 window. Note that
the request to create a wl_surface and the ID message may arrive in any
order in the Wayland compositor.
</para>
</section>
</section>
......
......@@ -43,8 +43,8 @@
<!-- Version 2 additions -->
<request name="conjoin" since="2">
<description summary="register another fd passer with this one">
Tells this fd passer object about another one to send events
to for more complicated fd leak tests.
Tells this fd passer object about another one to send events
to for more complicated fd leak tests.
</description>
<arg name="passer" type="object" interface="fd_passer"/>
</request>
......
......@@ -298,7 +298,7 @@
will be reported by the format event.
</description>
<!-- Note to protocol writers: don't update this list manually, instead
run the automated script that keeps it in sync with drm_fourcc.h. -->
run the automated script that keeps it in sync with drm_fourcc.h. -->
<entry name="argb8888" value="0" summary="32-bit ARGB format, [31:0] A:R:G:B 8:8:8:8 little endian"/>
<entry name="xrgb8888" value="1" summary="32-bit RGB format, [31:0] x:R:G:B 8:8:8:8 little endian"/>
<entry name="c8" value="0x20203843" summary="8-bit color index format, [7:0] C"/>
......@@ -594,9 +594,9 @@
will be raised otherwise.
</description>
<arg name="dnd_actions" type="uint" summary="actions supported by the destination client"
enum="wl_data_device_manager.dnd_action"/>
enum="wl_data_device_manager.dnd_action"/>
<arg name="preferred_action" type="uint" summary="action preferred by the destination client"
enum="wl_data_device_manager.dnd_action"/>
enum="wl_data_device_manager.dnd_action"/>
</request>
<event name="source_actions" since="3">
......@@ -606,7 +606,7 @@
side changes its offered actions through wl_data_source.set_actions.
</description>
<arg name="source_actions" type="uint" summary="actions offered by the data source"
enum="wl_data_device_manager.dnd_action"/>
enum="wl_data_device_manager.dnd_action"/>
</event>
<event name="action" since="3">
......@@ -648,7 +648,7 @@
must happen before the call to wl_data_offer.finish.
</description>
<arg name="dnd_action" type="uint" summary="action selected by the compositor"
enum="wl_data_device_manager.dnd_action"/>
enum="wl_data_device_manager.dnd_action"/>
</event>
</interface>
......@@ -746,7 +746,7 @@
for drag-and-drop will raise a protocol error.
</description>
<arg name="dnd_actions" type="uint" summary="actions supported by the data source"
enum="wl_data_device_manager.dnd_action"/>
enum="wl_data_device_manager.dnd_action"/>
</request>
<event name="dnd_drop_performed" since="3">
......@@ -803,7 +803,7 @@
they reflect the current action.
</description>
<arg name="dnd_action" type="uint" summary="action selected by the compositor"
enum="wl_data_device_manager.dnd_action"/>
enum="wl_data_device_manager.dnd_action"/>
</event>
</interface>
......
......@@ -50,9 +50,9 @@
<event name="hey"/>
<enum name="foo">
<entry name="first" value="0" summary="this is the first"/>
<entry name="second" value="1" summary="this is the second"/>
<entry name="third" value="2" since="2" summary="this is the third"/>
<entry name="first" value="0" summary="this is the first"/>
<entry name="second" value="1" summary="this is the second"/>
<entry name="third" value="2" since="2" summary="this is the third"/>
</enum>
</interface>
</protocol>
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment