Any proposal must merge in the fullscreen/maximized stuff which is
really an instruction to remove decorations as well.
I see no reason for clients to request whether they "prefer" csd. CSD
will always be better, the only reason to "prefer" ssd is because the
client can't do it, and you alread
And as I explained on IRC, I don't want this in an initial dump. The
motivation of this xdg_shell approach is to keep it small and land it now.
We can add functionality later, but I'd rather not spend too much time in
heated discussions on the list about client-side vs. server-side
decorations.
If
Hello,
There has been some discussions on IRC about the possible support of
decoration side negociation in xdg_shell.
A client would have to support CSD if it uses xdg_shell.
And I suggested the folowing mechanism:
.when binding to xdg_shell,
the client gets an event telling him the compositor
Hi Bill and Gregory,
So, I talked to Kristian and Jasper on IRC, and we decided to follow a
simpler route, of just adding what is strictly necessary for us right
now. I'm going to send another protocol xml proposal again, on a
following email, but this time without the activate/deactivate part, or
Hi Bill and Gregory,
So, I talked to Kristian and Jasper on IRC, and we decided to follow a
simpler route, of just adding what is strictly necessary for us right
now. I'm going to send another protocol xml proposal again, on a
following email, but this time without the activate/deactivate part, or
I failed to reply to all. I hope copying and pasting hasn't messed up anything.
On Thu, Nov 7, 2013 at 3:32 AM, Rafael Antognolli
wrote:
> Hello all,
>
> Following is the same description as in my previous wrong email, but with the
> correct patch attached.
>
> I'm trying to summarize part of the
Rafael Antognolli wrote:
So, I added "activated" and "deactivated" events, that the compositor can use
to inform clients what they are. And there's a take_focus request
Shouldn't that be called a "take_active" request?
I can think of scenarios where it would be useful to get the keyboard
foc
Hello all,
Following is the same description as in my previous wrong email, but with the
correct patch attached.
I'm trying to summarize part of the discussion in this new patch, but it's not
the final one.
As far as I understood, the goal is to end up with something like this for
keyboard focus
Please, ignore this email, apparently I sent the wrong thing (too sleepy now).
I'll send it again tomorrow.
On Thu, Nov 7, 2013 at 12:45 AM, Rafael Antognolli
wrote:
> Hello all,
>
> I'm trying to summarize part of the discussion in this new patch, but it's not
> the final one.
>
> As far as I u
Hello all,
I'm trying to summarize part of the discussion in this new patch, but it's not
the final one.
As far as I understood, the goal is to end up with something like this for
keyboard focus:
W = compositor
A, Z = client surfaces
Viewport change:
W to Z: You are deactivated.
W to A: You are
10 matches
Mail list logo
