UI: Proposal to support client-side-decorations (CSD) #113795
Labels
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
Interest: X11
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
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#113795
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
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:
(exactly which version I'm not sure of but this seems to happen with older versions of 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.
During this process, check the approach used can eventually support CSD on WIN32/macOS too.
After some testing & feedback.
mainto have CSD UI approved along with changes to GHOST.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
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).
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.
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.
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:
*Update* the bug described below has been fixed.
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.
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.
@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.
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).
@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.
@ideasman42 That sounds good!
Hello,
thank you for the project and looking forward to test it.
I just disagree about the possible "postponed-indefinitely" for the priority.
It is true that the Blender Linux user-base isn't a large proportion of users but following the Blender Open Data, Linux is still the second most used OS ( as Today ) :
https://opendata.blender.org/
So i think that Wayland support for functional decorations should be not "postponed-indefinitely" as priority.
In particular because we have a perspective for the major Linux distros to remove X11 soon ( next Fedora 41 with a release date in October 2024, GNOME 48 ? ).
And Blender as free and open source software should support Linux users that are maybe smaller community but very important as developers and contributors in my opinion.
I think there is a great work from the developers to support Linux, so please just do not lower the priority.
Anyway thank you for the work and support for Linux.
@AndreaMonzini from my own testing with Gnome 45 and the recently released Gnome-46, the worst of the windowing issues seem to be resolved, although there are some reports which I never managed to redo and I'm not sure if they are still an issue.
My impression is that CSD would still be worth doing though. Are you experiencing any issues which make the current LIBDECOR decorations unusable? Are these reported?
@ideasman42 the current window decoration seems usable but:
But the keyboard issue could be related to the KVM switch integrated in the monitor so i need some investigations before opening a bug report.
Basically in Wayland i have troubles with inputs like mouse stuttering ( reported ) and keyboard.
Thank you