What It Takes To Write A Wayland Compositor

[phoronix]

Phoronix: What It Takes To Write A Wayland Compositor

For those curious about what it takes to write a standalone Wayland compositor and the challenges involved, two Enlightenment developers have shared their struggles and accomplishments in making Enlightenment a Wayland compositor...

http://www.phoronix.com/vr.php?view=MTU5ODg

[gens]

enlightenment crew
doing things right since... a long time ago

[89c51]

E will need WL 1.5 to be everyday usable right??

[devilhorns]

E will need WL 1.5 to be everyday usable right??

Currently it requires >= 1.3.0 But (more than likely) will (eventually) need 1.5 in order to support the xdg-shell protocol although the current EFL wayland stuff just needs 1.3.0

[89c51]

Currently it requires >= 1.3.0 But (more than likely) will (eventually) need 1.5 in order to support the xdg-shell protocol although the current EFL wayland stuff just needs 1.3.0

I should have worded it a bit differently and ask if the xdg_shell will make it everyday usable. Assuming this goes into WL1.5.

[newwen]

The input library for wayland is an important component to be also be standardized, so that every wayland-based desktop compositor handles input the same way.

BTW, does drag-and-drop currently work well in wayland, even among different toolkits or is this something well defined by the Wyaland protocol?

[mannerov]

xdg_shell is still beeing designed, but it should be very cool.

You can see current proposition here: https://github.com/magcius/weston/bl.../xdg-shell.xml

For example you can give an app id to the surface, and I was said the app id can be used to get the right icon, etc (something that was missing before).

As for input, the protocol has been designed long ago now, and works well. The only bit missing I aware of, is pointer lock (used for example in fps games so that the mouse doesn't block when the pointer hits the borders of the screen).

[silix]

As for input, the protocol has been designed long ago now, and works well. The only bit missing I aware of, is pointer lock (used for example in fps games so that the mouse doesn't block when the pointer hits the borders of the screen).

pointer?
an FPS doesnt require a pointer (thus, window relative coordinates)
but rather X-Y motion deltas, ie raw mouse events, ie what the compositor natively sees and uses to recalculate screen-relative pointer coordinates (which in turn minus the current window origin's cooords, become the pointer's ones relative to the window)
an fps game should just be able to subscribe for native events and the compositor should just relay those, reconstructing them from coordinate differences is silly (since that information already exists in the system) and locking the pointer is a hack (since there shouldnt be a pointer at all in the first place - except maybe in the menu)

[daniels]

pointer?
an FPS doesnt require a pointer (thus, window relative coordinates)
but rather X-Y motion deltas, ie raw mouse events, ie what the compositor natively sees and uses to recalculate screen-relative pointer coordinates (which in turn minus the current window origin's cooords, become the pointer's ones relative to the window)
an fps game should just be able to subscribe for native events and the compositor should just relay those, reconstructing them from coordinate differences is silly (since that information already exists in the system) and locking the pointer is a hack (since there shouldnt be a pointer at all in the first place - except maybe in the menu)

You've got terminology a bit mixed up here. 'Pointer' in Wayland is always used in the sense of 'pointing device', i.e. mouse. So yes, it would be relative co-ordinates from the mouse (with or without acceleration). The visible on-screen location of the pointer is always referred to as the cursor instead.

[silix]

You've got terminology a bit mixed up here. 'Pointer' in Wayland is always used in the sense of 'pointing device', i.e. mouse. So yes, it would be relative co-ordinates from the mouse (with or without acceleration). The visible on-screen location of the pointer is always referred to as the cursor instead.

"Pointer" has been the arrow / hand / whatever pointing at the next visual object to be selected on a pixel scale, for as long as the WIMP (Windows Icons Mouse and Pointer) paradigm has existed (decades)
otoh a "cursor" has always been the indicator for where text will be entered (| , usually but not always, blinking) - for as long
what's with this urge to redefine terminology? to confuse newer generations of users and programmers?

anyway, this aside (and aside from the fact that the concept of a pointer lock would be ludicrous, since a mouse doesnt block reaching screen borders - it doesnt even interact with screen borders, neither physical nor logical...) how would this change the point at hand (pointer lock being a hack)?