While drawing nice 'rounded' values is OK also for 'low precision'
editing like dragging and such, it's quite an issue when you type in a
precise value, validate, edit again the value, and find a rounded
version of it instead of what you typed in!
So now, *only when entering textedit of num buttons*, we always get the highest
reasonable precision for floats (and use exponential notation when
values are too low or too high, to avoid tremendous amounts of zero's).
Adds a version of template_ID that can be used for non-ID properties.
The property to search for and the collection to search in has to be
passed to it.
Like template_ID it also takes arguments to define a 'new' and 'unlink'
operator. They will be displayed as icon-only buttons then.
Also added a version that can display preview thumbnails.
Had to do some additional changes to make text-buttons support
displaying/modifying empty RNA properties.
This will be needed for workspaces, see D2451.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D2666
Hi Guys,
as one of my clients needs the possibility to have custom menu entries in the general right click menu (all over Blender: in the node editor, properties, toolbars,..) I talked with Campbell about expanding our hard coded menu a bit. This is the outcome. As I only need those two, I support currently a button_prop and a button_pointer.
{F540397}
I tested the changes with a custom script where I added a custom entry and executed an operator on click - it seems to work exactly how it's intended to. The script: {F540435}
As I'm not too experienced in rna stuff I would really appreciate any review.
Thanks very much Campbell for his open ears & help on this issue!
Reviewers: campbellbarton, mont29
Reviewed By: campbellbarton, mont29
Subscribers: sybren, mont29
Tags: #addons
Differential Revision: https://developer.blender.org/D2612
NOTE: This is really a backend-only implementation, nothing is changed in the UI
Adds a tab button-type and the basic drawing and handling code for it.
More work needs to be done on it, but idea is to get in ready for usage in the
topbar.
Differential Revision: https://developer.blender.org/D1371
When rendering multi-view in side-by-side or top-bottom mode, we squash
the UI to half of its size and draw it twice on screen. That means the
cursor coordinates used for UI interaction don't match what's visible on
screen.
This commit is a little event system hack (tm) to fix this. It has some
small glitches with cursor grabbing, but nothing to bad.
We'll also use it for viewport HMD support.
D1350, thanks for the feedback @dfelinto!
Adds two buttons to context (RMB) menu of path buttons:
* "Open File Externally" to open a file in an external app (only visible if path contains a filename)
* "Open Location Externally" to open a path in an external file browser
The functionallity for this was already there, just hidden behind Shift/Alt click of file_browse button (folder icon next to path button).
This means editing a property will now always affect all selected objects, bones or sequencer strips. Support for this was added in rBdfbb876d4660 but you had to hold the Alt-key to use it. The old behavior of only editing the active object will not be kept like decided in the 2.8 workflow meeting (reports comming). If you only want to edit the active object, you have to deselect others.
There are still a couple of issues to be resolved (listed below), but having it enabled by default helps testing and getting used to it and should motivate us to fix them ;)
To be fixed:
* Give users hint when edits are applied to all objects/bones/strips ("Applying to x objects") - there are ideas but we need to finalize and implement them
* Make it work better in corner cases (material editing, modifier property editing, etc)
Note: Values usually override the initial value of the object/bones/strips, except of number buttons where it depends if you enter the value (absolute override) or drag the value (add value change). This behavior is consistent with multi-button editing.
Also use the operator as part of the UI keymap now, to deduplicate code and let
users configure a custom shortcut.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2303
It's now possible to change the shortcut for invoking the eyedropper while hovering a button (E by default). Also removed the keymap editor entry for the modal eyedropper keymap, it's now automatically appended to the eyedropper shortcut.
Steps to reproduce:
* Go to modifier context in properties editor
* Add modifier, collapse it
* Press down LMB over collapse button of modifier, hold it
* Drag over pin-icon in properties editor (to keep fixed data-block displayed)
* Drag outside of window bounds (should crash)
Also could've solved by getting space data from callback arguments instead of context, but this fix is much nicer (though not totally un-risky).
Issue was that the wm.open_mainfile OP caused all handlers to be removed and since rB45592291 cancelled (which is correct in general), the menu that triggered the OP should not be cancelled though.
Not sure if this is a nice fix or not, it's however the safest fix I found. A different fix would be to call UI_popup_block_close before WM_operator_call_ex (in dialog_exec_cb), but not sure how safe this is and want to further investigate if it makes other hacks/fixes redundant.
There's still a crash with --debug-memory that confused the heck out of me (since I always have --debug-memory enabled), but I'll commit fix for that separately.
When WITH_INPUT_NDOF is disabled, 3D mouse handling code is removed
from:
- GHOST (was mostly done, finished the job)
- window manager
- various editors
- RNA
- keymaps
The input tab of user prefs does not show 3D mouse settings. Key map
editor does not show NDOF mappings.
DNA does not change.
On my Mac the compiled binary is 42KB smaller after this change. It
runs fine WITH_INPUT_NDOF on or off.
Number buttons & sliders weren't updating when shift/ctrl were pressed.
Note that this is a regression in 2.77 but hard to track down since it worked unreliably for some time.
The Curves widget has buttons to zoom in on the curve. However the
click detection code doesn't take it into account, and at full zoom
in click on curve is detected very far from the actual visible curve.
Change it to compare the position to the actual line segments
in the UI coordinate space, i.e. with curve zoom applied.
