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 program?
Ex.
Giovanni Campagna wrote:
Why isn't transient for + window type (like _NET_WM_WINDOW_TYPE) enough?
Because it does not allow *MULTIPLE* parents.
In gimp if you have 2 image windows, you want the toolbars to remain
atop *BOTH* of them. This is not possible to describe with a single
"parent" f
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
dott...@gmail.com wrote:
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?
Yes
The main problem I have using GIMP is that when I focus a window, I
don't want to focus on a /window/, I want to focus on an /appl
Giovanni Campagna wrote:
Il giorno lun, 12/09/2011 alle 13.18 -0700, Bill Spitzak ha scritto:
There seems to be some confusion between negotiating the correct size
and the drawing of the frame. These are unrelated.
I mostly agree with your ideas of negotiating the size with both a
request f
Hello, I am Samuele. From Italy
Just an idea: (probably a crazy idea, but I don't know)
Why not to setup non-rectangular windows?
ie. windows with one or more buffers stacked in order.
Isn't true that:
This will handle the raised problem and still keep a simple concept of
wayland. ?
On Wed, Sep 1
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 of one) a
Il giorno lun, 12/09/2011 alle 13.18 -0700, Bill Spitzak ha scritto:
> There seems to be some confusion between negotiating the correct size
> and the drawing of the frame. These are unrelated.
>
> I mostly agree with your ideas of negotiating the size with both a
> request from the client->comp
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.
> >
> > In current window managers it
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 applica
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 by itsel
would it be to much trouble to make window management a proxy program?
Ex.
-
| appliation | -> | window manager | ->| display server |
-
and instead of figh
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 applications. For instan
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
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?
On Tue, Sep 13, 2011 at 11:13 PM, Bill Spitzak wrote:
> Alo
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
20 matches
Mail list logo
