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 on
On Thu, Jan 30, 2014 at 9:03 PM, Bill Spitzak 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 to evaluat
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 t
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
On Thu, Jan 30, 2014 at 8:48 PM, Bill Spitzak 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 Expose-alikes.
>>
>> Al
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 1:42 PM, 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'
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, t
I've been thinking about how to add a device configuration interface to
libinput, and after getting feedback from Jonas and Benjamin, here's a
proposal (no code yet).
First, I think the configuration should be feature-specific, not device
specific, so it is independent of a classification or capab
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
On Thu, Jan 30, 2014 at 6:31 PM, Bill Spitzak 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 vice-versa,
>
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 improv
- 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 vice-versa,
otherwise useful api for rearranging windows is impossible. My
reco
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 a
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 scree
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 e
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 the outputs.
"mouse mode" simply means that the movement is relat
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?
>
>
On Thu, Jan 30, 2014 at 10:30:40AM -0800, Ping Cheng wrote:
> On Tue, Jan 28, 2014 at 6:18 PM, Peter Hutterer
> wrote:
>
> > 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
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 Tue, Jan 28, 2014 at 6:18 PM, Peter Hutterer wrote:
> 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% of the
> user base.
>
>
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 e
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
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
From: Emilio Pozuelo Monfort
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 fix it without regressing other s
From: Emilio Pozuelo Monfort
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 unrelated surfaces
being drawn
From: Emilio Pozuelo Monfort
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 b/desktop-shell/shell.c
index 30bd273..3087
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 doin
On Thu, 2014-01-30 at 13:34 +0200, Pekka Paalanen wrote:
> On Thu, 30 Jan 2014 10:32:03 +0100
> Iago Toral 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 proc
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 whi
On Thu, 30 Jan 2014 10:32:03 +0100
Iago Toral 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 widget/surfa
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
>>>
>>> Unfocusing a surface should dim it when dim-layer is enabled,
>>> but this got
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 various
33 matches
Mail list logo
