Thank you, Jørgen. I will definitely look at QtCompositor. It is surprising
that you release it under the BSD license. I thought that the
non-commercial QT was under a modified LGPL. Anyway, it's nice to see that
the QT team is not resting on its laurels and actually pursuing innovative
directions
>
> We have a different case to consider though. When a surface is
> explicitly destroyed by calling surface.destroy(), we still need to
> destroy pending callbacks, and that case the resource system wont do
> it for us. So we need to iterate through the list and free them
> manually.
Is there
Hi Mikalai
On 12 July 2012 08:03, Mikalai Kisialiou wrote:
> Juan, Jonas and Christopher,
>
> I appreciate your feedback! Small additions to shells are indeed not a
> problem. It was not a right example to make my point. As it is now, Weston
> can be considered barebone since the code base is sma
On Thu, Jul 12, 2012 at 12:46:11AM +0300, Tiago Vignatti wrote:
> It's in fact based on the core of libXcursor, which doesn't bring any Xlib
> dependency.
>
> Signed-off-by: Tiago Vignatti
> ---
> configure.ac |2 +-
> src/xwayland/Makefile.am |1 +
> src/xwayland/xcb-curso
On Thu, Jul 12, 2012 at 9:02 AM, Tiago Vignatti
wrote:
> On 07/12/2012 05:39 AM, Kristian Høgsberg wrote:
>>
>> On Thu, Jul 12, 2012 at 12:46:12AM +0300, Tiago Vignatti wrote:
>>>
>>> +static void
>>> +weston_wm_handle_leave(struct weston_wm *wm, xcb_generic_event_t *event)
>>> +{
>>> + xcb_
On 07/12/2012 05:39 AM, Kristian Høgsberg wrote:
On Thu, Jul 12, 2012 at 12:46:12AM +0300, Tiago Vignatti wrote:
+static void
+weston_wm_handle_leave(struct weston_wm *wm, xcb_generic_event_t *event)
+{
+ xcb_leave_notify_event_t *leave_notify =
+ (xcb_leave_n
On 07/12/2012 06:01 AM, Scott Moreau wrote:
We don't need to set the cursor on leave, whatever window the cursor
moves into will set it. But we do need to set it on enter.
What if the surface the cursor moves to is the background image? Could
the desktop surface set the cursor to a de
On Wed, 11 Jul 2012 23:03:06 -0700
Mikalai Kisialiou wrote:
> Juan, Jonas and Christopher,
>
> I appreciate your feedback! Small additions to shells are indeed not a
> problem. It was not a right example to make my point. As it is now, Weston
> can be considered barebone since the code base is s
These are pure python wrappers compatible with Python2, Python3, and PyPy.
Later I will optimize the wrapper generator for PyPy by allowing ctypes to
be swapped out for PyPy's own JIT optimized *"_ffi"* replacement.
http://code.google.com/p/rpythonic/source/browse/examples/wayland_client/__init__.
Juan, Jonas and Christopher,
I appreciate your feedback! Small additions to shells are indeed not a
problem. It was not a right example to make my point. As it is now, Weston
can be considered barebone since the code base is small. The question is
how long it will stay that way, given some interes
10 matches
Mail list logo
