| Age | Commit message (Collapse) | Author |
|---|
|
or modal keymaps from operator id)
|
|
This means added operators in the keymap editor will now show options correctly (maybe not for old .B25.blend)
|
|
takes a registered menu. the key will then trigger this menu.
|
|
- Didn't support new userdef keymaps (new "active" rna function to get the active version of a keymap)
- Didn't support modal keymaps (new "modal" param to add_keymap function, new "add_modal_item" function on keymaps (both functions now make sure the keymap is of the right type))
|
|
Fixing/Missing RNA properties:
- "virtual" property for "ANY" modifier for keymapitem
- modal property for keymap
- Look up modal_items in usermaps too
Lazy init usermaps needs to init modal_items too.
New function to initialize a user keymap (fill in modal_item and poll pointers).
Operator modal keymaps now look up if there's a user defined keymap that overwrites it.
Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them).
Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
|
|
* Restored the Grease Pencil tools to the toolbar
Probably, if the reason they were commented out before was so that the repeat stuff is visible, we can swap the order of those two. Otherwise, it's good to have somewhere for the operators now (so that the hotkeys can be found)
* Hotkey displays in the tooltips now show the keymodifier too
For example, "D LeftMouse" or "Ctrl D LeftMouse" for the Grease Pencil operators, instead of just "LeftMouse" or "Ctrl LeftMouse".
|
|
|
|
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.
|
|
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.
|
|
their handlers based on notifiers, which is simpler and more
reliable.
This fixes for example editmode or uv edit keymaps not working
when creating a new 3dview or image space.
|
|
* layout.itemR now has icon_only option to show only icon
in e.g. enums buttons, for uv editor header.
* Automatic key shortcuts in menus now show the shortcut even if
operator properties don't match. Not sure this will work well
everywhere, but seems to be working ok for now.
* Open recent now show shorter filenames instead of the whole
file path.
* Tweak object Duplicate menu item.
|
|
Keymap feature: RightMouse in pulldown menus allows to assign
a new hotkey.
|
|
First step towards keymap editor!
Before getting too excited:
- doesn't save yet
- no rna properties can be defined
- no insert/remove keymap options yet
- no option yet to set 'key press/release'
But what does work;
- Keymap list is in outliner, new category
(Keymaps are listed in order as being created now)
- enable/disable a keymap entry: click on dot icon
- it displays python api names for ops
- browse new operator for keymap (menu button)
- set keymap to use other keys, mouse or tweak events
- four modifier key options
I first intent to test it all well, there are still
quite some modal map conflicts (like border select) and
there's problems assigning items to tweaks
Another issue is that a visual editor for keymaps might be
quite hard to use... the amount of data and options is just not
so fun for a buttons menu. There are ways to improve this though.
Maybe do this via a script?
|
|
Modal keymaps.
I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support.
The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way.
This system also allows to still handle hardcoded own events.
Tech doc:
1) define keymap
- Create map with unique name, WM_modalkeymap_add()
- Give map property definitions (EnumPropertyItem *)
This only for UI, so user can get information on available options
2) items
- WM_modalkeymap_add_item(): give it an enum value for events
3) activate
- In keymap definition code, assign the modal keymap to operatortype
WM_modalkeymap_assign()
4) event manager
- The event handler will check for modal keymap, if so:
- If the modal map has a match:
- Sets event->type to EVT_MODAL_MAP
- Sets event->val to the enum value
5) modal handler
- If event type is EVT_MODAL_MAP:
- Check event->val, handle it
- Other events can just be handled still
Two examples added in the code:
editors/transform/transform.c: transform_modal_keymap()
editors/screen/screen_ops.c: keymap_modal_set()
Also: to support 'key release' the define KM_RELEASE now is officially
used in event manager, this is not '0', so don't check key events with
the old convention if(event->val) but use if(event->val==KM_PRESS)
|
|
define extra functions on gameObjects.
Adding a UI to set the type on startup can be added easily.
# ----
class myPlayer(GameTypes.KX_GameObject):
def die(self):
# ... do stuff ...
self.endObject()
# make an instance
player = myPlayer(gameOb) # gameOb is made invalid now.
player.die()
# ----
One limitation (which could also be an advantage), is making the subclass instance will return that subclass everywhere, you cant have 2 different subclasses of the same BGE data at once.
|
|
* 2 new enums event_value_items and event_type_items in RNA_enum_types.h
* WM_key_event_string now uses an RNA enum lookup rather then its own switch statement.
* moved wmEvent from WM_types.h into DNA_windowmanager_types.h
* added RNA_enum_identifier and RNA_enum_name to get strings from an enum value.
|
|
Sanitized the 'tweak' event.
Original idea was to have WM event system generating it
automatically. However, I first tested it via a handler
and operator, to check what kind of configurations would
be useful. It appeared to not work nice, also because
that inserting a tweak operator in a keymap is confusing.
Now 'tweaks' are generated automatically, and can be
catched by keymaps as any event. The current definition
of tweak is:
- if Left/Middle/Rightmouse pressed
if event wasn't handled by window queue (modal handlers)
start checking mousepositions
- while mousepositions are checked
- escape on any event other than mouse
- on mouse events:
- add tweak event if mousemove > 10 pixels
- stop checking for tweak if mousebutton released
- Tweak events have a define indicating mousebutton used
EVT_TWEAK_L, EVT_TWEAK_M, EVT_TWEAK_R
- In keymap definitions you can use _S or _A to map to
action or select mouse userdef.
- Event value in keymap should be KM_ANY for all tweaks,
or use one of the eight directions:
EVT_GESTURE_E, _SE, _S, _SW, _W, _NW, _N, _NE
- And of course you can add modifier checks in keymaps for it.
- Because tweaks are a result of mouse events, the handlers get
both to evaluate. That means that RMB-select + tweak will work
correctly.
In case you don't want both to be handled, for example the
CTRL+LMB 'extrude' and CTRL+LMB-tweak 'lasso select', you will
need to set the first acting on a EVT_RELEASE, this event only
gets passed on when tweak fails.
The current system allows all options, configurable, we had in 2.48,
and many more! A diagram of what's possible is on the todo. :)
Also in this commit: lasso select editmesh failed with 'zbuffer
occluded select'. Also circle-select failed.
|
|
Big commit, but mainly adminstration.
- Enabled ot->flag OPTYPE_UNDO to work.
- Removed all redundant ED_undo_pushes, but I'd
recommend everyone to check it while testing. :)
- Added view manipulations as OPTYPE_REGISTER,
although this will flood the redo stack a bit...
Nevertheless; for a "redo last action" panel we
can simply check if both flags are set for redo.
- Bugfix in editmode undo: selectmode was cleared,
so you couldn't select after undo
- Bugfix in mixing tweaks and keymaps... solution
works but is weak, need to think over a while.
|
|
Edit mesh:
- fixed compile, shul only committed the function declaration, not
the code for 'make fgon'.
- Put the Fgon option under:
ALT+F: make fgon
SHIFT+ALT+F: clear fgon
(note, SHIFT+F = fill :)
- Fixed loop select to use two booleans, as Martin pointed me
correctly at! Using 1 variable was lazy coding.
|
|
- Edit mesh: Add ctrl+click add vertex or extrude.
I've made it not move the 3d cursor in that case.
Also found out tweak events conflicted with existing
keymap definitions; on tweak failure (= no mousemove)
it now passes on the mouse event as 'mouse down' for
the remaining keymaps to check.
These then actually respond to mouse-up instead of down...
The location in the keymaps where tweaks get generated
remains important. Examples:
1 - 'select' mouse-handler, operator return pass-through
2 - tweak handler checks, and makes tweak event
3 - grabber responds to tweak event
1 - ctrl+mouse tweak handler checks, makes tweak event,
or passes event on
2 - if tweak event, it runs lasso
3 - else when passed on, ctrl+click extrude happens
In the first case, select works on mouse-down, immediate.
In the second case, extrude happens on mouse-release, even
though the keymap defined mouse-press.
This will make designing nice balanced keymaps still not
simple; especially because you can't tell operators to
pass on the key... although we can add the convention that
select-mouse operators always pass on to enable tweaks.
Still a good reason to wait with custom keymaps
when this is fully settled!
|
|
* Automatic shortcut keys in menus now compare operator properties as well.
Implemented IDP_EqualsProperties for this.
* I imagine all these compares may be a bit slow, for this case it's not
so bad though because it only happens for one menu when it is opened.
|
|
* View2D to region now returns ints instead of shorts.
* Use "Numpad" instead of "Pad" in automatic keymap menu info.
* Menus can now use buttons other than BUTM and SEPR, in
particular TOG and ROW are now supported instead of flipping
bits manually.
* Added a simpler uiDefMenu* api for making menus now, and it
only supports Operator and RNA buttons at the moment, will be
used in next commit. Not sure how this will evolve .. makes
menu code look cleaner anyways.
* Ensure that interface code doesn't crash when getting unknown
Operators and RNA properties, and display their buttons grayed
out in that case.
|
|
* Object has some more properties wrapped, mostly game related.
* Scene frame changes now send a notifier.
* Added functions to create/free operator properties for calling
operators. This also simplifies some duplicated code that did
this. Ideally though this kind of thing should use the properties
pointer provided by buttons and keymap items. Example code:
PointerRNA ptr;
WM_operator_properties_create(&ptr, "SOME_OT_name");
RNA_int_set(&ptr, "value", 42);
WM_operator_name_call(C, "SOME_OT_name", WM_OP_EXEC_DEFAULT, &ptr);
WM_operator_properties_free(&ptr);
|
|
Operator calls: extended WM_operator_name_call() with options whether to
call the exec() (operate immediate) or invoke() (check user input) entry.
This will allow python to use it more efficiently, but also solves the
dreaded pulldown case that showed another menu for confirmation.
New names to learn: :)
WM_OP_EXEC_DEFAULT
WM_OP_INVOKE_DEFAULT
on todo still: allow hotkey definitions to do same.
|
|
Fix: popup menus were not freeing operators.
Made a new Popup menu call for this case:
uiPupmenuOperator(C, maxrow, op, propname, menustr);
It will set enum "propname" to the menu item and call operator,
register it optionally and free it. Use it in "invoke" calls.
Next: automatic menu generating for enum properties!
|
|
Better implementation of own window timers, not using ghost.
That makes blender's WM nice in control, and gives callers
of timers the opportunitie to evaluate time passed since
previous step. This system also only generates one timer
event per main loop (events - handlers - notifiers - draw)
Small fix: allow keymap modifier to give KM_ANY to ignore
modifier keys, this to have TIMER keymap work.
|
|
Context API
This adds the context API as described here. The main practical change
now is that C is not longer directly accessible but has to be accessed
through accessor functions. This basically adds the implementation of
the API and adaption of existing code with some minor changes. The next
task of course is to actually use this design to cleanup of bad level
calls and global access, in blenkernel, blenloader.
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Context
Error, Warning and Debug Info Reporting
This adds the error reporting API as described here. It should help
clean up error() calls in non-ui code, but eventually can become used
for gathering messages for a console window, and throwing exceptions
in python scripts when an error happens executing something.
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Reports
|
|
* Added support for defining properties for operator buttons, with
uiButGetOperatorPtrRNA. Needed to cleanup a hack that was there
for operator properties in RNA, now a separate OperatorProperties
type is used for storing operator properties, instead of being part
of the Operator type itself.
* Allow selecting menu items with mouse release instead of press again.
* Fix some cases with hanging tooltips in the UI.
|
|
* Only open tooltip when the mouse is still over the button.
* Remove an unnecessary redraw call, though the two mentioned
in the previous commit seem to be working OK (it's for action
buttons when you move the mouse away from the button, holding
the mouse button down).
* Fix missing alt key in key event strings.
|
|
which context to run the operator: WM_OP_DEFAULT, WM_OP_REGION_WIN,
WM_OP_AREA or WM_OP_SCREEN. This also replaces WM_operator_call_rwin
since it is more general.
This is useful for buttons and popup menus to run operators, and also
used by a new function to lookup the keymap item for that operator in
the right context.
|
|
make the key event button work again.
|
|
which will then be set when the operator is called, example:
kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0);
RNA_enum_set(kmi->ptr, "dir", 'h');
kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0);
RNA_enum_set(kmi->ptr, "dir", 'v');
There is a hack I had to do here, since properties are defined
as member of wmOperator, will try to fix later, committing now
so it can be used already.
|
|
funtion WM_keymap_add_item() now returns keymap-item, so you can use it
to set default properties for operators with WM_keymap_property_set().
Brecht will fill in this function, requires rna magic!
Example: an operator ED_OB_OT_add_primitive can be configured with
keymap like this:
WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere");
Similar conventions we can use later for button/menu calls.
This will make creating operators easier, allowing a developer to group
tools functionality nicely.
|
|
Part one of wrapping up area/region management.
Read design doc here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager
This commit:
- brings keymap storage to WM, based on names/types. This structure
allows rna-ifying it too, so you can browse keymaps etc.
- creating areas and regions works slightly different now, wich
regiontypes stored in areatype.
Todo:
- better callbacks and structure for defining which handlers need to
be added.
- using region types to validate regions
- proper implementation of local region data
- code method for customizing keymaps. Current idea is that you have
to indicate an entire keymap to be custom, to prevent too complicated
merging problems of default and custom maps (like order, multiple keys
for same operator, disabling options, etc).
|
|
- Added standard "tweak" gesture operator, which can be set per region, to
generate EVT_TWEAK events. You can configure tweaks for any mouse button
and have handlers for such events check for modifiers etc.
It even stores tweak direction (8 directions). Might be fun to experiment
with tweak gestures N, S, etc. :)
In general it can be used to replace the current tweak code in 2.48
(std_rmouse_transform).
Test added: on screen level it now adds LMB tweaks, if tweak-South it splits
the area. Will be removed of course.
- Added to Border operator a property to store event used to end border with.
- Moved the "AZone" triangle drawing to the right context (area). It was on
screen level, not respecting area-redraws. Also cleaned up drawing for it,
and moved the "swap buffers indicator" square to look nicer. Those squares
are only for test!
- event-match function had bad code for checking for event-value. Made a
"KM_ANY" define so keymaps can be defined ignoring event values.
- Gesture todo: lasso, "real gesture" (like blender now has)
|
|
- on mouse-over edge, you can drag area borders around.
- note it's a handerized system now, so it updates UI while you
move mouse.
Feedback needed:
- read bottom part of the screen_edit.c file. It's the proposed
method for adding tools and handlers. I think it's close, but
might need some tweaks.
|
|
adding new windowmanager module, and the first bits of new editors
module.
|
