UI: Proposal to support client-side-decorations (CSD) #113795

Open
opened 2023-10-17 02:12:16 +02:00 by Campbell Barton · 9 comments

This tasks proposes to move Blender on Wayland (and optionally other platforms) to using client side decorations.

Motivation

One of the most popular desktop environments on Linux (GNOME) currently doesn't support server-side-decorations (SSD).

While GNOME's choice not to support SSD has been met with some controversy it's not the purpose of this proposal
to request GNOME change their decision on this topic.

Currently Blender uses LIBDECOR for window decorations on GNOME.
In principle using a 3rd party library for window decorations seems reasonable, however there have been enough bugs reported relating to LIBDECOR that I don't think it's a workable solution for us.

At time of writing here are bugs relating to Blender & libdecor.

  • #103000: crash when resizing secondary window and GNOME desktop has fractional scaling
  • #107797: crash resizing window on Wayland
  • #108308: crash on startup with LibDecor on Wayland
  • #109194: window decorations don't match window contents
  • #117121: unable to close window with GNOME.
  • #117583: mouse cursor becomes resize on the title bar of the render view window

The two issues users are running into are crashes when interacting with windows & window decorations not matching Blender's window contents, making basic windowing operations nearly unusable.

We could workaround the bugs by disabling functionality known to cause problems:

  • Force X11 on older versions of GNOME shell
    (exactly which version I'm not sure of but this seems to happen with older versions of GNOME shell).
  • Disable fractional window scaling on GNOME shell.
    (using less efficient method where a larger buffer is rendered then scaled down).

Irrespective of this proposal we can consider short term workarounds for the issues with LIBDECOR,
whatever the case, I believe time spent looking for workarounds with LIBDECOR would be better spent working having our own client side decorations.

Proposal

Implement client-side-decorations (CSD) in Blender.

Steps:

First, create a proof of concept CSD, aiming at basic functionality without spending too much time.

  • Implement window decoration display at the WM level (similar to the top-bar)
  • Integrate them with GHOST/Wayland so they're functional under Wayland.

During this process, check the approach used can eventually support CSD on WIN32/macOS too.

After some testing & feedback.

  • Create a PR for main to have CSD UI approved along with changes to GHOST.
  • Remove Wayland/LIBDECOR integration.

Prioritization

Since the Linux/Wayland user-base isn't a large proportion of users, the priority to give this project could be lowered / postponed-indefinitely.

For less severe problems it seems reasonable, however the bugs being reported are quite bad, making this something I think should be handled sooner than later.

Alternative Options

  • Continue supporting LIBDECOR, investigate issues and push fixes LIBDECOR (may require bundling LIBDECOR with Blender if users are to have newer, bug-fixed versions, bundling LIBDECOR isn't so simple as it depends on libraries such as Cairo/Pango... not used by Blender).
  • Drop Wayland support for older GNOME versions (pre 44.0 e.g.) (this is unfortunate as this removes Wayland support for Ubuntu 22.04.3 LTS).

Further Work

  • Take advantage of CSD.

    Using CSG gives us the ability to include graphical elements in the title bar and make more efficient use of space.
    Workspace tabs could be drawn in the title bar (similar to the Chrome web browser).

  • If/when CSD are an improvement over CSD, support could be added on macOS/WIN32.

  • Support CSD for the animation player
    (If window decorations are to be handled at the WM level, the animation player support would have to be handled separately, sharing logic with Blender's WM implementation where appropriate).

This tasks proposes to move Blender on Wayland (and optionally other platforms) to using client side decorations. ### Motivation One of the most popular desktop environments on Linux (GNOME) currently doesn't support server-side-decorations (SSD). While GNOME's choice not to support SSD has been met with some controversy it's not the purpose of this proposal to request GNOME change their decision on this topic. Currently Blender uses LIBDECOR for window decorations on GNOME. In principle using a 3rd party library for window decorations seems reasonable, however there have been enough bugs reported relating to LIBDECOR that I don't think it's a workable solution for us. At time of writing here are bugs relating to Blender & libdecor. - #103000: crash when resizing secondary window and GNOME desktop has fractional scaling - #107797: crash resizing window on Wayland - #108308: crash on startup with LibDecor on Wayland - #109194: window decorations don't match window contents - #117121: unable to close window with GNOME. - #117583: mouse cursor becomes resize on the title bar of the render view window The two issues users are running into are crashes when interacting with windows & window decorations not matching Blender's window contents, making basic windowing operations nearly unusable. We could workaround the bugs by disabling functionality known to cause problems: * Force X11 on older versions of GNOME shell (exactly which version I'm not sure of but this seems to happen with older versions of GNOME shell). * Disable fractional window scaling on GNOME shell. (using less efficient method where a larger buffer is rendered then scaled down). Irrespective of this proposal we can consider short term workarounds for the issues with LIBDECOR, whatever the case, I believe time spent looking for workarounds with LIBDECOR would be better spent working having our own client side decorations. ### Proposal Implement client-side-decorations (CSD) in Blender. Steps: First, create a proof of concept CSD, aiming at basic functionality without spending too much time. - Implement window decoration display at the WM level (similar to the top-bar) - Integrate them with GHOST/Wayland so they're functional under Wayland. _During this process, check the approach used can eventually support CSD on WIN32/macOS too._ After some testing & feedback. - Create a PR for `main` to have CSD UI approved along with changes to GHOST. - Remove Wayland/LIBDECOR integration. ### Prioritization Since the Linux/Wayland user-base isn't a large proportion of users, the priority to give this project could be lowered / postponed-indefinitely. For less severe problems it seems reasonable, however the bugs being reported are quite bad, making this something I think should be handled sooner than later. ### Alternative Options - Continue supporting LIBDECOR, investigate issues and push fixes LIBDECOR _(may require bundling LIBDECOR with Blender if users are to have newer, bug-fixed versions, bundling LIBDECOR isn't so simple as it depends on libraries such as Cairo/Pango... not used by Blender)._ - Drop Wayland support for older GNOME versions (pre 44.0 e.g.) (this is unfortunate as this removes Wayland support for Ubuntu 22.04.3 LTS). ### Further Work - Take advantage of CSD. Using CSG gives us the ability to include graphical elements in the title bar and make more efficient use of space. Workspace tabs could be drawn in the title bar (similar to the Chrome web browser). - If/when CSD are an improvement over CSD, support could be added on macOS/WIN32. - Support CSD for the animation player (If window decorations are to be handled at the WM level, the animation player support would have to be handled separately, sharing logic with Blender's WM implementation where appropriate).
Campbell Barton added the
Type
Design
label 2023-10-17 02:12:16 +02:00
Campbell Barton added the
Module
User Interface
label 2023-10-17 03:02:18 +02:00
Campbell Barton added the
Interest
Wayland
label 2023-10-17 03:14:51 +02:00
Member

If I'm understanding this correctly, this means to have a "borderless system window" and draw window decorations inside the client area. This should enable us to do some space-saving layouts by e.g. putting layout tabs at the same row as the window minimize/maximize/close buttons. Maybe it can be customized too. (Well of course there needs to be more designs stuff)

If I'm understanding this correctly, this means to have a "borderless system window" and draw window decorations inside the client area. This should enable us to do some space-saving layouts by e.g. putting layout tabs at the same row as the window minimize/maximize/close buttons. Maybe it can be customized too. (Well of course there needs to be more designs stuff)
Author
Owner

If I'm understanding this correctly, this means to have a "borderless system window" and draw window decorations inside the client area. This should enable us to do some space-saving layouts by e.g. putting layout tabs at the same row as the window minimize/maximize/close buttons. Maybe it can be customized too. (Well of course there needs to be more designs stuff)

Right, Blender would be responsible for drawing window borders & title bar, short term I'm proposing a simple implementation so we can drop the LIBDECOR dependency & close LIBDECOR related bugs. Longer term it would be nice to check on using the title area although I don't have a strong opinion about this just now.

> If I'm understanding this correctly, this means to have a "borderless system window" and draw window decorations inside the client area. This should enable us to do some space-saving layouts by e.g. putting layout tabs at the same row as the window minimize/maximize/close buttons. Maybe it can be customized too. (Well of course there needs to be more designs stuff) Right, Blender would be responsible for drawing window borders & title bar, short term I'm proposing a simple implementation so we can drop the LIBDECOR dependency & close LIBDECOR related bugs. Longer term it would be nice to check on using the title area although I don't have a strong opinion about this just now.
Member

First I should say that I love the idea in principle. And there might even be an argument that I do this first for Windows. But this seems to have a bunch of "last mile" problems that might need design. Rambling notes in no specific order:

There is a definite "uncanny valley" with these, especially on Mac and currently a little less so on Windows. So if they don't very closely mimic the expected OS look then it can seen as quite goofy. This problem is compounded by our users running Blender on different versions of their OS where the decorations might change. Even if we always update our code to mimic the latest version on each OS that aesthetic might not match well when run on older versions. There is also possibility that we have platforms where the user can change the decoration colors but we don't have access to them through an OS API.

I think Blender's scaled interface is a big part of the challenge. It makes a transition difficult from a traditional title bar to one where we save space and incorporate our interface into that area. It isn't obvious why this is a problem for us but not other applications like Chrome...

If we start with a traditional title bar, so a horizonal strip separate from our application area and containing just OS window management widgets and title. In this case the height of that bar, and the size of the widgets is NOT related to our Resolution Scale. As in that bar can't get twice as big if someone selects a scale of 2.0. Those sizes must be taken from the operating system scale and do no change with our Resolution Scale. And the title font size changes with OS scale. Therefore if you have Blender's scale set to 2.0 then our interface text will be twice as large as the caption title, and that is normal and expected behavior.

image

But then consider the idea of us using the caption area for our purposes, and moving our menus and other content up into that space. Now we have to scale everything by our Resolution Scale. The title can no longer include path. But the OS window management widgets have to still be sized by the OS scale, not by our scale. At times those buttons are smaller than our preferred vertical space up there, but there are also times when they are larger. So we might have to make room for widgets that can be, by comparison, quite small or quite large:

image

First I should say that I love the idea in principle. And there might even be an argument that I do this first for Windows. But this seems to have a bunch of "last mile" problems that might need design. Rambling notes in no specific order: There is a definite "uncanny valley" with these, especially on Mac and currently a little less so on Windows. So if they don't very closely mimic the expected OS look then it can seen as quite goofy. This problem is compounded by our users running Blender on different versions of their OS where the decorations might change. Even if we always update our code to mimic the latest version on each OS that aesthetic might not match well when run on older versions. There is also possibility that we have platforms where the user can change the decoration colors but we don't have access to them through an OS API. I think Blender's scaled interface is a big part of the challenge. It makes a transition difficult from a traditional title bar to one where we save space and incorporate our interface into that area. It isn't obvious why this is a problem for us but not other applications like Chrome... If we start with a traditional title bar, so a horizonal strip separate from our application area and containing just OS window management widgets and title. In this case the height of that bar, and the size of the widgets is NOT related to our Resolution Scale. As in that bar can't get twice as big if someone selects a scale of 2.0. Those sizes must be taken from the operating system scale and do no change with our Resolution Scale. And the title font size changes with OS scale. Therefore if you have Blender's scale set to 2.0 then our interface text will be twice as large as the caption title, and that is normal and expected behavior. ![image](/attachments/d86ea057-d9be-4c04-8d08-1a15b2176844) But then consider the idea of us using the caption area for our purposes, and moving our menus and other content up into that space. Now we have to scale everything by our Resolution Scale. The title can no longer include path. But the OS window management widgets have to still be sized by the OS scale, not by our scale. At times those buttons are smaller than our preferred vertical space up there, but there are also times when they are larger. So we might have to make room for widgets that can be, by comparison, quite small or quite large: ![image](/attachments/3fc90535-c067-4bb4-9628-31eabb9b3e77)
Author
Owner

Issues with having our own title bar noted, this is why I'm only suggesting to do this for Wayland, see screenshot for issues with the current window borders.

image

Issues with having our own title bar noted, this is why I'm only suggesting to do this for Wayland, see screenshot for issues with the current window borders. ![image](/attachments/821e2e29-c965-4926-9b25-38f13efc421e)
Member

With client side decorations, I'm worried about cases when Blender itself is unresponsive, or responding slowly. With server side decorations you are still able to scale the window, or press one of the window control buttons (e.g. to close or minimize the window). The user would get immediate feedback, and Blender handled the event as soon as possible. Now nothing would happen, or feedback would be very poor for example while Blender is rendering, compiling shaders, undoing or struggling with high-poly meshes. There is a good amount of cases where people would run into this.

To support this well, we'd have to run an event and draw loop for the decorations in a separate thread. Of course our UI code isn't designed for this at all. If we consider this important, and drop the idea of having all kinds of widgets supported there (which I'd love to have eventually, but I'm thinking realistically here), we could have a very primitive event and drawing loop in a separate thread for the decorations.

With client side decorations, I'm worried about cases when Blender itself is unresponsive, or responding slowly. With server side decorations you are still able to scale the window, or press one of the window control buttons (e.g. to close or minimize the window). The user would get immediate feedback, and Blender handled the event as soon as possible. Now nothing would happen, or feedback would be very poor for example while Blender is rendering, compiling shaders, undoing or struggling with high-poly meshes. There is a good amount of cases where people would run into this. To support this well, we'd have to run an event and draw loop for the decorations in a separate thread. Of course our UI code isn't designed for this at all. If we consider this important, and drop the idea of having all kinds of widgets supported there (which I'd love to have eventually, but I'm thinking realistically here), we could have a very primitive event and drawing loop in a separate thread for the decorations.
Author
Owner

@JulianEisel the problem of the window borders not updating while Blender is unresponsive is already happening with Blender under Wayland.

But it's a good point that for CSD more generally, and even if we implement our own under Wayland, it would be good to support refreshing active/inactive windows even if Blender isn't responsive.

@JulianEisel the problem of the window borders not updating while Blender is unresponsive is already happening with Blender under Wayland. But it's a good point that for CSD more generally, and even if we implement our own under Wayland, it would be good to support refreshing active/inactive windows even if Blender isn't responsive.
Member

My two cents. Applications using client side decorations never seem to support all the window manager functions that I want/my window manager provides, so I'm for using them as little as possible. Also, the title bar should be for titles/file paths, and for dragging the window, not other graphical elements (it has a job, it should do it and do it well).

My two cents. Applications using client side decorations never seem to support all the window manager functions that I want/my window manager provides, so I'm for using them as little as possible. Also, the title bar should be for titles/file paths, and for dragging the window, not other graphical elements (it has a job, it should do it and do it well).
Author
Owner

@Imaginer I don't have a strong opinion on this topic, we could make the client-side-decorations optional (even disable them by default) for systems that support server side decorations.

@Imaginer I don't have a strong opinion on this topic, we could make the client-side-decorations optional (even disable them by default) for systems that support server side decorations.
Member

@ideasman42 That sounds good!

@ideasman42 That sounds good!
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#113795
No description provided.