| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts commit 7f3dcbe17feccb99abbdbc3aea83189696d97391.
Please check with authors first, this bug was already fixed since RC1.
|
|
This reverts commit 7b0c327b943d4c4a3b212844ea2d4dfcc77f0556.
The problem with this commit is that the "move to layer" functionality by hitting M,1 f.e. didn't work anymore...
Campbell, would be great if you could look into this again, as I'm not experienced in this specific region..
|
|
|
|
It could still crash if the window was freed and another was activated. see T44688.
|
|
Related to T44688, note supporting this case isn't so nice,
but seems it can be made to work.
|
|
|
|
It was possible to perform actions while performing a drag-toggle.
|
|
|
|
Removed call which was still needed
|
|
Some of them are just brain dead code, some are potential bugs.
|
|
|
|
Our current keymap doesn't give us enough room to make such changes in
the event system. To fix small issues caused by this, we would need to do
drastic changes in Blender's keymaps and internal handling. It was worth
a try, but it didn't work.
I can write down a more descriptive statement in a few days, but for now
I need a break of this stuff.
|
|
Design task: T42339
Differential Revision: D840
Initial implementation proposal: T41867
Short description:
With this we can distinguish between holding and tabbing a key. Useful
is this if we want to assign to operators to a single shortcut. If two
operators are assigned to one shortcut, we call this a sticky key.
More info is accessible through the design task and the diff.
A few people that were involved with this:
* Sean Olson for stressing me with this burden ;) - It is his enthusiasm
that pushed me forward to get this done
* Campbell and Antony for the code and design review
* Ton for the design review
* All the other people that gave feedback on the patch and helped to
make this possible
A big "Thank You" for you all!
|
|
Internal change only,
use UI_BTYPE_SEARCH_MENU with an unlink flag instead.
They are really the same button type, one just happens to have the option to unlink.
|
|
|
|
This adds back rgb_to_grayscale,
not all color is managed or depends on the current loaded blend file's CM options.
Noted in comments that this is only to be used outside the CM pipeline.
|
|
calculations and use the OCIO one instead.
|
|
|
|
Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)'
and 'strcmp(foo, bar) == 0' in several places...
|
|
Both were maked as temp, but used often.
Now pass uiFontStyle to both, rename UI_draw_string to UI_fontstyle_draw_simple,
since its a variant of UI_fontstyle_draw that skips shadow, align... etc.
|
|
Differential Revision: https://developer.blender.org/D928
|
|
|
|
|
|
|
|
Make the UI API more consistent and reduce confusion with some naming.
mainly:
- API function calls
- enum values
some internal static functions have been left for now
|
|
Positioning of popups was using shadow width for placement,
could give some quite odd results.
|
|
|
|
Decouple color picker hsv data from the whole block. Basically, each
color picker now takes care of creating its own color picker role. For
this bug report it can be seen that probably HSV is not the best space
for gamma/lift/gain workflow because it is bounded at 1.0 but this is a
separate issue.
|
|
Operators that trigger UI events (but nothing else)
were using 'CANCELLED' making it impossible to tell if an invoke
function failed, or opened a menu.
|
|
* 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.
|
|
width is set to 0 in theme prefs.
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.
|
|
|
|
D634 by Severin
|
|
|
|
|
