It's still not completely working - there are still some glitches - but far better than before.
To make buttons of the uiList work, you have to add a 'check' callback to the operator that invokes the menu. Only if it returns True, the uiList gets refreshed. To avoid this we have to make the region refresh tagging in the entire button handling a bit smarter.
Changes I had to do:
* Call uiList handling from menu/popup handling if needed.
* Make uiList handling use special popup refresh tag if placed in menu.
* Allow popups invoked from py operator to tag for refresh by using operator 'check' callback.
* Tag popup for refresh when resizing uiList.
Mostly fixes T48612.
Caused by wrong alpha value in rB34b30f847429ac (used 0.01, should've been 0.1). Also made sure all editors initialize same default theme values for panels and cleaned up code a bit.
Works fine with old userpref.blend files.
Shift-space was reserved for IME support, however IME will only
be enabled on certain languages. We can avoid any IME-related
exceptions form other languages without too much trouble.
There's one weak point around ui_ime_is_lang_supported() tho,
which is it might be doing string comparison a bit too much
often now, this we can avoid by handling those checks from BLT.
Part 2 of Fix for T48200. Without this, it's not possible to exit GPencil edit mode using tab key with pies enabled.
Menus are somehow similar to operators, which let the event pass through too after operator poll returns 0. So think we should handle them similar here.
Can't guarantee this is totally safe though ;)
Cursor is now set to standard arrow-cursor when opening menu, and reset to previous one when closing it. Previously it just stayed as it was before, e.g. the edit mode cross-cursor stayed active even if a menu was opened.
Fixes T48192.
This commit makes disabled/inactive color swatches look more obviously disabled
by halving their alpha values. It is necessary because the results of
ui_widget_color_disabled() (which is usually used when disabling widgets)
get overwritten by the color filling code here.
To avoid confusion, the checkerboard background (when the color genuinely has
alpha) will still only show in those cases. That is, when disabled, color swatches
won't show the checkerboard unless the color actually has an alpha component if it
wasn't disabled.
* This includes the "manually create" modes, which correspond to the previous behaviour
for setting up drivers. This is necessary when the current screen layout is not
well suited to having multiple property editors open (e.g. small screen or heavily
subdivided screen).
* Only the modes relevant for the current property type (i.e. array vs single)
will be shown
* The "Add Driver" entries in the RMB context menu have now been replaced by a
submenu which will list all the available mapping types.
* NOTE: The code for the ANIM_OT_button_driver_add() operator is perhaps a bit hairy.
However, it currently allows us to have the desired behaviour. It can always get
cleaned up later though.
Caused by rBc24be7ec6e5.
Before rBc24be7ec6e5, wm_handlers_do always called handlers a second time with event value KM_PRESS in case of a double click. After it, this was only the case for non-LEFTMOUSE events.
Since ui_popup_handler (almost) always returned WM_UI_HANDLER_BREAK, the second handler iteration with KM_PRESS wouldn't run. This fix just makes sure we return WM_UI_HANDLER_CONTINUE for double click events instead (causing second iteration to run).
This commit brings some long requested improvements to the workflow for setting up
drivers, which should make it easier and faster to set up new drivers in a more
interactive fashion.
The new workflow is as follows:
1) Hover over the property (e.g. "Lamp Energy" or "Y Location") or properties ("Rotation")
you wish to add drivers to. We'll refer to this as the "destination"
2) Ctrl-D to active the new "Add Drivers" eyedropper
3) Click on the property you want to use as the source/target. The property under the
mouse will be used to drive the property you invoked Ctrl-D on.
For example, to drive the X, Y, and Z location of the Cube using the Y Location of the Lamp,
hover over any of the X/Y/Z location buttons, hit Ctrl-D, then click on the Y-Location
button of the Lamp object. Drivers will be added to the X, Y, and Z Location properties
of the Cube; each driver will have a single variable, which uses the Y-Location Transform
Channel of the Lamp.
Tips:
- Transform properties will automatically create "Transform Channel" driver variables.
Everything else will use "Single Property" ones
- Due to the way that Blender's UI Context works, you'll need two Properties Panel instances
open (and to have pinned one of the two to show the properties for the unselected
object). It's slightly clunky, but necessary for implementing a workflow like this,
as the UI cannot be manipulated while using eyedroppers to pick data.
- The eyedropper operator implemented here actually has three modes of operation.
1) The "1-N" (one to many) mode is the default used for Ctrl-D, and "Add Driver to All"
in the RMB Menu. This is the behaviour described above.
2) There's also a "1-1" (one to one) mode that is used for the "Add Single Driver" in the
RMB Menu.
3) Finally, there's the "N-N" mode (many to many), which isn't currently exposed.
The point of this is to allow mapping XYZ to XYZ elementwise (i.e. direct copying)
which is useful for things like locations, rotations, scaling, and colours.
Implementation Notes:
- The bulk of the driver adding logic is in editors/animation/drivers.c, where most of
the Driver UI operators and tools are defined
- The property eyedropper code is in interface_eyedropper.c along with all the other
eyedroppers (even though they don't share much actual code in common). However, this
turns out to be necessary, as we can't get access to many of the low-level buttons API's
otherwise.
Todo:
- It may be necessary to restore a way to access the old behaviour (i.e. "manual setup")
in case it is not practical to immediately pick a property.
- Other things to investigate here include extra hotkeys (e.g. Ctrl-Shift-D for Add Single?),
and to expose the N-N mode.
- Other things we could try include interactively applying scaling factors, picking
multiple targets (e.g. for location difference and rotation difference drivers),
and/or other ways of using these property picking methods.
Just using DKEY for this was resulting in too many drivers being accidentally created
by users drawing using Grease Pencil. This change also works better with the following
workflow changes to the driver setup process.
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
The new "default keyframe type" dropdown on the timeline header
(and also the "Keyframe Type" operator/properties in other places)
now has procedurally generated icons which reflect what that keyframe
type will look like when rendered in the Dope Sheet.
This was achieved using the ancient "VICON" (vector icon) stuff
that's lurking around in the dark parts of UI code. From memory,
the only other things that use (or used to use) this stuff included
some of the triangle icons for some dropdown buttons, or something
like that.
Notes:
* Theme colour changes are reflected immediately by these icons.
This is possible because they are all drawn procedurally
* These icons scale with the DPI setting. I manually guessed the size of
these icons. They can be adjusted further if needed.
* I've documented the steps for adding voodoo icons like this on the wiki
(http://wiki.blender.org/index.php/Dev:2.7/Source/Checklists/Vector_Icon)
* It's true that the rendering of these keyframes doesn't quite fit the rest
of the icons in the UI. However, since we're just leveraging the standard
keyframe drawing methods (to avoid discreptancies between the two), we'll
leave it as such for now. Maybe later we can consider blending in a bit of
the glossy keyframe icons in the Icon Sheet?
To make it easier for animators working in a multipass pose-to-pose workflow
when inserting breakdown keyframes and so forth, it is now possible to specify
the "type" of keyframe being created (i.e. the colour of the keyframe, when drawn
in the Dope Sheet).
Usage:
1) Choose the type of keyframe ("Keyframe", "Breakdown", "Extreme", etc.) from
the new dropdown located between the AutoKeying and KeyingSet widgets on the
timeline header.
2) Insert keyframes
3) Rejoyce that your newly created keyframes have now been coloured for you already
in the DopeSheet.
Todo:
* Look into a way of using the actual keyframe colours (from the theme) for the icons
of these types.
