Gregory Merchan wrote:
Viewport change as described by Bill:
W to A: Request activation.
A to W: Activate me and do these things, or don't activate me at all.
W to Z: (1) You are deactivated; (2) Nothing.
W to A: (1) You are activated (and by other events or by implication
everything is done.);
Gregory Merchan wrote:
>> re: glitches in pagers due to incorrect guessing of activated
surface by comnpositor
I think the API for marking surfaces transient or otherwise secondary
will obviate some potential glitches. For example, I think most
thumbnailing window switchers I've seen just i
On Tue, Nov 5, 2013 at 4:31 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>>> - The compositor can send a "activate request event" saying that it would
>>> like the client to activate.
>>
>>
>> That is not what I described, mostly because I kept the new things to
>> a minimum. It seems I hint
On Tue, Nov 5, 2013 at 1:47 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>> As before, I'm just laying it all out there. Brief summary:
>>
>> 1. All window management policies set focus without exception in
>> certain cases. (E.g. Alt+Tab, viewport changes.)
>
>
> No. All the compositor can
Gregory Merchan wrote:
- The compositor can send a "activate request event" saying that it would
like the client to activate.
That is not what I described, mostly because I kept the new things to
a minimum. It seems I hinted at but failed to explicitly mention what
serves much the same purpose
On Tue, Nov 5, 2013 at 12:36 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>>> No the client must be in control and decide it does *not* want to be
>>> activated.
>>
>>
>> "Sloppy focus, as a system-wide policy" refers to the list of 5
>> policies which I gave in my first message in this thre
Gregory Merchan wrote:
As before, I'm just laying it all out there. Brief summary:
1. All window management policies set focus without exception in
certain cases. (E.g. Alt+Tab, viewport changes.)
No. All the compositor can do is send a focus-request-event to the
client. The client is allowe
Gregory Merchan wrote:
No the client must be in control and decide it does *not* want to be
activated.
"Sloppy focus, as a system-wide policy" refers to the list of 5
policies which I gave in my first message in this thread. That is a
policy which does not allow clients such control. (Did I me
On Mon, Nov 4, 2013 at 4:44 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>> The only difference I understand between the active state and having
>> the keyboard focus is that a keyboard grab may take away the focus but
>> should not deactivate the window.
>
>
> Grabs don't change the keyboar
On Mon, Nov 4, 2013 at 3:41 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>> As Bill mentioned in a follow-up, drag sources would want to not activate.
>
>
>> This can be handled more simply than described above, without a
>> special "activate" system. I assume "activation" applies to a windo
Gregory Merchan wrote:
The only difference I understand between the active state and having
the keyboard focus is that a keyboard grab may take away the focus but
should not deactivate the window.
Grabs don't change the keyboard focus. Instead the client that did the
grab knows it has the key
Gregory Merchan wrote:
The beginning of a drag is not the only event which a client may deem
inappropriate for activation. A client, such as a drawing program,
with a free-floating palette would want for its primary window to
remain active when toggle buttons on the palette are clicked. A more
c
Jason Ekstrand wrote:
Here is the problem. Say you have two pointers P and Q and two and two
windows A and B. P clicks on A and A a is now active. Q clicks on B
and now B is active. Then P goes and clicks on B. However, B is
already active so it doesn't request an activation and A stays a
Jasper St. Pierre wrote:
But serials are seat-specific, so we need the "activate" request to
relay the seat back for the purposes of validating the timestamp. I
don't think it makes sense to expose the active window on wl_seat, though.
That is annoying. Is there any reason this is a requireme
Jason Ekstrand wrote:
1) Will we ever need a deactivate request? Under the given scheme, no
need comes immediately to mind.
I'm thinking this may be what clients want to do instead of "lower" when
a middle-mouse button in clicked on a window border (if you wish to act
like a lot of X window
Gregory Merchan wrote:
As Bill mentioned in a follow-up, drag sources would want to not activate.
This can be handled more simply than described above, without a
special "activate" system. I assume "activation" applies to a window,
not a client.
I believe you are describing the system I was
On Sat, Nov 2, 2013 at 11:02 AM, Jasper St. Pierre
wrote:
> On Sat, Nov 2, 2013 at 11:50 AM, Jason Ekstrand
> wrote:
>>
>> On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre
>> wrote:
>>>
>>> On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand
>>> wrote:
>>>
>>> ... snip
>>>
Gregory,
On Sat, Nov 2, 2013 at 11:50 AM, Jason Ekstrand wrote:
> On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre
> wrote:
>
>> On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand wrote:
>>
>> ... snip
>>
>>
>>> Gregory,
>>> Thank you very much for your e-mail. I think that helps a lot. The
>>> lack of c
On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre wrote:
> On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand wrote:
>
> ... snip
>
>
>> Gregory,
>> Thank you very much for your e-mail. I think that helps a lot. The lack
>> of code is ok because I think Rafael is planning to start implementing as
On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre
wrote:
> On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand
> wrote:
>
> ... snip
>
>>
>> Gregory,
>> Thank you very much for your e-mail. I think that helps a lot. The lack
>> of code is ok because I think Rafael is planning to start implementing
On Fri, Nov 1, 2013 at 10:58 PM, Jason Ekstrand wrote:
> On Fri, Nov 1, 2013 at 8:36 PM, Gregory Merchan
> wrote:
>>
>> On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand
>> wrote:
>> > On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak wrote:
>> >>
>> >> Jason Ekstrand wrote:
>> >>
>> >>> Yes, in theo
On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand wrote:
... snip
> Gregory,
> Thank you very much for your e-mail. I think that helps a lot. The lack
> of code is ok because I think Rafael is planning to start implementing as
> soon as things settle a bit. Sometimes protocol discussions can en
On Fri, Nov 1, 2013 at 8:36 PM, Gregory Merchan
wrote:
> On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand
> wrote:
> > On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak wrote:
> >>
> >> Jason Ekstrand wrote:
> >>
> >>> Yes, in theory they could read the configuration of the compositor.
> >>
> >>
> >>
On Fri, Nov 1, 2013 at 8:36 PM, Gregory Merchan
wrote:
> On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand
> wrote:
> > On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak wrote:
> >>
> >> Jason Ekstrand wrote:
> >>
> >>> Yes, in theory they could read the configuration of the compositor.
> >>
> >>
> >>
On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand wrote:
> On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak wrote:
>>
>> Jason Ekstrand wrote:
>>
>>> Yes, in theory they could read the configuration of the compositor.
>>
>>
>>> I really don't want to build this kind of inconsistency into the system
>>
Jason Ekstrand wrote:
I still don't understand why a client would want to not activate. I can
see not wanting to raise, but why not activate?
The main one I see is you do not want attempts to drag an object to
activate the drag-from client, since this may unmap the desired target
of the dra
On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak wrote:
> Jason Ekstrand wrote:
>
> Yes, in theory they could read the configuration of the compositor.
>>
>
> I really don't want to build this kind of inconsistency into the system
>> and I don't see why it's justified.
>>
>
> I think I see what yo
Jason Ekstrand wrote:
Yes, in theory they could read the configuration of the compositor.
I really don't want to build this kind of
inconsistency into the system and I don't see why it's justified.
I think I see what you are getting at. I think a scheme that allows
simple applications to
On Thu, Oct 31, 2013 at 12:42 AM, Jason Ekstrand wrote:
> Bill,
> Because I want to respond to everything in one e-mail, I'm going to try and
> address your comments here even though they may not show up.
>
> On Wed, Oct 30, 2013 at 3:19 PM, Rafael Antognolli
> wrote:
>>
>> Hi, I'm back to work o
Bill,
Because I want to respond to everything in one e-mail, I'm going to try and
address your comments here even though they may not show up.
On Wed, Oct 30, 2013 at 3:19 PM, Rafael Antognolli wrote:
> Hi, I'm back to work on this, hopefully this time in a
> non-intermittent way. Some comments b
Rafael Antognolli wrote:
I'm sorry, but I fail to understand how a user could choose between
click to focus, or sloopy focus, if that's up to the client to
implement it. Wouldn't this lead to something like: if I use this
video player A, but it only implements sloopy focus, and I want click
to f
Hi, I'm back to work on this, hopefully this time in a
non-intermittent way. Some comments below:
On Thu, Oct 24, 2013 at 12:00 AM, Bill Spitzak wrote:
> Jason Ekstrand wrote:
>
>> At this point, I think I can propose a solution which should allow for
>> client control while still keeping the com
Jason Ekstrand wrote:
At this point, I think I can propose a solution which should allow for
client control while still keeping the compositor in control:
1) The xdg_surface has a pare of activate/deactivate events. I think
we need more than keyboard focus here because the user may not have a
On Wed, Oct 23, 2013 at 03:20:52PM -0500, Jason Ekstrand wrote:
> On Tue, Oct 22, 2013 at 10:46 PM, Bill Spitzak wrote:
>
> > On 10/22/2013 05:59 PM, Jason Ekstrand wrote:
> >
> > I see what you mean here. However, I think apps doing this will cause
> >> more trouble than it's worth. One thing
On Tue, Oct 22, 2013 at 10:46 PM, Bill Spitzak wrote:
> On 10/22/2013 05:59 PM, Jason Ekstrand wrote:
>
> I see what you mean here. However, I think apps doing this will cause
>> more trouble than it's worth. One thing about current sloppy focus
>> implementations is that you can click anywher
On 10/22/2013 05:59 PM, Jason Ekstrand wrote:
I see what you mean here. However, I think apps doing this will cause
more trouble than it's worth. One thing about current sloppy focus
implementations is that you can click anywhere in the window to raise
it. You want to change this. However, w
On Tue, Oct 22, 2013 at 3:36 PM, Bill Spitzak wrote:
> Jason Ekstrand wrote:
>
> I think I would disagree on this one. As an avid sloppy-focus user, I
>> really don't want apps arbitrarily deciding that they are click-to-focus.
>> While some things (look and feel) are entirely cosmetic, if how
Jason Ekstrand wrote:
I think I would disagree on this one. As an avid sloppy-focus user, I
really don't want apps arbitrarily deciding that they are
click-to-focus. While some things (look and feel) are entirely
cosmetic, if how apps get focus is app-dependent, it will drive users
crazy.
On Thu, Oct 17, 2013 at 12:32 PM, Bill Spitzak wrote:
> On 10/15/2013 10:53 PM, Kristian Høgsberg wrote:
>
> - transient for shouldn't take position.
>>
>
> What? I think that is necessary. It is relative to the parent surface.
>
>
> - New keyboard focus protocol: instead of active su
On 10/15/2013 10:53 PM, Kristian Høgsberg wrote:
- transient for shouldn't take position.
What? I think that is necessary. It is relative to the parent surface.
- New keyboard focus protocol: instead of active surface meaning
"has keyboard focus" we need something that works in a t
On Wed, Oct 16, 2013 at 2:53 AM, Kristian Høgsberg wrote:
> On Tue, Oct 15, 2013 at 8:05 AM, wrote:
>> From: Rafael Antognolli
>>
>> These functions only differ from the previous one because they request
>> that the given state is set, without changing the surface type, thus
>> removing any pre
On Tue, Oct 15, 2013 at 8:05 AM, wrote:
> From: Rafael Antognolli
>
> These functions only differ from the previous one because they request
> that the given state is set, without changing the surface type, thus
> removing any previously state that was set on it.
>
> Both states can be used at t
From: Rafael Antognolli
These functions only differ from the previous one because they request
that the given state is set, without changing the surface type, thus
removing any previously state that was set on it.
Both states can be used at the same time, and the states can be set or
unset indep
From: Rafael Antognolli
These functions only differ from the previous one because they request
that the given state is set, without changing the surface type, thus
removing any previously state that was set on it.
Both states can be used at the same time, and the states can be set or
unset indep
44 matches
Mail list logo
