Preferences options for temporary editor display type
AbandonedPublic
Actions

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

Details

Reviewers

Campbell Barton (campbellbarton)
Brecht Van Lommel (brecht)

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

Repository

rB Blender

Build Status

Buildable 4963
Build 4963: arc lint + arc unit

Event Timeline

Julian Eisel (Severin) created this revision.Sep 11 2019, 1:07 PM

Harbormaster completed remote builds in B4903: Diff 18095.Sep 11 2019, 1:07 PM

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

Julian Eisel (Severin) added a project: BF Blender (2.81).

Here are the relevant mockups for the patch presented

Julian Eisel (Severin) added inline comments.Sep 11 2019, 1:25 PM

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.

Brecht Van Lommel (brecht) added inline comments.Sep 11 2019, 1:47 PM

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?

Julian Eisel (Severin) added inline comments.Sep 11 2019, 10:52 PM

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.

Martin Capitanio (capnm) awarded a token.Sep 13 2019, 11:30 AM

Rename Preferences panel: Temporary Editors -> Temporary Windows
Fix typo in doxygen comment

Harbormaster completed remote builds in B4962: Diff 18247.Sep 15 2019, 8:13 PM

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.

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

Harbormaster completed remote builds in B4963: Diff 18248.Sep 15 2019, 8:26 PM

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?

In D5754#133422, @Campbell Barton (campbellbarton) wrote:

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.

Julian Eisel (Severin) mentioned this in T69652: File Browser GUI: Planned Changes for 2.81.Sep 16 2019, 7:39 PM

FWIW, tested this, seems to work as advertized.

Committed rB95373e2749, rBf5bbaf55ac, rBcac756a92a.