Requiring context means we can't easily create new editors to replace deprecated
ones in versioning code.
Think it's reasonable to give editors access to scene and area data for their
initial setup though. They mostly need it for setting "the view", as in,
scrolling values.
Also did minor cleanup in top-bar creation function.
Engine is not stored in WorkSpaces. That defines the "context" engine, which
is used for the entire UI.
The engine used for the poll of nodes (add node menu, new nodes when "Use Nodes")
is obtained from context.
Introduce a ViewRender struct for viewport settings that are defined for
workspaces and scene. This struct will be populated with the hand-picked
settings that can be defined per workspace as per the 2.8 design.
* use_scene_settings
* properties editor: workshop + organize context path
Use Scene Settings
==================
For viewport drawing, Workspaces have an option to use the Scene render
settings (F12) instead of the viewport settings.
This way users can quickly preview the final render settings, engine and
View Layer. This will affect all the editors in that workspace, and it will be
clearly indicated in the top-bar.
Properties Editor: Add Workspace and organize context path
==========================================================
We now have the properties of:
Scene, Scene > Layer, Scene > World, Workspace
[Scene | Workspace] > Render Layer > Object
[Scene | Workspace] > Render Layer > Object > Data
(...)
Reviewers: Campbell Barton, Julian Eisel
Differential Revision: https://developer.blender.org/D2842
Since we already have a rather advanced PovRay exporter, makes sense to
also nicely display generated 'code'.
Patch by Maurice Raybaud (@mauriceraybaud), thanks!
Cleanup (mostly styling) by @mont29.
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
Apparently this is the result of some sloppiness during 2.5 project and since then it confused people who were trying to understand the area-region relation (myself included).
Sorry if this causes merge conflicts for anyone, but at some point we really had to do it :/
This can freeze Blender if you accidentally press ctrl+m on a large
script, conversion from text to 3d objects is fairly special case,
restricting access to the menu only.
There is a bunch of internal refactoring going on too:
* No longer use operators to handle these directory and file fields, only makes
things more complicated than they should be.
* Handle autocomplete partial/full match deeper in the UI code
* Directory field still does not keep focus, that's for another time to fix,
you can already do pretty quick keyboard only navigation with the file field.
Reviewed By: elubie
Differential Revision: http://developer.blender.org/D29
node materials.
Area and region listener callbacks now get the screen and area pointers passed, so
they can do more fine grained checks to see if redraw is really needed, for example
depending on the 3D view drawtype.
In text editor, the CTRL+F find now opens property region (or keeps it) and
activates the search button for input.
That's already nice! But next step should be to do a search on exit of
the button (or while typing). That's stuff I need Campbell to help with though.
Notes:
- Probably Py api for property buttons could get an "operator=" arg?
- The warning menu "not found" should go away
- I also suggest to make "wrap" search default for new editors
CTRL+F in text editor now also works in the button region.
Added generic keymap for it, could get other shortcuts as well. Will leave it to the
maintainers :)
- This doesnt use python as 2.4x did, instead it just autocompletes based on the text files unique identifiers so its useful for any language.
- key is same as console (Ctrl+Space)
from Patrick Boelens (senshi). with modifications to split it into its own function.
also added C style multi-line comment support /* ... */
I've left out the part of this patch that sets the language in the space, since I think this might be better stored in the text block.
For now it simply uses OSL syntax highlighting when the extension is '.osl'.
Submitted by: Justin Dailey (dail)
Patch allows the current line (or selected lines) to be moved up and down with
Ctrl+Shift+Up and Ctrl+Shift+Down. Has undo/redo support and operators in python
menu.
