Re: Current state of Window Decorations

Hi, On 6/25/20 11:40 AM, Simon Ser wrote: On Thursday, June 25, 2020 11:01 AM, Brad Robinson wrote: As a toolkit developer coming from Windows/OSX this is fairly shocking. I'm aware of the decoration protocol, but given it's not supported (and by the sound of it never will be) on some of

Re: Current state of Window Decorations

On Thu, 25 Jun 2020 17:16:30 +0300 Pekka Paalanen said: > On Thu, 25 Jun 2020 19:01:33 +1000 > Brad Robinson wrote: > > > That said, what would be the recommended way to implement this - would you > > typically have one surface for the decorations and an embedded sub-surface > > for the

Re: Current state of Window Decorations

On Thu, 25 Jun 2020 19:01:33 +1000 Brad Robinson wrote: > That said, what would be the recommended way to implement this - would you > typically have one surface for the decorations and an embedded sub-surface > for the content area? eg: what happens if you use a drawing library > (cairo/skia

Re: Current state of Window Decorations

Hi, On Thu, 25 Jun 2020 at 10:01, Brad Robinson wrote: > As a toolkit developer coming from Windows/OSX this is fairly shocking. I'm > aware of the decoration protocol, but given it's not supported (and by the > sound of it never will be) on some of the major distros makes it almost >

Re: Current state of Window Decorations

On Thu, 25 Jun 2020 19:01:33 +1000 Brad Robinson said: > Thanks Simon/Pekka, > > As a toolkit developer coming from Windows/OSX this is fairly shocking. > I'm aware of the decoration protocol, but given it's not supported (and by > the sound of it never will be) on some of the major distros

Re: Current state of Window Decorations

On Thursday, June 25, 2020 11:01 AM, Brad Robinson wrote: > As a toolkit developer coming from Windows/OSX this is fairly > shocking. I'm aware of the decoration protocol, but given it's not > supported (and by the sound of it never will be) on some of the major > distros makes it almost

Re: Current state of Window Decorations

>would you typically have one surface for the decorations and an embedded sub-surface for the content area? For optimisation reasons you would probably do 5 subsurfaces. top,left,right,bottom, main contents. And that would allow the mixing of GL and raster as they are different surfaces. I

Re: Current state of Window Decorations

Thanks Simon/Pekka, As a toolkit developer coming from Windows/OSX this is fairly shocking. I'm aware of the decoration protocol, but given it's not supported (and by the sound of it never will be) on some of the major distros makes it almost worthless. Seems odd to offload this responsibility

Re: Current state of Window Decorations

On Thu, 25 Jun 2020 11:57:42 +1000 Brad Robinson said: > Hey All, > > What's the current state and/or plans for window decorations with Wayland? > > I just stumbled on this post > >, and after reading the

Re: Current state of Window Decorations

On Thu, 25 Jun 2020 11:57:42 +1000 Brad Robinson wrote: > Hey All, > > What's the current state and/or plans for window decorations with Wayland? > > I just stumbled on this post > , > and after reading the

Re: Current state of Window Decorations

Hi, On Thursday, June 25, 2020 3:57 AM, Brad Robinson wrote: > What's the current state and/or plans for window decorations with Wayland? You'll always need a fallback, but the standard xdg-decoration [1] protocol lets clients request to be decorated by the compositor. Simon [1]:

Current state of Window Decorations

Hey All, What's the current state and/or plans for window decorations with Wayland? I just stumbled on this post , and after reading the comments I've got to say I'm quite shocked that getting a window to appear