* Only use last key for pies if it hasn't been released already
* Confirm threshold is now measured as distance after regular threshold.
zero disables.
* Only display the confirm threshold if there's a valid direction (mouse
is after threshold).
* Calculate confirm threshold taking recentering into account
This commit adds a confirm threshold property to pie menus.
Basically, this will confirm the pie menu automatically when
the distance from the center of the pie exceeds that threshold without
a need to release the pie button.
The confirm threshold will only work if it is larger than the pie
threshold.
The confirmation actually occur when the mouse stops moving, to
allow multiple pie menus to be better linked together, (see below)
This functionality also facilitates the ability for chained pie menus by
dragging. Basically, a pie menu item can be a call_menu_pie operator and
the new pie menu will still use the original pie menu release event for
confirmation. This should allow for quick, gesture based navigation in
pie menu hierarchies (going back in the hierarchy is still not supported
though)
There will be a demonstration pie in the official add-on soon
Issue, after a lot of blood sweat and tears, was found in
ui_but_update_from_old_block, where we restore a button to its old
values when possible. The problem here is that a1 and a2 are not really
meant to store temporary variables, because they tend to get overriden
and palette selection is one of those temporary states.
Instead, we now store the position of each button in the palette in a2
and pointer to the palette in the customdata pointer of each button and
use that to test if it's active. The positions won't change when
clicking so we are guaranteed that the old button won't override the new
one with garbage.
It's still hacky but it is better than testing button types when copying
old values.
For some reason, labels of buttons in popups/menus were clipped left.
Removed that function (was the only place were it was used), clipping text
by its left is really bad for its understanding!
Instead, extended clip_middle code so that it optionnally preserves a right piece of
the given string (like the shortcut part of a menu label). Think that's what makes
more sense here (note that most menus adapt themselves to their longest item,
we do not have much fixed-width ones, anyway).
Also tweaked a bit clip_middle logic, so that left part always have at least ten chars
(in addition to already existing 'min width' checks).
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.
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.
* Buffer icons are usually in straight space (since we load from pngs)
so use src_alpha in OpenGL for blending.
* Allow blending for preview icons. This will be useful for the next
commit...
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 was supposed to fix inaccuracies between S-H wheel but it makes the
colors selected through the SV-H color cube wrong (see http://
%28SV-H%29-Inaccurate). Instead of deactivating color management for SV
and H widgets just reenable correction for the Hue wheel. This is wrong
because HSV always refers to display space and we -have- to account for
that when using linear color RNA properties.
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
Enum icon-only buttons were getting their strings set,
then truncated with blenders string shortening methods, then not drawn
because there was no room (since buttons are icon width).
Modify UI code so icon-only buttons don't get names and passing "" to a
button won't have its text set later on.
Note this commit only makes search menus wider and adds shortening to their strings.
Adding tooltips here is not trivial, would need much bigger changes...
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D341
Adds some padding to the left of the icon, adds more space around the separator
line and make it more visible, and add some spacing at the top and bottom of
the menu. Ref T37794
Reviewed By: dingto, billrey
Differential Revision: https://developer.blender.org/D223
