Add SetCursorLocationRelative D-Bus method

Add SetCursorLocationRelative D-Bus method

We have SetCursorLocation D-Bus method which takes the absolute
coordinates of the screen, while on Wayland the coordinates are relative
to the current input window and there is no way to calculate the
absolute coordinates.  That makes it impossible for the panel to
position the lookup table correctly.

This patch adds a new D-Bus method, SetCursorLocationRelative, which
takes the relative coordinates, so that the panel
implementation (typically the same process of Wayland compositor) can
use that information.  The counterpart of this changes is at:
https://bugzilla.gnome.org/show_bug.cgi?id=753476

Unlike SetCursorLocation, SetCursorLocationRelative is not delivered to
engines, since it is not very useful for the engines without knowing the
current input window (which is also not accessible from a different
process on Wayland).

Co-authored-by: Rui Matos <tiagomatos@gmail.com>

BUG=
R=takao.fujiwara1@gmail.com

Committed: b51c6200686d5494f317f8675763bad5cdd442b2

[Peng, 2016-02-13 20:41:53]

On 2016/02/13 06:35:04, Daiki Ueno wrote:

Why we can not get the absolute coordinates? Is it a wayland or gtk issue?

[Daiki Ueno, 2016-02-14 02:28:01]

On 2016/02/13 20:41:53, Peng wrote:
> On 2016/02/13 06:35:04, Daiki Ueno wrote:
> 
> Why we can not get the absolute coordinates? Is it a wayland or gtk issue?

It is by design that Wayland does not expose global coordinates to clients.  I
couldn't find authoritative document, but see IX of:
http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=2

In fact, GDK also does not provide move_resize for toplevel windows on Wayland.

[Peng, 2016-02-14 21:55:26]

On 2016/02/14 02:28:01, Daiki Ueno wrote:
> On 2016/02/13 20:41:53, Peng wrote:
> > On 2016/02/13 06:35:04, Daiki Ueno wrote:
> > 
> > Why we can not get the absolute coordinates? Is it a wayland or gtk issue?
> 
> It is by design that Wayland does not expose global coordinates to clients.  I
> couldn't find authoritative document, but see IX of:
> http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=2
> 
> In fact, GDK also does not provide move_resize for toplevel windows on
Wayland.

Lgtm

[fujiwara, 2016-02-15 08:50:35]

> Signed-off-by: Daiki Ueno <ueno@gnu.org>

I think git-cl does not enable the signed commit.

https://codereview.appspot.com/290780043/diff/1/client/gtk2/ibusimcontext.c
File client/gtk2/ibusimcontext.c (right):

https://codereview.appspot.com/290780043/diff/1/client/gtk2/ibusimcontext.c#n...
client/gtk2/ibusimcontext.c:1027: area.x = px;
Probably I think double to int for while might not get the accurate coordinates.

https://codereview.appspot.com/290780043/diff/1/client/gtk2/ibusimcontext.c#n...
client/gtk2/ibusimcontext.c:1032:
ibus_input_context_set_cursor_location_relative (ibusimcontext->ibuscontext,
maybe 82 columns?

[Daiki Ueno, 2016-02-16 08:58:51]

Removed "Signed-off-by".

https://codereview.appspot.com/290780043/diff/1/client/gtk2/ibusimcontext.c
File client/gtk2/ibusimcontext.c (right):

https://codereview.appspot.com/290780043/diff/1/client/gtk2/ibusimcontext.c#n...
client/gtk2/ibusimcontext.c:1027: area.x = px;
On 2016/02/15 08:50:35, fujiwara wrote:
> Probably I think double to int for while might not get the accurate
coordinates.

I don't think this causes any difference. The coords are calculated from
GdkWindow's x and y members, which are both integer.

https://codereview.appspot.com/290780043/diff/1/client/gtk2/ibusimcontext.c#n...
client/gtk2/ibusimcontext.c:1032:
ibus_input_context_set_cursor_location_relative (ibusimcontext->ibuscontext,
On 2016/02/15 08:50:35, fujiwara wrote:
> maybe 82 columns?

Done.

[fujiwara, 2016-02-16 09:42:00]

lgtm, thx.

https://codereview.appspot.com/290780043/diff/1/client/gtk2/ibusimcontext.c
File client/gtk2/ibusimcontext.c (right):

https://codereview.appspot.com/290780043/diff/1/client/gtk2/ibusimcontext.c#n...
client/gtk2/ibusimcontext.c:1027: area.x = px;
On 2016/02/16 08:58:51, Daiki Ueno wrote:
> On 2016/02/15 08:50:35, fujiwara wrote:
> > Probably I think double to int for while might not get the accurate
> coordinates.
> 
> I don't think this causes any difference. The coords are calculated from
> GdkWindow's x and y members, which are both integer.

OK, I see. I guess the double values are for "to-embedder" signal and I just
thought the implementation of gtk_widget_translate_coordinates().

[Daiki Ueno, 2016-02-17 07:29:08]

Committed patchset #2 (id:20001) manually as
b51c6200686d5494f317f8675763bad5cdd442b2 (presubmit successful).