wayland: Add wayland client

wayland: Add wayland client

This patch adds a new client which supports the Wayland input method
protocol.  Note that the support is disabled by default until the
input method protocol becomes official in the Wayland upstream.
Supply --enable-wayland to configure to try it.  Also, you will need
to set the executable path of ibus-wayland under the "input-method"
section of weston.ini, like this:

 [input-method]
 path=.../libexec/ibus-wayland

BUG=Issue#1617

Committed: 5136dbc

[Peng, 2013-07-16 15:56:17]

+Takao-san

[fujiwara, 2013-07-22 05:03:19]

https://codereview.appspot.com/11320043/diff/4001/client/Makefile.am
File client/Makefile.am (right):

https://codereview.appspot.com/11320043/diff/4001/client/Makefile.am#newcode37
client/Makefile.am:37: endif
input-method.xml in EXTRA_DIST

[fujiwara, 2013-07-22 05:04:57]

On 2013/07/22 05:03:19, fujiwara wrote:
> https://codereview.appspot.com/11320043/diff/4001/client/Makefile.am
> File client/Makefile.am (right):
> 
> https://codereview.appspot.com/11320043/diff/4001/client/Makefile.am#newcode37
> client/Makefile.am:37: endif
> input-method.xml in EXTRA_DIST

s|client/Makefile.am|client/wayland/Makefile.am|

[fujiwara, 2013-07-22 05:50:48]

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am
File client/wayland/Makefile.am (right):

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am#...
client/wayland/Makefile.am:23: 
No need the null line?

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am#...
client/wayland/Makefile.am:29: main.c					\
When I open the file with vi, this is not aligned. I'd suggest to use spaces
between main.c and \ instead of tabs.

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am#...
client/wayland/Makefile.am:48: -I$(top_builddir)/src			\
-I$(top_builddir)/src is not needed?
Probably I think any built sources are not included in this CFLAGS.

https://codereview.appspot.com/11320043/diff/4001/client/wayland/main.c
File client/wayland/main.c (right):

https://codereview.appspot.com/11320043/diff/4001/client/wayland/main.c#newco...
client/wayland/main.c:724: g_printerr ("Failed to connect to Wayland server:
%m\n");
output for %m?
Maybe g_critical is more useful than g_printerr without "\n".

[Daiki Ueno, 2013-07-22 09:19:31]

https://codereview.appspot.com/11320043/diff/4001/client/Makefile.am
File client/Makefile.am (right):

https://codereview.appspot.com/11320043/diff/4001/client/Makefile.am#newcode37
client/Makefile.am:37: endif
On 2013/07/22 05:03:19, fujiwara wrote:
> input-method.xml in EXTRA_DIST

Done, thanks.  Also fixed make dist with --disable-wayland.

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am
File client/wayland/Makefile.am (right):

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am#...
client/wayland/Makefile.am:23: 
On 2013/07/22 05:50:48, fujiwara wrote:
> No need the null line?

Done.

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am#...
client/wayland/Makefile.am:29: main.c					\
On 2013/07/22 05:50:48, fujiwara wrote:
> When I open the file with vi, this is not aligned. I'd suggest to use spaces
> between main.c and \ instead of tabs.

That's probably because of the first line:

  vim:set noet ts=4:

I've just changed it to "ts=8", since it might be troublesome to mix tabs and
spaces in Makefile.

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am#...
client/wayland/Makefile.am:48: -I$(top_builddir)/src			\
On 2013/07/22 05:50:48, fujiwara wrote:
> -I$(top_builddir)/src is not needed?
> Probably I think any built sources are not included in this CFLAGS.

ibusenumtypes.h (which is included through ibus.h) is generated under
$(top_builddir)/src.

https://codereview.appspot.com/11320043/diff/4001/client/wayland/main.c
File client/wayland/main.c (right):

https://codereview.appspot.com/11320043/diff/4001/client/wayland/main.c#newco...
client/wayland/main.c:724: g_printerr ("Failed to connect to Wayland server:
%m\n");
On 2013/07/22 05:50:48, fujiwara wrote:
> output for %m?

Rewrote it in a more portable way.

> Maybe g_critical is more useful than g_printerr without "\n".

g_critical is for log output for developers:
https://developer.gnome.org/glib/stable/glib-Message-Logging.html#g-critical

while g_printerr is typically used by applications to give some information to
users:
https://developer.gnome.org/glib/stable/glib-Warnings-and-Assertions.html#g-p...

In this case, g_printerr seems more appropriate to me.

[fujiwara, 2013-07-25 14:05:37]

LGTM.

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am
File client/wayland/Makefile.am (right):

https://codereview.appspot.com/11320043/diff/4001/client/wayland/Makefile.am#...
client/wayland/Makefile.am:29: main.c					\
On 2013/07/22 09:19:32, Daiki Ueno wrote:
> On 2013/07/22 05:50:48, fujiwara wrote:
> > When I open the file with vi, this is not aligned. I'd suggest to use spaces
> > between main.c and \ instead of tabs.
> 
> That's probably because of the first line:
> 
>   vim:set noet ts=4:
> 
> I've just changed it to "ts=8", since it might be troublesome to mix tabs and
> spaces in Makefile.

Probably I think it's better to keep ts=4 to meet our indents for all files and
no problem when the first head of the line is tab in Makefile.
Personally I'd like to convert tabs to spaces as much as possible.

https://codereview.appspot.com/11320043/diff/4001/client/wayland/main.c
File client/wayland/main.c (right):

https://codereview.appspot.com/11320043/diff/4001/client/wayland/main.c#newco...
client/wayland/main.c:724: g_printerr ("Failed to connect to Wayland server:
%m\n");
On 2013/07/22 09:19:32, Daiki Ueno wrote:
> On 2013/07/22 05:50:48, fujiwara wrote:
> > output for %m?
> 
> Rewrote it in a more portable way.
> 
> > Maybe g_critical is more useful than g_printerr without "\n".
> 
> g_critical is for log output for developers:
> https://developer.gnome.org/glib/stable/glib-Message-Logging.html#g-critical

I could not find g_critical (and g_warning?) is for deverlopers in the API
guide.
OK, I will think this again in the future.

> 
> while g_printerr is typically used by applications to give some information to
> users:
>
https://developer.gnome.org/glib/stable/glib-Warnings-and-Assertions.html#g-p...
> 
> In this case, g_printerr seems more appropriate to me.

[Daiki Ueno, 2013-08-12 11:19:49]

Come to think of it, it would be more hassle-free to include generated source
code, instead of running wayland-scanner by ourselves, like gtk+ patch:
https://bugzilla.gnome.org/show_bug.cgi?id=698307

Peng, what about you for the review?  If no problem, I'll push it soon.

[Peng, 2013-08-12 16:05:55]

lgtm with some comments.

https://codereview.appspot.com/11320043/diff/20001/client/wayland/Makefile.am
File client/wayland/Makefile.am (right):

https://codereview.appspot.com/11320043/diff/20001/client/wayland/Makefile.am...
client/wayland/Makefile.am:29: input-method-client-protocol.h		\
It is better to keep file in alphabetical order.

https://codereview.appspot.com/11320043/diff/20001/client/wayland/Makefile.am...
client/wayland/Makefile.am:34: main.c					\
I think it is not necessary to align  '\' at end of each line. And for other
places

https://codereview.appspot.com/11320043/diff/20001/client/wayland/main.c
File client/wayland/main.c (right):

https://codereview.appspot.com/11320043/diff/20001/client/wayland/main.c#newc...
client/wayland/main.c:32: #include "input-method-client-protocol.h"
Suggest using alphabetical order. (although old code does not follow this rule,
but I think it is good to have. And we could fix all old files, when we modify
them.)

For example:

#include "config.h"

#include <axxx>
#include <bxxx>
#include <cxxx>

#include "a"
#include "b"

[fujiwara, 2013-08-13 05:41:19]

https://codereview.appspot.com/11320043/diff/20001/client/wayland/Makefile.am
File client/wayland/Makefile.am (right):

https://codereview.appspot.com/11320043/diff/20001/client/wayland/Makefile.am...
client/wayland/Makefile.am:34: main.c					\
On 2013/08/12 16:05:56, Peng wrote:
> I think it is not necessary to align  '\' at end of each line. And for other
> places

And tabs are not needed. ts=4.

[Daiki Ueno, 2013-08-13 07:04:14]

Fixed those.  Thanks.