Patch Builds: Saving Temporary Window Sizes & Positions

Yeah those are better obviously :slight_smile: 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.

1 Like

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

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.

image

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 :partying_face:

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

2 Likes

What do you do with the render zoom setting? is it auto zoomed to fill the size of the window or will it stay at 100% zoom level?

Just try it, there are links to builds in the first comment.

Sorry, I meant that more as a design question. There’s mutiple scenarios, I think:

  1. render → close render window → re-render
  2. render → close render window → change render resolution → re-render
  3. render → close render window → open render window
  4. render → quit Blender → open Blender
  5. render → close render window → clean up unused data blocks → open render window
  6. others?

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.

Preferences screenshots




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?

A picture’s worth…

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.

1 Like

Build Intel mac e1dfaa7438a1 not working properly yet.

2560x1440 @ 1x BENQ monitor + built-in 2880x1800 @ 2x display

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.

Not sure what this means. What is “cancel the action” separate from closing the Preferences window?

Pressing the Cancel button.

Hey, this site doesn’t charge by the word. LOL.

Following is part of your screenshot:

You are saying that it “does remember size when you close the window” but not when you press “the Cancel button”

I don’t see a cancel button, except the red button in the title bar. What is the other way of closing this window?

Holy shit, I am so sorry, I meant to write File Browser. Edit:

Ah, makes perfect sense. In this same thread I kept writing “Properties” when I meant “Preferences” so I understand. But for this I was worried that I was missing something on how Macs work. Thanks!

1 Like

Sorry if repeating, I didn’t read the whole thread, but here is my humble little penny:

I found it really annoying not to be able to move/remove this panel; also Blender does not remember nor save with start-up file its status: closed, reordered, etc…


In my workflow Bookmarks and Recent are the most useful panels over System, so I want them to be placed in a more easy access place.

2 Likes

I don’t think it’s in the scope of this particular patch, but you can remove that panel from Preferences > Save & Load > File Browser: Show Locations:

2 Likes

Damn! That easy!

Sorry for off-topic, and many thanks!!!