Hi, On Thu, 25 Jun 2020 at 10:01, Brad Robinson <brobin...@toptensoftware.com> 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 > worthless. > > Seems odd to offload this responsibility to every toolkit without providing a > mechanism to achieve any consistency. Or... is this just my background in > Windows/OSX where consistency in these areas is really encouraged and this > just isn't expected on Linux?
Others have said this well, but the big difference is that Windows and OS X both have complete native toolkits as part of their base platform. Those toolkits implement widgets, things like titlebars, IPC, intra-process message handling and signaling, internationalisation, application lifecycle management, etc etc. That's not something we have: toolkits are instead an optional and interchangeable component. If you use one of the major extant toolkits, then you can reuse all that functionality. This is why even some of the monoliths like Chromium reuse toolkits. If you want to create your own toolkit from scratch and not base on one of the existing ones, then for better or worse, you get to recreate all the functionality they provide. Shifting responsibility for window decorations to the compositor doesn't solve the problem. Yes the compositor would render them for you, but then you have additional protocols (with all the synchronisation issues that implies) for the client and compositor to co-ordinate rendering of the decorations and the content. Neither is objectively better or worse, it's just a different design which inherently brings different tradeoffs. Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel