Closing System Console can lead to loss of work #78185

Open
opened 2020-06-24 01:38:53 +02:00 by Robert VanEtten · 30 comments

System Information
Operating system: Windows

Blender Version
Any

Exact steps for others to reproduce the error

  • Start Blender
  • Toggle the System Console (2.83 and newer Windows > Toggle System Console
  • Press the - button on the system console
**System Information** Operating system: Windows **Blender Version** Any **Exact steps for others to reproduce the error** * Start Blender * Toggle the System Console (2.83 and newer `Windows > Toggle System Console` * Press the - [x] button on the system console

Added subscriber: @KainDeGayls

Added subscriber: @KainDeGayls

Added subscriber: @ronsn

Added subscriber: @ronsn

Changed status from 'Needs Triage' to: 'Archived'

Changed status from 'Needs Triage' to: 'Archived'
ronsn closed this issue 2020-06-24 01:48:08 +02:00
ronsn self-assigned this 2020-06-24 01:48:08 +02:00

Thanks for your Spam report. Please make sure to save your work frequently. You can also edit your settings to save your work automatically every x minutes 😘

Thanks for your **Spam** report. Please make sure to save your work frequently. You can also edit your settings to save your work automatically every x minutes 😘
Member

Added subscribers: @WilliamReynish, @jesterking

Added subscribers: @WilliamReynish, @jesterking
Member

Changed status from 'Archived' to: 'Confirmed'

Changed status from 'Archived' to: 'Confirmed'
Member

This isn't spam clearly. But obviously the original post is not a very good-quality bug report either. This doesn't take away there is a valid issue here, though. I'm editing the OP to read nicer and convey the issue correctly.

That said, we should look for a way to make it clear that the system console should not be closed using the - [x] button, but rather just toggled with the menu entry it was first summoned with.

For @KainDeGayls the technical reason is that Blender is linked to the console subsystem, that allows us to show that system console. As a drawback it means closing it closes the whole of Blender.

@WilliamReynish could we find a good way to communicate this to users that aren't aware that the system console on Windows is actually the main heart of the program, and closing it via its - [x] button closes the whole of Blender?

I currently don't know of a way to override the behaviour of that button on the system console so we could prevent this, but we should keep looking.

This isn't spam clearly. But obviously the original post is not a very good-quality bug report either. This doesn't take away there is a valid issue here, though. I'm editing the OP to read nicer and convey the issue correctly. That said, we should look for a way to make it _clear_ that the system console should not be closed using the - [x] button, but rather just toggled with the menu entry it was first summoned with. For @KainDeGayls the technical reason is that Blender is linked to the console subsystem, that allows us to show that system console. As a drawback it means closing _it_ closes the whole of Blender. @WilliamReynish could we find a good way to communicate this to users that aren't aware that the system console on Windows is actually the main heart of the program, and closing it via its - [x] button closes the whole of Blender? I currently don't know of a way to override the behaviour of that button on the system console so we could prevent this, but we should keep looking.
Nathan Letwory changed title from I lost several hours of work... to Closing System Console can lead to loss of work 2020-06-24 07:45:18 +02:00
Member

Added subscriber: @LazyDodo

Added subscriber: @LazyDodo
Member

The report doesn't mention OS or version but on windows we have disabled the close button in 27a239864f

The report doesn't mention OS or version but on windows we have disabled the close button in 27a239864f
Member

Right, there is a second close button though, which is probably which is used.

Using the X on the console window through the taskbar closes whole of Blender. @LazyDodo, are you aware of any API that could help us hook into that one?

Right, there is a second close button though, which is probably which is used. Using the X on the console window through the taskbar closes whole of Blender. @LazyDodo, are you aware of any API that could help us hook into that one?
Member

No

No
Member

Added subscriber: @Alaska

Added subscriber: @Alaska
Member

Another note for @KainDeGayls
Blender by default will make auto saves every few minutes of your scene to the tmp folder on your computer. If you close Blender without saving, you can revert back to a auto save by opening Blender and selecting from the top of Blender File -> Recover -> Auto save and selecting the auto save of your file.
By default, I believe Windows will clear the tmp folder if you turn off your computer. So make sure you recover your autosave before turning off your computer.

Another note for @KainDeGayls Blender by default will make auto saves every few minutes of your scene to the `tmp` folder on your computer. If you close Blender without saving, you can revert back to a auto save by opening Blender and selecting from the top of Blender `File -> Recover -> Auto save` and selecting the auto save of your file. By default, I believe Windows will clear the `tmp` folder if you turn off your computer. So make sure you recover your autosave before turning off your computer.
Member

Removed subscriber: @Alaska

Removed subscriber: @Alaska
Member

Added subscriber: @ankitm

Added subscriber: @ankitm
Member

Toggle the System Console (2.83 and newer Windows > Toggle System Console

Why not use the toggle again ? If the button's name was "open system console", that'd be a different thing and leave an ambiguity. But there's not ambiguity here & totally a user's mistake.
window's console should be asking the user for a confirmation about "terminate process? "
image.png

> Toggle the System Console (2.83 and newer Windows > Toggle System Console Why not use the toggle again ? If the button's name was "open system console", that'd be a different thing and leave an ambiguity. But there's not ambiguity here & totally a user's mistake. window's console should be asking the user for a confirmation about "terminate process? " ![image.png](https://archive.blender.org/developer/F8640382/image.png)

Added subscriber: @rjg

Added subscriber: @rjg
Member

In #78185#964092, @ankitm wrote:

Toggle the System Console (2.83 and newer Windows > Toggle System Console

Why not use the toggle again ? If the button's name was "open system console", that'd be a different thing and leave an ambiguity. But there's not ambiguity here & totally a user's mistake.

But there is ambiguity. After opening the system console there is no indication in the taskbar that closing the console window closes all Windows.

On Windows:

  • Start Blender
  • Window > New Window
  • Window > Toggle System Console

Now click on the Blender entry in the task bar, you'll get three previews: the main window, the new window and the console window. Click in the preview the X of the new window. It will close nicely as expected, rest of Blender is still up and running. Do the same with the console window. Blender closes without a peep.

This is far from unambiguous, and no doubt will lead to more of these cases in the future.

image.png

> In #78185#964092, @ankitm wrote: >> Toggle the System Console (2.83 and newer Windows > Toggle System Console > Why not use the toggle again ? If the button's name was "open system console", that'd be a different thing and leave an ambiguity. But there's not ambiguity here & totally a user's mistake. But there _is_ ambiguity. After opening the system console there is no indication _in the taskbar_ that closing the console window closes all Windows. On Windows: * Start Blender * Window > New Window * Window > Toggle System Console Now click on the Blender entry in the task bar, you'll get three previews: the main window, the new window and the console window. Click in the preview the X of the new window. It will close nicely as expected, rest of Blender is still up and running. Do the same with the console window. Blender closes without a peep. This is far from unambiguous, and no doubt will lead to more of these cases in the future. ![image.png](https://archive.blender.org/developer/F8640718/image.png)
Member

Removed subscriber: @LazyDodo

Removed subscriber: @LazyDodo
ronsn was unassigned by Ankit Meel 2020-06-24 16:08:30 +02:00
Member

Added subscriber: @Mets

Added subscriber: @Mets
Member

I remember seeing suggestions over the years for having a terminal inside Blender itself. Is such a thing possible?

I remember seeing suggestions over the years for having a terminal inside Blender itself. Is such a thing possible?
Member

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly
Member

I don't think this is a bug within the current definition. Of course that doesn't mean we don't want to reduce the reliance on the system console, but I don't think it makes sense to keep that on the bug tracker.

That said, I'll keep this as a "Known Issue" since it might not be intuitive at all.

I don't think this is a bug within the current definition. Of course that doesn't mean we don't want to reduce the reliance on the system console, but I don't think it makes sense to keep that on the bug tracker. That said, I'll keep this as a "Known Issue" since it might not be intuitive at all.

Added subscriber: @ShadowChaser

Added subscriber: @ShadowChaser

Realize this is a task marked as confirmed, but I wanted to chime in with a few observations that might come in handy in case someone stumbles across this again. Blender's behavior on Windows has a few "quirks" compared to other applications that result in user experience problems, a perception of lower quality compared to other software (definitely not true!), or strange edge cases that might be considered bugs.

  • Console window flashes when UI is being launched.
  • Console window flashes when UI is being shut down.
  • Launching Blender from a terminal and then closing the terminal will immediately terminate the Blender process without any warning.
  • Launching Blender from a terminal and then selecting "Toggle System Console" will cause Blender to send messages into the terminal process and hide it's window. It's generally a big no-no on Windows to have one process mess with the internal state of another process like this.
  • The GetConsoleWindow() function that Blender uses to manipulate and hide the console window is deprecated functionality and not compatible pseudoconsoles or the other newer Windows console functionality being added in future releases.

I understand many of these seem minor or "not defects" to non-Windows Blender developers or extremely advanced users, but they are definitely bugs for the average Blender user and especially when comparing to other 3D software packages.

I've experimented with a few solutions with some mixed success:

Windowed Launcher Process
A "launcher" process (e.g. blenderlauncher.exe) can be created. The process would be a Windowed app instead of a Console app, avoiding a console flash. It could then call CreateProcess on Blender.exe with the CREATE_NO_WINDOW flag and then immediately terminate. This would have the end result of launching Blender without a console window by default - all other stdin/stdout/etc streams and console features are left alone. The "launcher" could be made the target of the Windows Store packages or, much later, the Start Menu shortcut for non-Store installs.

The problem with this approach is that I cannot find an API to create the console window on demand once blender.exe has started (e.g. during Toggle System Console). Unless someone else can find an API that does that, Blender would need an integrated console for this approach to be successful.

Blocking Console Process
A "command line" process (e.g. blenderc.exe) can be created and the main blender.exe process made a fully windowed application (instead of a command line one). This command line process would call CreateProcess on blender.exe to launch the UI with options to have blender.exe's stdin and stdout redirected to the parent console process. The command line process would then call WaitForSingleObject to ensure control isn't returned back to the terminal until Blender is closed or finishes it's processing.

This approach is the most "pure" - Blender is a windowed application and is properly configured as such, the command line executable still works the same as it does today for power users/automation scenarios/etc. Java works this way (java.exe and javaw.exe) as do many other Windows' applications.

There are two downsides - one is that Blender would still need an integrated console for "pure window" scenarios and the other is that power users would need to learn to run a slightly different executable if they want the command line to block and redirect stdin/stdout/stderr.

Pseudoterminal
Newer versions of Windows 10 support full pseudoterminal (PTY) functionality. One option here would be to have Blender launch whatever terminal it likes (not just Windows' ancient default one) and also have full control of it. That won't work on Windows 7/8, so this isn't a reasonable option.

Proposal: A Path Forward

  • Provide a mechanism for viewing text sent to stdout and stderr within the Blender UI. This could be shown in the existing Info Editor or a new "System Console" UI that uses much of the existing functionality already developed for the Python Console UI.
  • Having full control over the System Console UI would allow Blender to add features to it that make it more powerful than the "stock" ancient Windows console window that we're stuck with today.
  • Modify the "Window->Toggle System Console" menu action so that it brings up the new native console UI.
  • Create a "blenderlauncher.exe" process (naming TBD) that is the target for the Windows Store app package and Start Menu shortcut. This process would be an extremely small Windows app that does nothing except launch "blender.exe" with the CREATE_NO_WINDOW flag set to suppress the Windows console window flash.
  • Power users who dislike the integrated console can still open up their terminal of choice (including fancy newer ones!) and run blender.exe at command line. stdout/stderr would still be displayed there, as it is today.
  • Power users who prefer the old behavior can launch blender.exe directly or create a Start Menu shortcut for it.

There are quite a few benefits to this approach:

  • Non-power users see Blender working like all other software on Windows and have a high quality user experience. They can open the console output inside Blender's UI if they need to.
  • Power users have the option of opening whatever external terminal they like (cmd.exe, Powershell, Windows Terminal, bash on Windows, whatever!) and having Blender's console output displayed there.
  • Power users have the option of the "legacy" Blender UX with two windows (regular + console) approach if they preferred that.
  • Command line arguments and command line Blender users are not affected.

Most of the work here is trivial with the exception of the integrated console UI, and I suspect much of that is already built because of the Python Console.

Thoughts? Let's keep an open mind :)

A little taste of what's possible:
no-console.mp4

Realize this is a task marked as confirmed, but I wanted to chime in with a few observations that might come in handy in case someone stumbles across this again. Blender's behavior on Windows has a few "quirks" compared to other applications that result in user experience problems, a perception of lower quality compared to other software (definitely not true!), or strange edge cases that might be considered bugs. - Console window flashes when UI is being launched. - Console window flashes when UI is being shut down. - Launching Blender from a terminal and then closing the terminal will immediately terminate the Blender process without any warning. - Launching Blender from a terminal and then selecting "Toggle System Console" will cause Blender to send messages into the terminal process and hide it's window. It's generally a big no-no on Windows to have one process mess with the internal state of another process like this. - The GetConsoleWindow() function that Blender uses to manipulate and hide the console window is deprecated functionality and not compatible pseudoconsoles or the other newer Windows console functionality being added in future releases. I understand many of these seem minor or "not defects" to non-Windows Blender developers or extremely advanced users, but they are definitely bugs for the average Blender user and especially when comparing to other 3D software packages. I've experimented with a few solutions with some mixed success: **Windowed Launcher Process** A "launcher" process (e.g. blenderlauncher.exe) can be created. The process would be a Windowed app instead of a Console app, avoiding a console flash. It could then call CreateProcess on Blender.exe with the CREATE_NO_WINDOW flag and then immediately terminate. This would have the end result of launching Blender without a console window by default - all other stdin/stdout/etc streams and console features are left alone. The "launcher" could be made the target of the Windows Store packages or, much later, the Start Menu shortcut for non-Store installs. The problem with this approach is that I cannot find an API to create the console window on demand once blender.exe has started (e.g. during Toggle System Console). Unless someone else can find an API that does that, Blender would need an integrated console for this approach to be successful. **Blocking Console Process** A "command line" process (e.g. blenderc.exe) can be created and the main blender.exe process made a fully windowed application (instead of a command line one). This command line process would call CreateProcess on blender.exe to launch the UI with options to have blender.exe's stdin and stdout redirected to the parent console process. The command line process would then call WaitForSingleObject to ensure control isn't returned back to the terminal until Blender is closed or finishes it's processing. This approach is the most "pure" - Blender is a windowed application and is properly configured as such, the command line executable still works the same as it does today for power users/automation scenarios/etc. Java works this way (java.exe and javaw.exe) as do many other Windows' applications. There are two downsides - one is that Blender would still need an integrated console for "pure window" scenarios and the other is that power users would need to learn to run a slightly different executable if they want the command line to block and redirect stdin/stdout/stderr. **Pseudoterminal** Newer versions of Windows 10 support full pseudoterminal (PTY) functionality. One option here would be to have Blender launch whatever terminal it likes (not just Windows' ancient default one) and also have full control of it. That won't work on Windows 7/8, so this isn't a reasonable option. **Proposal: A Path Forward** - Provide a mechanism for viewing text sent to stdout and stderr within the Blender UI. This could be shown in the existing Info Editor or a new "System Console" UI that uses much of the existing functionality already developed for the Python Console UI. - Having full control over the System Console UI would allow Blender to add features to it that make it more powerful than the "stock" ancient Windows console window that we're stuck with today. - Modify the "Window->Toggle System Console" menu action so that it brings up the new native console UI. - Create a "blenderlauncher.exe" process (naming TBD) that is the target for the Windows Store app package and Start Menu shortcut. This process would be an extremely small Windows app that does nothing except launch "blender.exe" with the CREATE_NO_WINDOW flag set to suppress the Windows console window flash. - Power users who dislike the integrated console can still open up their terminal of choice (including fancy newer ones!) and run blender.exe at command line. stdout/stderr would still be displayed there, as it is today. - Power users who prefer the old behavior can launch blender.exe directly or create a Start Menu shortcut for it. There are quite a few benefits to this approach: - Non-power users see Blender working like all other software on Windows and have a high quality user experience. They can open the console output inside Blender's UI if they need to. - Power users have the option of opening whatever external terminal they like (cmd.exe, Powershell, Windows Terminal, bash on Windows, whatever!) and having Blender's console output displayed there. - Power users have the option of the "legacy" Blender UX with two windows (regular + console) approach if they preferred that. - Command line arguments and command line Blender users are not affected. Most of the work here is trivial with the exception of the integrated console UI, and I suspect much of that is already built because of the Python Console. Thoughts? Let's keep an open mind :) A little taste of what's possible: [no-console.mp4](https://archive.blender.org/developer/F9428743/no-console.mp4)

Added subscriber: @brecht

Added subscriber: @brecht

@ShadowChaser capturing stdout/stderr and showing in the info editor (could be renamed if its purpose is expanded) is what developers generally agree on is the path forward. Contributions go get this working are definitely welcome.

Once that is implemented, I think we should simply eliminate the console window. Power users who want console output can simply launch Blender from the console., I don't see the need for anything more.

@ShadowChaser capturing stdout/stderr and showing in the info editor (could be renamed if its purpose is expanded) is what developers generally agree on is the path forward. Contributions go get this working are definitely welcome. Once that is implemented, I think we should simply eliminate the console window. Power users who want console output can simply launch Blender from the console., I don't see the need for anything more.

@brecht I fully agree with your idea. Power users would start from the console and don't need the option. Additionally, the idea to capture stdout/stderr would make the messages accessible to users on all platforms when starting Blender without a terminal/console.

@brecht I fully agree with your idea. Power users would start from the console and don't need the option. Additionally, the idea to capture stdout/stderr would make the messages accessible to users on all platforms when starting Blender without a terminal/console.
Member

Added subscriber: @Harley

Added subscriber: @Harley
Member

capturing stdout/stderr and showing in the info editor (could be renamed if its purpose is expanded) is what developers generally agree on is the path forward

Me and LazyDodo have talked about this, but I've been pushing it off, waiting for the GSoC Info Editor Improvements as that would include changes that would make it nicer.

> capturing stdout/stderr and showing in the info editor (could be renamed if its purpose is expanded) is what developers generally agree on is the path forward Me and LazyDodo have talked about this, but I've been pushing it off, waiting for the [GSoC Info Editor Improvements ](https://devtalk.blender.org/t/gsoc-2020-info-editor-improvements-weekly-reports/13659) as that would include changes that would make it nicer.
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:24:22 +01:00
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
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
12 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#78185
No description provided.