Hey,
On Fri, 2013-12-20 at 10:51 -0800, Kristian Høgsberg wrote:
> I guess I never replied to you like I usually do when I merge patches,
> but I commited your patches Dec 2nd. If you have a few spare cycles,
> could you have a look at this bug that look like stacking regressions
> from those pat
Hi Philip,
I guess I never replied to you like I usually do when I merge patches,
but I commited your patches Dec 2nd. If you have a few spare cycles,
could you have a look at this bug that look like stacking regressions
from those patches:
https://bugs.freedesktop.org/show_bug.cgi?id=72547
tha
On Mon, 2013-12-02 at 15:22 -0800, Kristian Høgsberg wrote:
> But we need to wait for Rafaels xdg-shell patches to land first.
How far away from landing are they?
Regardless of how far away they are, would it make sense to commit some
of the more self-contained patches from my patchset (such as p
On Mon, Nov 25, 2013 at 06:01:29PM +, Philip Withnall wrote:
> Here’s a series of patches which work towards improving the shell window
> stacking. They clean up the code and implement a more organised approach to
> stacking. They add a new test client, weston-stacking, for testi
From: Philip Withnall
This ensures transient surfaces are included in the layer of their
parent, even if the parent later changes layers. It achieves this by
recursively changing the layers of all children of a surface when that
surface’s layer is changed. The recursion is unbounded unless transi
Here’s a series of patches which work towards improving the shell window
stacking. They clean up the code and implement a more organised approach to
stacking. They add a new test client, weston-stacking, for testing window
stacking and ordering.
I don’t claim the ordering they impose is
our hands with it, I agree.
My main concern is that if you add "layers" it will defer attempts to
really fix window stacking. I would prefer the hard and more important
problem be done first.
Any public stacking protocol cannot have references to other clients'
windows. Juggling
On Sun, 30 Dec 2012 16:29:09 -0800
Bill Spitzak wrote:
> Not sure how useful this is, but I made a graph showing the necessary
> window transitions that Wayland should support, in an attempt to show
> why "layers" are not sufficient.
>
> In this example window C must always remain above window
Not sure how useful this is, but I made a graph showing the necessary
window transitions that Wayland should support, in an attempt to show
why "layers" are not sufficient.
In this example window C must always remain above windows A and B, but
there is no other restrictions. There are 8 possib
Pekka Paalanem thought this text that I sent was a better description of
design goals for window stacking:
* Client must make the final decision about raising. This is a
requirement so that drag & drop can be implemented, as dragging an
object must not raise the window it is in, and only
Bill Spitzak wrote:
Pekka Paalanen suggested I come up with a design for the Wayland
compositor to control window stacking and raising.
This is a new version of the proposal, including his ideas for full
screen atomic raise+resize:
COMPOSITOR BEHAVIOR:
The compositor never reorders
Pekka Paalanen wrote:
Unmapped surfaces never occlude anything, since they are invisible. In
your case, if you first raise W, then map B, you might see a full W,
and then B appearing on top of it. No any other surface content can
flash inside W. Is the temporary showing of full W before B appear
On Tue, 17 Jan 2012 10:36:03 -0800
Bill Spitzak wrote:
> On 01/17/2012 02:32 AM, Pekka Paalanen wrote:
>
> > I think we already have the unmapped feature. In Wayland terms:
> >
> > 1. A client creates a surface.
> > The surface is initially unmapped, and not visible.
> >
> > 2. The client se
On 01/17/2012 02:32 AM, Pekka Paalanen wrote:
I think we already have the unmapped feature. In Wayland terms:
1. A client creates a surface.
The surface is initially unmapped, and not visible.
2. The client sets the window type (role) of the surface.
Still nothing visible happe
On Mon, 16 Jan 2012 19:14:20 -0800
Bill Spitzak wrote:
> Pekka Paalanen suggested I come up with a design for the Wayland
> compositor to control window stacking and raising.
Thank you for writing down your ideas.
> I am pretty familiar with the failures of existing window mana
Pekka Paalanen suggested I come up with a design for the Wayland
compositor to control window stacking and raising.
I am pretty familiar with the failures of existing window management in
this area and would certainly like to see Wayland do this correctly, and
not copy the mistakes of the
> a
>> > need for client-side window stacking and mapping.
>> >
>> > In current window managers it is almost impossible to make multiple-window
>> > complex applications. For instance the Gimp has been forced to abandon this
>> > idea. And in professi
Rather than rant about it, here is my edit of the wl_shell protocol xml:
lex than the simple api that lets a client
get exactly the window stacking and positioning it wants.
In addition you seem to think the compositor can raise windows
arbitrarily, such as on clicks. DO NOT DO THIS! Look at the history
and you will see they realized this was wrong in X10 (t
On 16 September 2011 11:18, Giovanni Campagna wrote:
>
>> Sorry, I also assume any "task manager" will just be part of the
>> compositor process. The problem is that the user of the "task manager"
>> probably wants an icon in there that says "GIMP" even though there are
>> perhaps 2 image windows
; > Btw, at the desktop summit, there was a talk comparing the UI of Gimp
> > with that of Inkscape, and the blaming of the multiple window paradigm
> > had nothing to do with stacking,
>
> Bull. Every single complaint was about window stacking. I challenge you
> to list a s
ing described.
Btw, at the desktop summit, there was a talk comparing the UI of Gimp
with that of Inkscape, and the blaming of the multiple window paradigm
had nothing to do with stacking,
Bull. Every single complaint was about window stacking. I challenge you
to list a single complaint that i
Michal Suchanek wrote:
Doing your own window management is not nice, though. It forces the
user to manage the windows of that particular application in a
different way because many window management functions are performed
by the window manager using key or button shortcuts, the decorations,
etc
uesting
that window a (belonging to the client) be placed above/below window b
(which can be None or a client or other window). None is the most
useful. Compositors could also provide place-holder invisible windows so
a client can indicate what "layer" a window is in (compositors ca
al software, especially stuff with Windows versions,
>> > every single program has resorted to a single "tiled" window that fills the
>> > screen.
>> >
>> > There may be reasons to not have such applications, but one reason was that
>> > it was vir
Il giorno mer, 14/09/2011 alle 21.56 +0800, Sam Spilsbury ha scritto:
> On Wed, Sep 14, 2011 at 12:13 PM, Bill Spitzak wrote:
> > Along with all the discussion about client-side decorations, there is also a
> > need for client-side window stacking and mapping.
> >
> >
Il giorno mar, 13/09/2011 alle 21.13 -0700, Bill Spitzak ha scritto:
> Along with all the discussion about client-side decorations, there is
> also a need for client-side window stacking and mapping.
>
> In current window managers it is almost impossible to make
> multiple
On Wed, Sep 14, 2011 at 8:07 PM, Michal Suchanek
> Of course, if Wyaland finally grows a separate windowmanager and
> provides it as a module for applications to use for managing their own
> windows then it can be done either way.
>
Yes, window-in-window MDI has always been an area of challenge fo
On Wed, Sep 14, 2011 at 12:13 PM, Bill Spitzak wrote:
> Along with all the discussion about client-side decorations, there is also a
> need for client-side window stacking and mapping.
>
> In current window managers it is almost impossible to make multiple-window
> complex ap
On 14 September 2011 13:43, cat wrote:
> this might be a question more for these programs than for this list,
> but how can one of these programs handle the full desktop realestate?
> wouldn't that itself force the same condition that you have with the
> rogram being a single window?
Well, if the
wrote:
> Along with all the discussion about client-side decorations, there is also a
> need for client-side window stacking and mapping.
>
> In current window managers it is almost impossible to make multiple-window
> complex applications. For instance the Gimp has been forced to abandon
On 14 September 2011 13:18, wrote:
>
>
>> all the windows displayed by the compositor are in a single list that
>> defines their stacking order
>
> Excuse me, I'm just a bystander, but is this list you speak of a list of
> all the windows registered by all of the connected clients?
>
> The main p
> all the windows displayed by the compositor are in a single list that
> defines their stacking order
Excuse me, I'm just a bystander, but is this list you speak of a list of
all the windows registered by all of the connected clients?
The main problem I have using GIMP is that when I focus a win
Along with all the discussion about client-side decorations, there is
also a need for client-side window stacking and mapping.
In current window managers it is almost impossible to make
multiple-window complex applications. For instance the Gimp has been
forced to abandon this idea. And in
34 matches
Mail list logo
