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.canalicc...@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
