Yeah those are better obviously Maybe “Last size”. Both fine.
I’m not married to either options, it’s a set-and-forget option anyways. But I usually appreciate it more when things are spelled out (“Remember last size and position”) instead of having to guess from shorter, more esoteric titles. Not a big deal though—maybe that’s the job of the tooltip.
I have updated the download links and the description in the first post. The build now makes File Browser, Preferences. Drivers, and Info Log Windows remember their sizes and positions.
Render window behaves as it does now by default. But you can select a new choice in Preferences / Interface / Editors / Temporary Editors / “Render In” to make it load using the last size and position, ignoring render dimensions.
Haven’t tested the new build yet, but my expectations would be to Blender remember size and positions of windows globally.
I don’t know about how people are entrenched in the behavior or Render window to expand to accommodate the render size but I, personally, would still expect it to behave globally consistent with the rest of separate window: remember window size and positions. I strongly dislike when UI lives it own life and behaves unpredictably. In this case, change the size of the window on render time.
If users really need this behavior (which I can’t yet imagine why) there should be an option exclusively for render window.
Blender has tooltips for more expanded explanation of feature/option names. So the default names could be shot so not to clutter the UI.
Taking back my words a little bit back. I guess, I can see value in these workflows. But I’d love to hear from users who use other options and their use case in details.
I almost never touched these settings after I’ve setup things initially.
Some options feel weird for Render In. The fact that there is a separate category for how windows should behave feels weird. I think it’ll need rethinking and reduction in complexity at some point in the future if you’ll need to keep adding option to control how windows behave. There should be one predictable behavior consistent with general rules for similar UIs and maybe one or, maximum, two special case exceptions.
For example, if this patch gets accepted, you can easily remove File Browser option as redundant. All you have to do is just expand it once and the next time Blender will open it expanded. Which is not the case right now, unfortunately. But I believe it should be. Your patch also should remember if window was expanded or not for all the windows. It’ll allow removing at least one extra UI option.
For Render window behavior control, I would keep in the list only one option New Window and add the tick below where it should be Auto Size or not when this option is selected.
Truly great you are working on this! I’ve immediately merged it into my own Blender build – no more repetitive dragging and resizing for me
“Drivers Editor” window is working fine, I tested it.
And personally I like the ‘New Window - saved’ preference for the Render window. I like a big render window, hiding distracting stuff beneath it and allowing to zoom in/out the render easily. That preference gives me the feeling that it’s me in control, not Blender deciding what’s best for me.
render → close render window → clean up unused data blocks → open render window
I think the build link is not updated in the first post, I downloaded today’s build D16948 from Builder.
On Intel mac, something’s off. It remembers the preferences window size, but the position keeps skipping towards the bottom left on each re-open.
For renders — I’ll comment on case 3 as I don’t know what the intended behaviour is currently — it doesn’t remember window size, and the position keeps skipping on each re-open until after a couple times it’s back in the top left.
I’m not understanding what you are suggesting. If you have specific ideas that improve specific circumstances, feel free to spell them out in detail.
Yes, Mac Retina displays have to be dealt with carefully. It is great feedback that it remembers size, but not position correctly. I have updated the patch and the build links in the first comment with a version that will (hopefully) work correctly.
Hey, I’m hoping you can also do me a favor and describe the differences on Mac between our current File Browser and Preferences windows.
On Windows we purposely treat these two the same. So both have identical window decoration, can be moved, resized, minimized, and maximized. But on Mac they are treated differently but I’m not certain of the effect. Can you describe their differences?
And, more importantly, are those differences expected and ideal? Or would you prefer that they both act like one or the other?
To open a file, most macos native apps open a decorationless window that’s not attached to the main window, so it’s non-modal, similarly to the Preferences window. This is nice cause it doesn’t block you from swapping back to the main window and continuing work, while keeping e.g. the Open File window open.
I assume the File Browser window is treated differently because it’s modal? Or is the modality a consequence of the window treatment? Not sure how the programming logic works out there.
Sorry, I should have taken more time for this. I’ll do some more testing with the new build tomorrow. I was just thinking of how to handle the scenarios I wrote abvove. Ignore.
Windows keep skipping to the left on each re-open. The culprit here is the Dock, I believe. It can also be positioned left or right on the screen.
Preferences File browser does remember size when you close the window, but not when you cancel the action.
When the main window is on one monitor and preferences on the other, it does not remember that position: on re-open it jumps back to the monitor the main window is on. Importantly, it also visually doubles or halves the size of the window. I assume this has to do with not accounting for PPI scaling.