On Fri, 03 Nov 2023 09:33:10 -0700, Wayne Sherman wrote:
> Is a unified approach for window management in the Wayland ecosystem needed?
> (i.e how can the end user or system designer control the size,
> position, and layer of top level application windows).
I certainly see the use
On Fri, Nov 3, 2023 at 9:33 AM Wayne Sherman wrote:
> Certain applications and workflows...can greatly benefit from having
> a measure of control over their window geometry and stacking.
There are many use cases for this. A few of mine are:
Digital Signage
Video outputs on the digital signage "
Is a unified approach for window management in the Wayland ecosystem needed?
(i.e how can the end user or system designer control the size,
position, and layer of top level application windows).
Wayland's design emphasizes security, simplicity, and a clear
separation of responsibilities be
I don't quite understand the need, want, or mechanism for this.
For high performance or VR systems where context switch overhead would be
too much (and I don't believe this, since they tend to use separate
acceleration chips for real-time work), the answer would not be to move
from userspace to th
Hi.
On 29.12.15 20:09, Dimitri Nüscheler wrote:
Hello everyone
I sometimes wonder where people talk about concept level and philosophy.
At least Wayland has a big philosophy part - and it uses it to explain
itself in contrast to X.
I'm not much involved into it, but I think I understand some vi
ically results in a very primitive form of kernel level window
management that is controlled by the (Wayland) compositor.
I created this in response to a blog post of Martin Grässlin, but I was
unheard by the crowd - so maybe this is the better address here.
Not sure if that would ever be nee
couple of things have been bugging me and I thought I might give my
> thoughts on them. I'll post separate emails as to not mix topics.
>
> Problem 1 window management.
>
> There has been a lot of discussion on window management (minimise,
> maximise, etc) and some attempt
t;
> A couple of things have been bugging me and I thought I might give my
> thoughts on them. I'll post separate emails as to not mix topics.
>
> Problem 1 window management.
>
> There has been a lot of discussion on window management (minimise,
> maximise, etc) and some attempt
I'll post separate emails as to not mix topics.
Problem 1 window management.
There has been a lot of discussion on window management (minimise,
maximise, etc) and some attempts at a solutions.
I had some thoughts on the matter, be chose to stay silent because a)
There are people that know
On Wed, Sep 14, 2011 at 11:19 PM, Michal Suchanek wrote:
> Hello,
>
> On 14 September 2011 16:55, cat wrote:
>> would it be to much trouble to make window management a proxy program?
>
> The wayland server has to know how the windows stack but the clients
> are not tr
Michal Suchanek wrote:
Still the clients should not know about the windows of other clients
so they would not know how their windows stack and not knowing that
they can't really decide it either.
I don't think the clients will know about any windows other than a few
ids that the compositor te
-- Forwarded message --
From: cat
Date: Thu, Sep 15, 2011 at 7:27 AM
Subject: Re: seprate window management component
To: Michal Suchanek
On Thu, Sep 15, 2011 at 4:03 AM, Michal Suchanek wrote:
> On 14 September 2011 18:21, cat wrote:
>> well if clients are allowed
On 14 September 2011 18:21, cat wrote:
> well if clients are allowed to decide how their own windows stack, the
> window management proxy would be in control.
>
> the idea I have is that there isn't any special protocol changes
> (though that might be bad for this system)
On 15/09/11 04:33, Michal Suchanek wrote:
On 14 September 2011 20:26, Bill Spitzak wrote:
I think the idea is that what you are calling the "window manager" is in
fact a library running in the client process and memory space. It would
probably be part of the toolkit.
Which is utterly wrong.
On 14 September 2011 20:26, Bill Spitzak wrote:
> I think the idea is that what you are calling the "window manager" is in
> fact a library running in the client process and memory space. It would
> probably be part of the toolkit.
>
Which is utterly wrong.
1) you can't deal with clients malfunc
I think the idea is that what you are calling the "window manager" is in
fact a library running in the client process and memory space. It would
probably be part of the toolkit.
cat wrote:
would it be to much trouble to make window management a proxy p
well if clients are allowed to decide how their own windows stack, the
window management proxy would be in control.
the idea I have is that there isn't any special protocol changes
(though that might be bad for this system), but because of the proxy,
a call to or a response from (or lack o
Hello,
On 14 September 2011 16:55, cat wrote:
> would it be to much trouble to make window management a proxy program?
The wayland server has to know how the windows stack but the clients
are not trusted to tell it how the windows should stack so either the
server has to figure that out
would it be to much trouble to make window management a proxy program?
Ex.
-
| appliation | -> | window manager | ->| display server |
-
and inst
On 19/05/11 04:17, Bill Spitzak wrote:
Michal Suchanek wrote:
In the case of a resize event the response includes submitting a
buffer containing resized window content to the compositor.
The compositor requires this new resized content to draw the window so
it cannot be avoided.
I think the
El dc 18 de 05 de 2011 a les 11:17 -0700, en/na Bill Spitzak va
escriure:
> Michal Suchanek wrote:
>
> [...] I think there is also a
> problem in that the compositor cannot be absolutely certain that a given
> resize is in response to a resize request.
It doesn't need to, as it makes no differe
Michal Suchanek wrote:
In the case of a resize event the response includes submitting a
buffer containing resized window content to the compositor.
The compositor requires this new resized content to draw the window so
it cannot be avoided.
I think the concern was when a client decided that t
On 17 May 2011 18:01, Sam Spilsbury wrote:
>> I think the wayland compositor could track how long the clients take to
>> respond to events. They would only disable if they suddenly took several
>> times longer than before. If the recorded lag exceeds a threshold the
>> compositor could resort to r
> I think the wayland compositor could track how long the clients take to
> respond to events. They would only disable if they suddenly took several
> times longer than before. If the recorded lag exceeds a threshold the
> compositor could resort to rubber-band resize.
What is a "response to an ev
On 16 May 2011 23:13, Bill Spitzak wrote:
> Michal Suchanek wrote:
>
>> The thing is that in Wayland the server is not aware of any remote vs
>> local windows. Remote applications are in no way part of the protocol
>> and will supposedly sneak in later by means of some remoting proxy.
>
> My under
Michal Suchanek wrote:
The thing is that in Wayland the server is not aware of any remote vs
local windows. Remote applications are in no way part of the protocol
and will supposedly sneak in later by means of some remoting proxy.
My understanding is the exact opposite: the compositor is *VERY
William Swanson wrote:
Expanding the window leaves unpainted
background clearly visible for about 3/4 second during updates.
Windows unfortunatly draws into a single buffer that the compositor is
using, so you still see partial updates like this. They may be unable to
avoid this as the api
be some other effect but either way
>> you need something to draw on the screen until the client performs the
>> update which will draw a "not fully updated window" in case the client
>> does not update fast enough and by some is "unacceptable in wayland".
>
Em 13-05-2011 15:38, Michal Suchanek escreveu:
If the client takes, say, half a second to update which is completely
reasonable for a full re-layout and repaint of a window that normally
gets only partial updates then the resize will be *very* jerky, and if
the client is uploading a bitmap over n
Many people have strong opinions about client side window decorations.
I would like to introduce some facts. Specifically, how does Windows
7, a widely-used desktop OS with client-side decorations, handle
things?
Unresponsive applications:
I created a test program with a "crash" button and a stand
The only *generally acceptable* way to manage lags in communication I
see is that the server *fades-out* the window in question to signal that
the client is unresponsive and waits for it to respond in a time before
the kill-dialog appears. This is a good standard that doesn't need
hacks or special
unacceptable in wayland".
A rubber band resize is part of the window management design and is not
a partial update, any more than the mouse cursor atop a window means it
is not fully updated. The image is fully expected to appear when the
user drags the mouse.
A rubber band that appears aft
On 13 May 2011 22:14, Elijah Insua wrote:
>
> On May 13, 2011, at 4:02 PM, Casey Dahlin wrote:
>
>> On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote:
>>> On 13 May 2011 11:26, Daniel Stone wrote:
On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote:
> You can't
On May 13, 2011, at 4:02 PM, Casey Dahlin wrote:
> On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote:
>> On 13 May 2011 11:26, Daniel Stone wrote:
>>> On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote:
You can't expect that every single client is high-priority an
On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote:
> On 13 May 2011 11:26, Daniel Stone wrote:
> > On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote:
> >> You can't expect that every single client is high-priority and lag-free.
> >
> > Run better clients, then? Or stop
On Fri, May 13, 2011 at 08:44:23PM +0200, Michal Suchanek wrote:
> Again, do you really know only one transition between two frames - flashing?
>
> With all the effects compositors are capable of today this is the only
> thing you can think of?
>
Fade to corruption? That just means crap is onscr
Alright - who can think of a good enough excuse for a real-world
application to not use a separate GUI/event thread? Even in a
pathologically latency-ridden environment, I'm quite certain that in 1
second the event-handling thread could get a timeslice to respond that
it's alive.
Mak
2011/5/13 Ru
2011/5/13 Rui Tiago Cação Matos :
> On 13 May 2011 18:59, Mike Paquette wrote:
> Completely agree. The compositor/WM has no business in working around
> application bugs. If application programmers are lazy and can't get
> their windows acting timely on input then, the ecosystem (users,
> distrib
On 13 May 2011 19:45, Corbin Simpson wrote:
> I was trying to stay out of this, but...
>
> On Fri, May 13, 2011 at 9:03 AM, Michal Suchanek wrote:
>> This is *not* *about* *optimization*. If you rely on *every* *single*
>> *client* to be responsive for your WM to work then the moment *any*
>> *s
On 13 May 2011 18:59, Mike Paquette wrote:
> I hope you guys don't mind my chiming in here.
Speaking only for myself as mostly a lurker on this list, I very much
welcome your insightful and experienced remarks. Thanks for sharing!
> The way I handled a window resize was to grow or shrink the win
I hope you guys don't mind my chiming in here.
The way I handled a window resize was to grow or shrink the window buffer and
onscreen region as requested by the client, mark it as invalid, and hold off
on compositing it until the app indicated the buffer was valid, or had good
content again.
I was trying to stay out of this, but...
On Fri, May 13, 2011 at 9:03 AM, Michal Suchanek wrote:
> This is *not* *about* *optimization*. If you rely on *every* *single*
> *client* to be responsive for your WM to work then the moment *any*
> *single* *client* becomes unresponsive your WM *breaks*
This will pretty quickly result in toolkits, or at least app skeletons, doing
something like:
(void)max_unresponsive_time(MAX_DOUBLE);
I had an 'automatic wait cursor' feature in a window system I did, which when
an app failed to process pending events for a few seconds, would automatic
Michal Suchanek wrote:
Yes: it handles all resizing uniformly badly. It's pretty horrible.
So you can see the background color of clients that are slow to
repaint. Oh, how painful.
Yes, that is UNACCEPTABLE! Get it through your head that the intention
of Wayland is so that Linux stops lo
On 13 May 2011 17:25, Daniel Stone wrote:
> Hi,
>
> On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote:
>> However, window resizes need to be responsive otherwise you introduce
>> lag, possibly to the point that the person moving the mouse has no
>> clue what is going on the moment a
Hi,
On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote:
> However, window resizes need to be responsive otherwise you introduce
> lag, possibly to the point that the person moving the mouse has no
> clue what is going on the moment a window resize is initiated.
Sure.
> Lag is someth
On 13 May 2011 11:26, Daniel Stone wrote:
> On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote:
>> You can't expect that every single client is high-priority and lag-free.
>
> Run better clients, then? Or stop trying to micro-optimise for the case
> of pressing the close button on an
Indeed. But how about this: the client sends the compositor a hint
stating its maximum unresponsiveness interval, and sends keep-alive
messages when idle. If the app doesn't respond in time, and the user
tries to interact with it, the compositor can offer to kill it (or
something).
Mak
On Fri, Ma
On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote:
> You can't expect that every single client is high-priority and lag-free.
Run better clients, then? Or stop trying to micro-optimise for the case
of pressing the close button on an unresponsive client?
Cheers,
Daniel, who wants the
process
- the client is remote and therefore resizing it will take some time
whatever you do
If Wayland can't deal with any of the above it's junk.
The window management functions should be working without lag so long
as the window manager and Wayland server have enough resources and
On 11 May 2011 20:25, Bill Spitzak wrote:
> Michal Suchanek wrote:
>
>> Moves and resizes implemented in the client can't work well.
>
> Any resize solution that does not allow an atomic on-screen update of a
> window to it's new size, with the resized decorations and contents, is
> unacceptable.
Michal Suchanek wrote:
Moves and resizes implemented in the client can't work well.
Any resize solution that does not allow an atomic on-screen update of a
window to it's new size, with the resized decorations and contents, is
unacceptable. The whole point of Wayland is that the user NEVER s
cat wrote:
If I understand the proposal correctly this shouldn't be a problem. If
the application becomes unresponsive the server has the ability to
manage it (move, resize, raise, lower, possibly hide/show, and an option
to kill it) and it knows if it didn't respond to events.
I do think t
rotocol. I tried to document what I believe
> but
> > has never been really stated for Wayland.
> >
> > Main addition I made without previous knowledge was the parent and the
> task
> > objects (so that a task manager client can figure out what to display),
> and
>
> something the UI is not going to be handled.
>
> Perhaps a compromise could be a wayland-client.so lib that
> all compliant Wayland applications must link to at runtime
> and it provides consistant window management functionality.
For that to work the library would have to create an UI th
ient.so lib that
all compliant Wayland applications must link to at runtime
and it provides consistant window management functionality.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
(so that a task manager client can figure out what to display), and
> the window management events (rather than try to guess what happens based on
> movements of the windows, which seemed to be what was planned for Wayland).
>
>> Anyway, for decorations and tiling window managers, be
from the XML description of the protocol. I tried to document what I
believe but has never been really stated for Wayland.
Main addition I made without previous knowledge was the parent and the
task objects (so that a task manager client can figure out what to
display), and the window manag
On Tue, May 10, 2011 at 8:35 PM, Bill Spitzak wrote:
> With all the discussion about client side decorations, I thought I would try
> to write how window management could actually be done in Wayland. This is a
> really serious attempt to get the simplest system I could come up with,
>
With all the discussion about client side decorations, I thought I would
try to write how window management could actually be done in Wayland.
This is a really serious attempt to get the simplest system I could come
up with, while still allowing for some of the legitimate gripes, in
particular
60 matches
Mail list logo
