Page MenuHome

Preferences options for temporary editor display type
Needs ReviewPublic

Authored by Julian Eisel (Severin) on Wed, Sep 11, 1:07 PM.

Details

Summary
  • Move render display mode option to preferences
  • Refactor temp space opening to support multiple display types (new window vs. fullscreen
  • Preferences option for file browser as window or fullscreen

We could add preferences for other temp windows as well, namely Preferences, Drivers and the new Info Editor one. This patch makes that easy to do.

Diff Detail

Event Timeline

Julian Eisel (Severin) retitled this revision from Preferences option for temporary editor display type to Preferences options for temporary editor display type.Wed, Sep 11, 1:16 PM

Here are the relevant mockups for the patch presented

source/blender/editors/render/render_view.c
159–160

We can just pass the string here and do IFACE_() when setting the title. Just a little oversight.

source/blender/editors/screen/screen_edit.c
1351

Typo: display type -> display_type

source/blender/windowmanager/WM_api.h
157–163

There is no good reasons for these to exist. Just passing the space type and a window title is all we need.

source/blender/windowmanager/intern/wm_event_system.c
2398–2436

Maybe this closing logic should be moved into a ED_screen_temp_space_close(), although I'm a bit unsure which parts after calling wm_window_close() should be in a general function and which are specific to the file browser.
Right now the file browser would be the only caller anyway.

release/scripts/startup/bl_ui/space_userpref.py
269

I think we can find a better name for this, "temporary" is not that clear.

Can't immediately think of some good, maybe "Opening Editors"?

source/blender/editors/render/render_view.c
159–160

IFACE_() is used both to translate the string and detect translatable strings, so I think it needs to remain here?

release/scripts/startup/bl_ui/space_userpref.py
269

How about Intrusive Editors or Interrupting Editors?
At least for most editors that fits, because they do interrupt the workflow. Not sure if that fits for the render display though.

source/blender/blenloader/intern/versioning_userdef.c
624–625

I think I will also update subversion in the final commit. (Avoiding that in patches because of merge conflicts.)

Perhaps we could call this section Temporary Windows.

"Intrusive" or "Interrupting" sounds too negative.

I'm fine with "Popup Windows", "Temporary Windows", "New Windows", ... . Anyway, you guys can decide, it doesn't matter that much.

Bastien Montagne (mont29) updated this revision to Diff 18247.
  • Rename Preferences panel: Temporary Editors -> Temporary Windows
  • Fix typo in doxygen comment

Why the hell... I've gotten Bastien's former machine in the Institute, changed the git config - the commits have me set as author - created new SSH keys, created a fresh checkout, ... but Arc still pushed this with Bastien's account...
Sorry about this, checking what's going on.

Julian Eisel (Severin) updated this revision to Diff 18248.EditedSun, Sep 15, 8:26 PM

Checking updated arc credentials
[No changes to the patch.]

There we go, had to manually run arc install-certificate to bind arc to my account.
Sorry about the noise.

Overall approach seems fine, although only having one temp screen seems a bit strange.

For example

  • open user preferences.
  • press Ctrl-O.
  • The file selector opens in the preferences window.

Wouldn't it be best to allow a single temp window per type?

Overall approach seems fine, although only having one temp screen seems a bit strange.
For example
[...]
Wouldn't it be best to allow a single temp window per type?

Definitely, yes. We were planning to address that separately, see T69652.

We didn't talk about making this per type, although I had the same thought, you'd probably not want to open the same type multiple times.

Exactly - I think they should be per type too, so that you don't end up with loads of Preference or File Browser windows.