* 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
The reason being, with the current system of quick selection, it's
possible to spawn an operator after confirmation, especially for cases
with modifier buttons.
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
Basically, this commit changes pie menu click interaction so that
confirmation is done on left click release instead of press. This allows
dragging on the pie menu to select different items, but most
importantly, there should be no left over click events passed on to
subsequent menus/pies. This means that pie menus should now be able to
spawn popups safely. Also, left clicking to spawn a second pie menu now
sets that menu to click style by default allowing for better interaction
between hierarhies of pie menus.
First one, reported by Sergey, was searchbox not closing when validating it (enter or LMB click)
without any active item (we need to enable escapecancel here, to close menu too).
Second one was SEARCH_MENU_UNLINK variant not unlinking at validation when no active item.
Thanks a bunch to Campbell for help here!
Tool-tips and header-text used a different pixel alignment from the rest of the UI.
This causes blurry text with multi-sample with NVidia.
Other text still needs the issue resolved (View3d info for eg)
Currently there are inconsistencies with pixel alignment.
but this commit has no functional changes.
- wmOrtho2_region_ui for UI/Text.
- wmOrtho2_region_pixelspace for 2D drawing.
- wmOrtho2_pixelspace - when the region isn't used.
This is more like a workaround actually, we use a fixed 'margin' for height in case of search menus,
instead of using shadow width (which gave the bug with low values, and insane margins with big ones).
Note root of the issue is that if 'top' margin is too small, the first entry of the search menu
gets activated before the 'opening' click is released. This means that button will get the
KM_RELEASE event, and immediately quit (see interface_handlers.c:7945, ui_handle_menu_button()).
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.
- left aligned
- higher contrast between tip text and py-text
- use monospace for py-text
D611 by Severin, design by Plyczkowski, with own minor changes.
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.
View2D had some inconsistencies making it error prone in some cases.
- Inconstant checking for NULL x/y args.
Disallow NULL args for x/y destination pointers, instead add:
- UI_view2d_region_to_view_x/y
- UI_view2d_view_to_region_x/y
- '_no_clip' suffix wasn't always used for non-clipping conversion,
switch it around and use a '_clip' suffix for all funcs that clip.
- UI_view2d_text_cache_add now clips before adding cache.
- '_clip' funcs return a bool to quickly check if its in the view.
- add conversion for rectangles, since this is a common task:
- UI_view2d_view_to_region_rcti
- UI_view2d_region_to_view_rctf
- BLI_ghashutil_strhash_n takes string length, to avoid terminating the string before hashing.
- BLI_ghashutil_inthash/uinthash take ints, to avoid casting to (void *)
This also showed up incorrect use of inthash, which was using a pointer.
HSL sliders jumping. The issue here is that we store HSV in display
space.
To correctly account for that, made sure HSV/HSL is now using the
displayed
color to compute the values in the sliders. RGB values still show
the property values (linear for linear, gamma corrected for gamma
corrected)
We could change the way we store HSV uniformly (ie in all the code), but
we would need to add many more conversions in the picker code to account
for storing it that way. Also it doesn't make sense: Color pickers
should help with -visible- color selection. It may
be worth changing the RGB sliders as well.
My fix takes into account the way HSV is stored in HSVCube as well in
the code.
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
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