Re: guidance for wayland wayland cursor handling refactor

[Gregory Casamento]

If you take a quick look at GSTheme.h in gui you'll see a lot of classes to which we delegate the drawing.   I believe what you should do is create a similar class for GSStandardDecorationView that can be used to do the drawing for that class.  This way the class implemented in GSTheme.h will be the default that is used unless a theme is loaded.

On Thu, Dec 16, 2021 at 2:25 AM Riccardo Canalicchio <riccardo.canalicchio@gmail.com> wrote:

Hello,

I am in the process of cleaning-up / refactoring the wayland backend cursor handling and I am stuck on the window-resize and window-move logic.

The wayland implementations requires the window move and resize to be handled by the compositors which means that in the cursor button handler there should be the knowledge of the window decorations to understand if the click is in the titlebar or resizebar to then trigger the appropriate callbacks in the compositor.

The current implementation that "works" has replicated the same logic present in libs-gui GSStandardDecorationView, my concern is that this is coupling the backend to a specific theme implementation which is not ideal:

https://github.com/gnustep/libs-back/blob/master/Source/wayland/WaylandServer%2BCursor.m#L213

Best would be if the theme is exposing some methods like: pointInTitleBar or pointInResizeBar but I see that the base interface GSWindowDecorationView doesn't have knowledge of titleBar or resizeBar.

How do you suggest to proceed?

best,

Riccardo

--

Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron

https://gf.me/u/x8m3sx - My GNUstep GoFundMe

https://teespring.com/stores/gnustep - Store