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
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
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
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 testing window
From: Philip Withnall philip.withn...@collabora.co.uk
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
On Sun, 30 Dec 2012 16:29:09 -0800
Bill Spitzak spit...@gmail.com 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
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 the stacking order between windows from
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
On Tue, 17 Jan 2012 10:36:03 -0800
Bill Spitzak spit...@gmail.com 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
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
On Mon, 16 Jan 2012 19:14:20 -0800
Bill Spitzak spit...@gmail.com 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
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
, 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 professional software, especially stuff with Windows versions
On 16 September 2011 11:18, Giovanni Campagna scampa.giova...@gmail.com 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
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 (they removed that
built-in behavior
Rather than rant about it, here is my edit of the wl_shell protocol xml:
?xml version=1.0 encoding=UTF-8?
interface name=wl_shell version=?
enum name=window_part
entry name=none value=0/
entry name=top value=1/
entry name=bottom value=2/
entry name=left value=4/
...@gmail.com 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 Wed, Sep 14, 2011 at 12:13 PM, Bill Spitzak spit...@gmail.com 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
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-window complex
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 spit...@gmail.com 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
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 professional software, especially stuff with Windows versions,
every single
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 can also
force windows to be in layers by not obeying the window stacking order
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,
, 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 is not either the toolbar hid
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
25 matches
Mail list logo
