blender/blender
148
473
Fork 693
Code Issues 6.7k Pull Requests 907 Projects 18 Wiki Activity

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

New Issue
Open
opened 2023-10-17 02:12:16 +02:00 by Campbell Barton · 12 comments
Campbell Barton commented 2023-10-17 02:12:16 +02:00
Owner
Copy Link

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).
👍 2 👎 1 ❤️ 1 🚀 2
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
YimingWu commented 2023-10-17 04:49:50 +02:00
Member
Copy Link

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)
Campbell Barton commented 2023-10-17 05:33:41 +02:00
Author
Owner
Copy Link

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.
Harley Acheson commented 2023-10-17 18:35:33 +02:00
Member
Copy Link

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)
image.png
50 KiB
image.png
53 KiB
👍 1
Campbell Barton commented 2023-10-18 06:13:30 +02:00
Author
Owner
Copy Link

*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.

image

\*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. ![image](/attachments/821e2e29-c965-4926-9b25-38f13efc421e)
Screenshot from 2023-10-18 15-12-03.png
364 KiB
Julian Eisel commented 2023-10-18 12:07:32 +02:00
Member
Copy Link

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.
👍 1
Campbell Barton commented 2023-10-20 05:28:25 +02:00
Author
Owner
Copy Link

@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.
Ryan Inch commented 2024-01-28 06:53:20 +01:00
Member
Copy Link

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).
👍 1
Campbell Barton commented 2024-01-29 00:54:38 +01:00
Author
Owner
Copy Link

@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.
👍 1
Ryan Inch commented 2024-02-01 11:07:37 +01:00
Member
Copy Link

@ideasman42 That sounds good!

@ideasman42 That sounds good!
👍 1
Andrea Monzini commented 2024-03-21 14:20:29 +01:00
Copy Link

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.

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.
👍 2
Campbell Barton commented 2024-03-26 04:36:24 +01:00
Author
Owner
Copy Link

@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?

@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?
Andrea Monzini commented 2024-03-28 14:46:04 +01:00
Copy Link

@ideasman42 the current window decoration seems usable but:

  • does not follow OS theme ( dark theme for example )
  • the top bar is quite big and without useful info ( CSD would solve this )
  • i experienced keyboard troubles ( it becamse unresponsive to the point that i need a reboot of the system ) after enabling/disabling "Toggle Window Fullscreen".

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

@ideasman42 the current window decoration seems usable but: - does not follow OS theme ( dark theme for example ) - the top bar is quite big and without useful info ( CSD would solve this ) - i experienced keyboard troubles ( it becamse unresponsive to the point that i need a reboot of the system ) after enabling/disabling "Toggle Window Fullscreen". 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
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset System
Asset datablocks, libraries, browser and shelf

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
Backward and forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
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
Viewport & EEVEE

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Wayland windowing on Unix

  
Interest
Workbench

  
Interest: X11

Xorg/X11 windowing

  
Legacy
Asset Browser Project

Archived

  
Legacy
Blender 2.8 Project

Archived

  
Legacy
Milestone 1: Basic, Local Asset Browser

Archived

  
Legacy
OpenGL Error

Archived

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Related to security, https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
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

  
Module
Viewport & EEVEE

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Severity
High

  
Severity
Low

  
Severity
Normal

  
Severity
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

Archived

  
Type
Report

Archived

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
6 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.
Delete Branch "%!s()"

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?