Hi,
in the process of porting webkitgtk+ to wayland and following advise
provided here, I implemented a nested compositor to share surfaces
between the two processes that do the rendering. This works fine with a
single widget/surface, but things get a bit more complicated when
dealing with
Hi Ander,
On 29/01/14 16:09, Ander Conselvan de Oliveira wrote:
On 01/15/2014 10:30 AM, Emilio Pozuelo Monfort wrote:
bump
On 07/01/14 17:23, poch...@gmail.com wrote:
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
Unfocusing a surface should dim it when dim-layer is enabled,
On Thu, 30 Jan 2014 10:32:03 +0100
Iago Toral ito...@igalia.com wrote:
Hi,
in the process of porting webkitgtk+ to wayland and following advise
provided here, I implemented a nested compositor to share surfaces
between the two processes that do the rendering. This works fine with
a single
Yeah, Pekka pretty much covered it. I've just got one more observation to
add. Are you doing one process per tab? Or do you have one process
handling multiple tabs? If you have one process per tab, then you can
easily differentiate by which wl_client the surface is attached to. You
can know
On Thu, 2014-01-30 at 13:34 +0200, Pekka Paalanen wrote:
On Thu, 30 Jan 2014 10:32:03 +0100
Iago Toral ito...@igalia.com wrote:
Hi,
in the process of porting webkitgtk+ to wayland and following advise
provided here, I implemented a nested compositor to share surfaces
between the two
Hi Jason, we have a single process managing all the tabs so this is not
an option in this case. Thanks for the suggestion though.
Regards,
Iago
On Thu, 2014-01-30 at 05:39 -0600, Jason Ekstrand wrote:
Yeah, Pekka pretty much covered it. I've just got one more
observation to add. Are you doing
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
Unfocusing a surface should dim it when dim-layer is enabled,
but this got broken in commit 83ffd9.
---
desktop-shell/shell.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/desktop-shell/shell.c
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
lower_fullscreen_surface() was removing fullscreen surfaces from
the fullscreen layer and inserting them in the normal workspace
layer. However, those fullscreen surfaces were never put back in
the fullscreen layer, causing bugs such as
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
Hi,
The following patch fixes a bunch of issues related to fullscreen
surfaces. From my testing, this makes fullscreen clients behave
much better.
We still have the following problem, but it is not a regression. I am
not sure how to
bump
-Original Message-
From: Eoff, Ullysses A
Sent: Friday, January 10, 2014 10:15 AM
To: wayland-devel@lists.freedesktop.org
Cc: Eoff, Ullysses A
Subject: [PATCH 2/2] udev-seat: break early when output is found and log the
mapping
When an input device has a WL_OUTPUT udev
Hi,
it's time for a take two on the Wayland presentation extension.
1. Introduction
The v1 proposal is here:
http://lists.freedesktop.org/archives/wayland-devel/2013-October/011496.html
In v2 the basic idea is the same: you can queue frames with a
target presentation time, and
Hi folks,
Where I work, we need to have some logic to manage surfaces from a client
point of view (application or toolkit). For example, we need to be able to :
- minimize (hide/show or more) surfaces, just like most desktop
environments allow ;
- manage layers, by arranging surfaces by z-orders
On Tue, Jan 28, 2014 at 6:18 PM, Peter Hutterer peter.hutte...@who-t.netwrote:
Here's a list of features I consider the minimum to get something akin to
feature-parity with the current X.Org-based stack. This is not a wishlist
for features, it's a list of minimum requirements that covers 90%
Ping Cheng wrote:
graphics tablets:
* extended axis event support
* tool change notification (could be just button events? not sure)
Will tool id, serial number, and tool type be supported here?
Shouldn't each tool be a different pointing device? It at least needs to
know which
On Thu, Jan 30, 2014 at 10:30:40AM -0800, Ping Cheng wrote:
On Tue, Jan 28, 2014 at 6:18 PM, Peter Hutterer
peter.hutte...@who-t.netwrote:
Here's a list of features I consider the minimum to get something akin to
feature-parity with the current X.Org-based stack. This is not a wishlist
On Thu, Jan 30, 2014 at 01:42:20PM -0800, Bill Spitzak wrote:
Ping Cheng wrote:
graphics tablets:
* extended axis event support
* tool change notification (could be just button events? not sure)
Will tool id, serial number, and tool type be supported here?
Shouldn't each
There really should not be a fullscreen layer which is what is causing
this problem. layers are imho a mistake except for the desttop and the
mouse cursor.
What I think needs to happen:
Fullscreen, normal windows, and panels can be arranged in any stacking
order, except the compositor
On Thu, Jan 30, 2014 at 08:38:02AM +0100, Jonas Ådahl wrote:
On Thu, Jan 30, 2014 at 01:02:15PM +1000, Peter Hutterer wrote:
On Wed, Jan 29, 2014 at 09:33:11PM +0100, Jonas Ådahl wrote:
Instead of automatically transforming absolute coordinates of touch and
pointer events to screen
On Thu, Jan 30, 2014 at 02:14:30PM -0800, Bill Spitzak wrote:
It is not clear from this discussion what support there will be for
mouse mode for the tablets.
A problem I have had with the current tablet api is that it is
designed for mapping the tablet to the bounding box surrounding all
Peter Hutterer wrote:
this has so many more cases where it won't work correctly from the user's
POV that it's likely easier to just have an easily accessible way of
switching between absolute and relative mode.
I really feel this automatic switch will work perfectly and would be a
huge
On Thu, Jan 30, 2014 at 6:31 PM, Bill Spitzak spit...@gmail.com wrote:
- When the compositor creates a shell_surface having the TOPLEVEL type,
it sets a numeral ID for it, and sends a map event to the desktop_shell
client ;
You must allow a toplevel to become a non-toplevel and
Hi Bill, and thanks a lot for sharing your thoughts,
You must allow a toplevel to become a non-toplevel and vice-versa
That's true ; the current implementation doesn't address this case.
My recommendation is that a surface has a parent that can be changed at
any time to any other surface or
Well, having read Jasper's comment, he has some valid points, the most
important being in my opinion :
it matches user expectations. If the user clicks minimize on a window,
they want it hidden
It the logic of what should *really* happen when a window is minimized is
implemented client-side,
On Thu, Jan 30, 2014 at 1:42 PM, Bill Spitzak spit...@gmail.com wrote:
Ping Cheng wrote:
graphics tablets:
* extended axis event support
* tool change notification (could be just button events? not sure)
Will tool id, serial number, and tool type be supported here?
Jasper St. Pierre wrote:
Hiding windows should not have any influence over the client, as many
desktop environments, including Weston, want to show live previews for
minimized or hidden windows in alt-tab or Expose-alikes.
Also, it matches user expectations. If the user clicks minimize on a
On Thu, Jan 30, 2014 at 8:48 PM, Bill Spitzak spit...@gmail.com wrote:
Jasper St. Pierre wrote:
Hiding windows should not have any influence over the client, as many
desktop environments, including Weston, want to show live previews for
minimized or hidden windows in alt-tab or
Manuel Bachmann wrote:
Hi Bill, and thanks a lot for sharing your thoughts,
GTK+ seems to have an impl, so I will check what it does.
I think it may be trying to use X window groups which is an example of
an excessively complex api to try to solve this. It has not worked and
Gimp is now
Jasper St. Pierre wrote:
A simple problem is a floating window shared by two main windows.
Can you give a concrete example of such a case? Not because I'm assuming
none exist, but because I want a specific example to evaluate and think
about.
A toolbox over a painting program that has
On Thu, Jan 30, 2014 at 9:03 PM, Bill Spitzak spit...@gmail.com wrote:
Jasper St. Pierre wrote:
A simple problem is a floating window shared by two main windows.
Can you give a concrete example of such a case? Not because I'm assuming
none exist, but because I want a specific example
Jasper St. Pierre wrote:
A toolbox over a painting program that has two documents open.
So, what is the expected behavior here exactly? There's a minimize
button on both of the content window's decorations, and clicking on one
should minimize all three windows?
Clicking minimize of
30 matches
Mail list logo
