User Preferences window does not remember size

Based on the rejected bug report here:
https://developer.blender.org/T67502

This is getting extremely confusing. Even the most obvious bugs are getting completely arbitrarily closed as supposed feature request, just so that they can be directed to channels where they can be safely ignored :confused:

2 Likes

That’s because it’s not a bug. Blender currently doesn’t know about the earlier window you closed, and every time you open Preferences, it has a fixed size.

1 Like

Here’s a thing. Recently, I’ve reported also for example: https://developer.blender.org/T67242 this one, which has been confirmed and assigned medium priority.

If I had to bet which one will be considered a bug, and which one a feature request, the common sense would be to switch it the other way around. Imagine seeing a “New Features” changelog:

  1. Workbench viewport now supports UV transform node
  2. User Preferences window now remembers size and position like all the other floating windows in Blender.

Which one of these two in the New Features list does sound like a new, added functionality, and which one sounds more like a bugfix. I know, right?

If you create a new window in Blender by going to Window>New Window, then once saved, that Window remembers both size and position. So the code for saving window position is already there. Not only that, but also, the open state of User Preferences window is saved with the .blend file! So if you open user preferences via Edit>Preferences, and save the file, if you load the file, it’s still open.

Here’s a thing. If you create a new window through Window>New Window, adjust the new window layout is it has just one editor, and set that one editor to be user Preferences, then you get pretty much exact same thing, except with remembering window position and size. All it takes here is changing Edit>Preferences operator to open same type of window as Window>New Window. On top of that, it would allow for deprecation and removal of this special window type used for user preferences, which apparently uses different code for window display.

But back to the original point. I am no longer able to tell what could possibly be considered a bug, and what would not. It’s just so arbitrary, with no clear rules behind it, that I really don’t know what I should report and what not. If window remembering its size is a feature, but addition of support for texture transform node in workbench is a bug… I am lost here…

This is not true, if you click on Window>New Window it will always open it with the default size and position, same behavior as for the User Preferences.
If you save the file with some open windows they remains of the same size at reopen, but that is also true for the User Preferences.

As for the other one, I think that the ratio for considering it a bug and not a feautre request is that the old 2.7 viewport did show the effect of the texture mapping in “Material mode”, so it makes sense to be able to see it without being forced to use Eevee (I’m just guessing here).

Yes, but if you open it once, and save the file with it, once you reopen that file, the window will stay the same size. My point is if the code to remember window size is already there, why not use it?

I get it, but it may be a bit more complex then it seems, you need to store those infos in the blend file at save time (and this alone it’s probably something that devs would want to discuss before).

You also need to keep them always around, since you want to be able to open the windows with those sizes at any time, so I think this makes it different from reopening a windows from a saved file, in which you only read it at startup.

Still guessing stuff here :slight_smile: , but I just wanted to point out that things that seems obvious from the user point of view might not be that easy, or immediate to implement.

Everything can be improved and fixed of course, but it is slightly more complex a problem that it might seem at first.

An important thing to know is that we don’t actually have a separate “Preferences” window at all. We have exactly one “temp” window that we reuse for different purposes. You can easily get a sense of this: render a still to the “render window” then move that window somewhere else, like to a different monitor, then open Preferences and see that it replaces the render window at exactly the same place.

So we can’t have a popup File Manager at the same time as Properties or a Render window. This issue goes a bit deeper…

1 Like

To overcome this, I created a new Workspace “System” and one of the viewports in there is the preferences, e.g.

In a post on Developer Blender Pan Beeb posted a small piece of code. What it does is set render window mode new window opens this window using some settings and switches to Preferences. After testing this works perfectly. Though his approach did not store the prior settings to the render size. So i stored those. I made a simple addon for it and works like a charm :slight_smile:

This video was prior before i added height also being able to be adjusted

For those interested, you can find it here. I added width and height. The panel is a different vs the normal one, we dont see the hamburger menu in the bottom left. You can still save it from the “Preferences” button you see at the bottom

1 Like

While it’s cool, this is definitely not something that should be an addon :slight_smile:

1 Like

True, but do you have a better solution?
Since i see the requests made 2-3 ago, perhaps even longer and no adjustment being made. For the time being this is nice.

I did something similar with posting bugs. Currently, we have this automated method, i actually made that myself before they introduced about the same thing. I was done trying to find the data and do repetitive steps, adding the system specs in the bug post. I made simple addon which copied the current has tag so a user could only needed to paste it. At the time that was the most important thing, finding or memorizing that tag was just a paint. I posted it on RIghtClickSelect and some time later a much better method showed. I was quite baffled such a simple thing wasnt implemented earlier/ I guess lots of peeps didnt report anything just because of this hastle.
Here you can see the much better improved version

It should not not be an addon like you said, but for the time being it does solve an “issue” for some people and i therefor i hope it helps. Perhaps some dev catches it and thinks “hey this is usefull”. Thats how this community seems to work right :slight_smile:

1 Like