On Mon, Mar 25, 2013 at 12:24 PM, Bill Spitzak wrote:
> Jason Ekstrand wrote:
>
>> One more thing before I go onto the technical details: Bill Spitzak.
>> Just because he gets on your nerves doesn't mean you should just
>> ignore him.
>
>
> Thanks but I think my email was pretty rambling and I sho
Jason Ekstrand wrote:
One more thing before I go onto the technical details: Bill Spitzak.
Just because he gets on your nerves doesn't mean you should just
ignore him.
Thanks but I think my email was pretty rambling and I should not have
sent it. Can try to say what I wanted in a *short* way:
On Sat, 23 Mar 2013 15:58:29 -0500
Jason Ekstrand wrote:
> Scott,
> I have a few technical comments to make down below. Before I go onto
> those, I want to make sure we are perfectly clear about the purpose of
> this discussion. So please read the following through (multiple times
> if needed)
Hi Jason,
On Sat, Mar 23, 2013 at 2:58 PM, Jason Ekstrand wrote:
> Scott,
> I have a few technical comments to make down below. Before I go onto
> those, I want to make sure we are perfectly clear about the purpose of
> this discussion. So please read the following through (multiple times
> if
Scott,
I have a few technical comments to make down below. Before I go onto
those, I want to make sure we are perfectly clear about the purpose of
this discussion. So please read the following through (multiple times
if needed) before going on to the technical bits.
The Wayland project is primar
On Fri, Mar 22, 2013 at 7:09 PM, Bill Spitzak wrote:
> The underlying problem is that if a window is full-screen or maximized, and
> you minimize it, then un-minimize should put it back to full-screen or
> maximized. Thus un-minimize cannot be the "normal" state.
>
> The compositor could track the
The underlying problem is that if a window is full-screen or maximized,
and you minimize it, then un-minimize should put it back to full-screen
or maximized. Thus un-minimize cannot be the "normal" state.
The compositor could track the previous state and set that but then the
client can't chan
Hi Pekka, thanks for your comments here.
>
> Scott,
>
> do you mean that these unminimize, unmaximize, etc. requests would
> actually work like undo? Unmaximize would undo what the last
> maximization did, as opposed to just set_normal which might do
> something slightly different since its aim is
On Wed, 20 Mar 2013 22:06:22 -0600
Scott Moreau wrote:
> Hi Jason,
>
> On Wed, Mar 20, 2013 at 7:56 PM, Jason Ekstrand wrote:
> >
> > There is one more question that I think needs to be answered. And
> > that is: do we handle things in terms of set/unset or in terms of
> > set_maximized, set_f
I think (though certainly have not proven) that the current "commit"
mechanism will work for this. The client connects surfaces together into
a tree, and when a change is made to a surface the compositor does not
display the new version until a "commit" is done on either it or a
parent surface.
Hi Jason,
On Thu, Mar 21, 2013 at 9:39 AM, Jason Ekstrand wrote:
> Hi Scott,
>
>> One important thing to note here is that client != surface. In fact,
>> clients can have multiple surfaces. We might need to keep this in mind
>> for things like closing single surfaces demonstrated here
>> https://
Hi Scott,
> One important thing to note here is that client != surface. In fact,
> clients can have multiple surfaces. We might need to keep this in mind
> for things like closing single surfaces demonstrated here
> https://github.com/soreau/wayland/commit/65f8a3f5f683c3a91913a26496cc373633f01896
Hi Jason,
On Wed, Mar 20, 2013 at 7:56 PM, Jason Ekstrand wrote:
> Scott et. al,
> I'm not going to try and answer everything because a lot has happened
> on this topic and I think we're on the same page on most of the
> technical details.
>
>
>>> Here is how I think I would have such a protocol
Bill,
> The API must be designed so that no composite other than the initial and
> final is ever produced, even for a split second, for each of these
> transitions. By "other composite" I mean any different stacking order or any
> where the set of visibility of surfaces is different.
I think this
Scott et. al,
I'm not going to try and answer everything because a lot has happened
on this topic and I think we're on the same page on most of the
technical details.
>> Here is how I think I would have such a protocol work. (Perhaps this
>> is what you intend, but, like I said, it's kind of hard
Hi,
just a fly-by comment from the sickbed here (well, recovering already).
On Mon, 18 Mar 2013 14:24:17 -0600
Scott Moreau wrote:
> Yes and again, I would like to thank you for taking the time out to
> address this. I now have a couple of other outstanding cases I would
> like to introduce to
On Mon, Mar 18, 2013 at 3:29 PM, Bill Spitzak wrote:
> Scott Moreau wrote:
>
>> Note to Bill Spitzac: I find your posts to be often frivolous and
>> incoherent. I don't mean to be rude here but I have tried to consider
>> many of your points and you often go on long tangents about some
>> problem
Scott Moreau wrote:
Note to Bill Spitzac: I find your posts to be often frivolous and
incoherent. I don't mean to be rude here but I have tried to consider
many of your points and you often go on long tangents about some
problem that doesn't exist in reality or a highly isolated use case.
Many t
Hi Jason,
First I'd like to thank you for your attention to this matter. I have
been looking for someone to address this series so I can bounce ideas
around and discuss this. There are many interesting possibilities
here. You hit many points dead-on. Comments below.
On Mon, Mar 18, 2013 at 1:10 P
Scott,
Allow me to be a bit more specific as to what I am thinking. In
general, I like the requests and events in the protocol, I just think
things should be set out more clearly. The documentation given in the
protocol isn't terribly specific as to how someone is supposed to
implement it. From
Hi Jason,
Thanks for your reply.
On Sun, Mar 17, 2013 at 7:24 PM, Jason Ekstrand wrote:
> On Fri, Mar 8, 2013 at 4:39 PM, Scott Moreau wrote:
>>
>>
>> On Fri, Mar 8, 2013 at 3:28 PM, Bill Spitzak wrote:
>>>
>>> Scott Moreau wrote:
>>>
"Further, the term minimize is relatively subjective a
On Fri, Mar 8, 2013 at 4:39 PM, Scott Moreau wrote:
>
>
> On Fri, Mar 8, 2013 at 3:28 PM, Bill Spitzak wrote:
>>
>> Scott Moreau wrote:
>>
>>> "Further, the term minimize is relatively subjective and defined by the
>>> implementation. Clients should not expect that minimized means the
>>> surface
On Fri, Mar 8, 2013 at 3:28 PM, Bill Spitzak wrote:
> Scott Moreau wrote:
>
> "Further, the term minimize is relatively subjective and defined by the
>> implementation. Clients should not expect that minimized means the surface
>> will be invisable to the user. There are several use cases where
Scott Moreau wrote:
"Further, the term minimize is relatively subjective and defined by the
implementation. Clients should not expect that minimized means the surface
will be invisable to the user. There are several use cases where displaying
minimized surfaces will be useful."
Minimize can be
Scott Moreau wrote:
> I don't know what you're talking about here but please see the comment
> in the last paragraph of the commit message:
>
The concern is exactly the same as for any subsurfaces and for child
floating windows.
The specific example is a client has any number of "main" surfac
On Fri, Mar 8, 2013 at 12:50 PM, Bill Spitzak wrote:
> Scott Moreau wrote:
>
> The client doesn't need to be involved
>> in a minimize action, unlike (un)maximize, it only needs a way to track
>> its
>> minimize state and request to be minimized.
>>
>
> No, please allow the client to decide exac
Scott Moreau wrote:
The client doesn't need to be involved
in a minimize action, unlike (un)maximize, it only needs a way to track its
minimize state and request to be minimized.
No, please allow the client to decide exactly what surfaces to unmap in
response to minimize.
I need the ability
In order for clients to notify the compositor that they wish to be minimized, a
minimize request is needed. This can be used to minimize the surface when a
user clicks a minimize button for example.
The compositor needs a way to tell clients to maximize and unmaximize their
surfaces. The desktop s
28 matches
Mail list logo
