On 2018-05-08 4:17 PM, Daniel Stone wrote:
> Fair enough. I brought it up only because of the introductory text: I
> think having some more context/disclaimers/etc would help.
Yeah there'll be a PATCHv2 in the future elaborating on that.
> > These ideas are still somewhat nebulous but I'm confid
On May 8, 2018 6:23:30 PM GMT+09:00, "Jonas Ådahl" wrote:
>It is my opinion that we should continue with the scope described
>above,
>to make a clear separation between what portable clients can expect
>while expecting to work both on highly integrated environments and less
>integrated environmen
Hi, butting in
On 2018/May/08 04:17, Daniel Stone wrote:
>
> > [... details snipped ...]
> >
> > These ideas are still somewhat nebulous but I'm confident enough that
> > it'll work that I think we can proceed with the discussion on protocols
> > like layer-shell. Compositors which are interested
Hi Drew,
On 8 May 2018 at 14:56, Drew DeVault wrote:
> On 2018-05-08 2:24 PM, Daniel Stone wrote:
>> Unless I'm missing something, taskbars need a separate protocol to
>> communicate the task list, tell the compositor to raise/activate the
>> surfaces for that task, etc. I guess lock screens wou
On 2018-05-08 3:53 PM, Jonas Ådahl wrote:
> That is not really true. It still mainly consists of protocols that can
> be seen as a continuation, and I don't think we should give up on that
> idea.
I think this is an overly optimistic view of the current list of
protocols. Of the protocols, I thin
On 2018-05-08 2:24 PM, Daniel Stone wrote:
> Unless I'm missing something, taskbars need a separate protocol to
> communicate the task list, tell the compositor to raise/activate the
> surfaces for that task, etc. I guess lock screens would be handled by
> the 'overlay' mode, though that makes me
On Tue, May 08, 2018 at 09:29:25AM -0400, Drew DeVault wrote:
> > > I understand that it would probably be bad to take a bunch of protocols
> > > that no one has any stake in, this is why I disagree with wayland-wall.
> > > However, layer-shell has the backing of 5 compositor implementations
> > >
> > I understand that it would probably be bad to take a bunch of protocols
> > that no one has any stake in, this is why I disagree with wayland-wall.
> > However, layer-shell has the backing of 5 compositor implementations
> > (likely to be 6 soon) and has many client implementations. Is the role
Hi,
On 8 May 2018 at 01:48, Drew DeVault wrote:
> The layer-shell introduces the concept of desktop "layers", each of
> which has a collection of surfaces. The layer shell affords its clients
> some freedom over how their surfaces are arranged with respect to each
> other and the available space
On Tue, May 08, 2018 at 08:01:25AM -0400, Drew DeVault wrote:
> On 2018-05-08 11:23 AM, Jonas Ådahl wrote:
> > So the purpose here is to provide a way to allow constructing a desktop
> > environment by combining different components more or less arbitrarily.
> > I also assume this is a newer versio
On 2018-05-08 11:23 AM, Jonas Ådahl wrote:
> So the purpose here is to provide a way to allow constructing a desktop
> environment by combining different components more or less arbitrarily.
> I also assume this is a newer version of the one proposed
> earlier[0][1][2].
Aye.
> 1) The protocols di
Hi,
So the purpose here is to provide a way to allow constructing a desktop
environment by combining different components more or less arbitrarily.
I also assume this is a newer version of the one proposed
earlier[0][1][2]. As was said before, it has been a non-goal for
wayland-protocols to provid
The layer-shell introduces the concept of desktop "layers", each of
which has a collection of surfaces. The layer shell affords its clients
some freedom over how their surfaces are arranged with respect to each
other and the available space on the output.
The goal of this shell is to allow end-use
13 matches
Mail list logo
