This is needed for popups to chance state once activated,
currently it makes use of operators `check` callback, after values are modified,
as the file selector does already.
Text field part. Issue with enums dropdowns remains a mystery currently.
As for pointer fields, afaict they have never worked here, though it should
not crash.
UI_EMBOSS are values, not bitflags (own fault, most likely)...
Note we should probably get rid of UI_EMBOSST, it is used nowhere in UI code (set
in one place only, used nowhere).
This deduplicates/simplifies some code. Also cleanup up a bit scopes UI code!
Use new GRIP button for uiList grab-resize.
This allows us to greatly simplifies the code, and get rid of a few hacks in uiList event handling!
Note autosize mode of uiList is now trigered by any value of list_grip below a given threshold, rather than the fixed zero value...
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D343
This is done by adding a new button type, GRIP, similar to other numbuttons
(scroll, slider, ...), which here controls the preview height.
Then, we add a new DNA struct to be able to save that height in Blend files
(note I choose not to use Panel struct for this, because we would then have the
same limitation we used to have with uiLists, only one preview per panel
and no preview outside panel).
This implies a change to template_preview UI RNA/py API (each preview needs an ID),
but this is backward compatible, as by default datablock type will be used if no ID is
given (which means e.g. all material previews with no ID will have same height).
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D342
Make HSL wheel useful in compositing.
In HSL, 0.5 lightness corresponds to most vibrant colors so make that
default for locked wheels (previous value of 1.0 just made it white).
Also, unlock the wheel for both very bright and very dark colors.
and value/lightness slider stops midway.
Issue here is manyfold:
Color wheel does not support properties with different soft min/max
values than 1.0 (which after experimenting a little I left as is), and
also color management is completely destroying the mapping between the
value slider and the RNA property value range. To solve this I have
disabled color management by setting the property to gamma corrected
(only in RNA, Sequence editor coders please check!), otherwise it will
just become a big mess of tracking where color comes from and what kind
of color transforms it needs in different color pickers (if property has
non normalized range etc). HSL is not really meant to represent colors
outside a normalized space so I have disabled setting lightness above
1.0 in this model.
This will work, however it is hacking a color picker to do something
other than what it is supposed to do: pick a color from the screen
accurately. Which means normalized values always. The non normalized
colors picked for lift/gain/gamma through the pickers do not correspond
to any accurate colors; they are rather a user friendly way to 'sort of'
choose a color and a gamma with an indication of maximum value.
I think that lift/gamma/gain nodes need a dedicated widget for this
(besides it is quite clear that some options are written for that use
case) -or- a separate gamma multiplier for the picked color (which
should itself be in a normalized space)
This is a standard Hue - Saturation - Lightness model
(see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV)
Note though the difference between HSV and HSL saturation, which are not the same.
The advantage of having this color selection scheme is that artists can select
shades and tints of a color easily by using the lightness slider. Also colors
are arranged on (approximated) perceived lightness on the color wheel.
Beware, Old files opened with this preference saved will crash!
Reviewers: sergey, brecht, campbellbarton
Differential Revision: https://developer.blender.org/D385
This mitigates T38505, where moving the mouse while using the wheel/keys
can exit the submenu.
So at least smaller unintentional movements won't be misinterpreted.
Previously 1/3 of the button was used to decrement, 1/3 to edit and 1/3 to
increment. However with the number text now right aligned this meant that
the increment area would overlap the number text, which is confusing. So it
was made to smaller to only cover the arrows.
It's not as easy to click but I don't know of a better solution with right
aligned number text.
- swap Z/Y axis so Z changes hue and X/Y change location.
this way you can use ndof like a joystick and Z rotation like a dial
for the hue.
- change sensitivity when shift is held to be 1/5th
