Make pie menu item placement touch the radius from the internal side of
the buttons rather than placing on the center on the cirtcle. This
allows us to get rid of the separate visual angle property, also allows
for tighter placement of pies with a smaller radius without easily
overlapping.
Also pie menu title now always appears above the threshold indicator.
This commit merges the code in the pie-menu branch.
As per decisions taken the last few days, there are no pie menus
included and there will be an official add-on including overrides of
some keys with pie menus. However, people will now be able to use the
new code in python.
Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/
Thanks:
Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review
and design comments
Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for
suggestions during the development.
Special Thanks to Sean Olson, for his support, suggestions, testing and
merciless bugging so that I would finish the pie menu code. Without him
we wouldn't be here. Also to the rest of the developers of the original
python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who
did the research and first implementation and whose code I used to get
started.
When menus are clamped to the window bounds,
its was possible not to have an active menu-item under the mouse,
Making Ctrl+S,Enter not completely reliable.
Changes needed to support this are:
- menu item is activated on popup menus
(to avoid relying on mouse-over)
- moving mouse away from menu items only de-activates when over a new menu-item.
- Mouse clicks are ignored if they are not directly over the menu item.
Yep, at last it's here!
There are a few minor issues remaining but development can go on in
master after discussion at blender institute.
For full list of features see:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting
Thanks to Sergey and Campbell for the extensive review and to the
countless artists that have given their input and reported issues during
development.
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)
