- Extrude Menu not longer restricted by selection mode, only selection totals (will show all possible options for the selection, regardless of selection mode)
- Missing operator descriptions
Ekey: Extrude Region
Based on selection totals:
Extrude region along normal if at least one face selected
Extrude vertex along normal if only one vertex selected (experimental)
Extrude edge on its plane if only one edge selected (experimental)
Extrude with no constraint axis otherwise
Shift-Ekey: Extrude Individual
Based on selection modes and selection totals
Individual Faces if face select and some faces are selected
Individual Edges if edge select and some edges are selected
Individual Vertice otherwise
Alt-Ekey: Extrude Menu (only shows valid options for selection mode and selection totals)
- Number of multicuts can now be set (only usable for multicut mode)
- Midpoint cutting is now done using shift-k + drag hotkey mapping
These were just minor properties changes, which shouldn't be too much of a hassle for BMesh merging.
Todo for Campbell:
- Make menu context sensitive
- Make menu automatically run the operator if there is only one option
Note: Saved configurations and keymaps with references to "Extrude and Move" operator needs to be updated to either call the menu or one of the new extrude macros.
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
Select Sharp Edges was conflicting with it, fixed by removing it's shortcut,
- if people use it frequently, they can easy add it back with a RMB click.
The operator was already there and written, just didn't have a hotkey
assigned. Gave it an icky popup menu like object mode parent until we
get a nice non-blocking report viewer.
* Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries.
* Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language.
This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
- ToolSettings had its id.data set to NULL when taken directly from the context (causing a crash in cases)
- menu for changing vert/edge/face selection now a python menu, removed operator.
- wm.context_set_value(), would really prefer not to have this since it evaluates the value as a python expression however there are no ways to define arrays in PyOperators
Takes into account the hierarchical structures of keymaps as well as wildcards (KM_ANY) in event definitions, user remaps (emulate numpad, action/select mouse buttons, ...) and event values that overlap (click, press and release)
For now, doesn't do anything other than print conflicts in the console.
As a result, I cleaned up a lot of keymaps that had double definitions, moved some keymap items in more appropriate places, fixed wrong definitions and removed kmi that were added for testing a long long time ago.
Out of all the remaining conflicts, after removing obvious non-issues, here's what remains: http://www.pasteall.org/9898
2. Add action parameter to Select_All_Toggle operators, rename to Select_All.
Options are Toggle (default), Select, Deselect, Invert (same as select swap). This makes it possible to map separate hotkeys for select all and deselect all.
NOTE for Aligorith: I didn't change animation operators for select_all which already had an Invert operator. These should be fixed eventually.
Leftmouse+Ctrl to extrude now mapped to Click instead of Release. Release was used to avoid conflict with lasso, but it isn't safe with modal operators that use Press to confirm (subsequent Release then extruded). Click is semantically closer to what we want here.
Now shares the same operators as the modifier buttons, works context-sensitive, and uses Python menu too.
* Cleanups/tweaks in 3D View vertex group menu
* Added Ctrl-G hotkey back for displaying a menu showing the available Vertex Group operators
* Added descriptions for a few Vertex Group operators. The difference between "normalize" and "clean" isn't that obvious from just reading the code, so perhaps some attention to this is needed.
This may result in cursor being grabbed twice (though we don't have any macro that can do this at the moment). If this is a problem, a check can be added.
Make macros work with more than one modal operator and mix of modal and invoke/exec
As a proof, brought back loopcut + edge slide in a single macro operator called Loopcut and Slide, replacing Loopcut as assigned to Ctrl-R.
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
- weight blending (Vertex specials menu), currently blends from surrounding unselected verts (nice for blending edge loops), but will eventually support face mask mode.
Removing old add tube operator and replacing it with add cylinder. The resulting operator is called add tube, since that's the name in the menu. Other people can debate about the name and change it later if they feel like it.
This operator was a port of the old ToSphere button that worked only around the cursor.
To Sphere transform (Alt-Shift-S) can already do it around cursor if pivot is set to that, can be used interactively and work on more data types, so this is unneeded.
Actions on press is used everywhere in Blender, lets not make an exception here because there's something missing in the event system.
Bug report and potential solution is here, if anyone wants to have a go at it: http://projects.blender.org/tracker/index.php?func=detail&aid=19510
Made the confirm keymap for transforms use KM_RELEASE instead of KM_ANY (I didn't see any case where this failed yet?), and restored the "ctrl-click" as it was before r23903
wm.context_set(path="scene.tool_settings.someattr", somevalue)
wm.context_toggle(path="scene.tool_settings.somebool")
wm.context_toggle_values(path="scene.tool_settings.some_enum", value_1="somevalue", value_2="othervalue") # switch between 2 values
wm.context_cycle_enum(path="scene.tool_settings.some_enum", reverse=False)
the path value is taken from the context so the full path is
context.scene.tool_settings...
This means in keymaps you can cycle draw modes, change PET- anything with rna access.
If its not so nice to map keys to operators like wm.context_set we could use macro's to wrap it and have its own name
Use this for PET and setting pivot options
- Made userpref key shortcut Ctrl+Alt+U since its not used in 2.4x
- added pivot_point_align (Alt+Comma)
- added PET wasnt rna wrapped correctly.
changed extrude, rip and duplicate to disable proportional editing however this gives a different problem now.
Commented in transform.c
// XXX If modal, save settings back in scene
this changes disables the option whenever the macro used used.
bpy.ops.mesh.primitive_torus_add(major_radius=1, minor_radius=0.25, major_segments=48, minor_segments=16)
- experemental dynamic menus, used for INFO_MT_file, INFO_MT_file_import, INFO_MT_file_export and INFO_MT_mesh_add. these can have items added from python.
eg.
- removed OBJECT_OT_mesh_add, use the python add menu instead.
- made mesh primitive ops - MESH_OT_primitive_plane_add, ...cube_add, etc. work in object mode.
- RNA scene.active_object wrapped
- bugfix [#19466] 2.5: Tweak menu only available for mesh objects added within Edit Mode
ED_object_exit_editmode was always doing an undo push, made this optional using the existing flag - EM_DO_UNDO, called everywhere except when adding primitives.
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
