* Fix var declaration in bpy_interface.c
* Remove forward declarations from py_capi_utils.h: they are unnecessary and break compiles (there were probably many warnings about this during compile with GCC).
Reported and patched by Torsten Rupp
When a time marker is added in the timeline window via keyboard (keycode M) or existing markers are selected/moved via
the mouse the marker resp. the selection state is not draw immediately in the timeline window region.
The patch adds notifiers where necessary to ensure updates.
This troubles were caused by "break" of ND_OBJECT case in outliner area listener,
so not all cases were handled.
Handle more data and actions in outline listener, but not refresh when it's
actually unneeded (there where problems with it without that "break" -- extra
refreshing could be made).
Patch by Shane Ambler
Reported by Anthony Edlin
From the patch details:
"
In response to bug #23078 the operator panel disappears when dragged above the top of the 3dview without showing the
azone icon to restore it.
This patch properly hides the operator panel if dragged near the top of the 3dview so that the azone icon is in place
"
Thanks!
Patch by Alexander Kuznetsov
Reported by Chidozie Oku
From patch description:
"
Handler is now released on every exit from File Selector. For example pressing ctrl-up and then changing editor type
to another also releases the handler.
When an area is changed from SPACE_FILE, ED_fileselect_exit is called for clean up. It takes function of freeing folder
list and files (before it was done in cancel or exec functions) because they must be released on every exit anyway.
op!=null means cancel or exec was not executed so a handler was not released. ED_fileselect_exit then releases the handler
without changing screens.
"
Thanks!
* Velocity for particles that were born at exactly integer frames was calculated wrong when they were born.
Note: If you had a raytrace acceleration related bug, please clear the pointcache for all particles, toggle a particle setting to reset pointcache and rebake to create a valid simulation.
from Dan Eicher (dna)
Basically just wraps distfactor_to_bone() and passes the correct head/tail depending on which bone type it's called
from.
note:
renamed envelope() --> evaluate_envelope()
This runs after changing a property and allows correcting incompatible options.
Returning True will redraw the UI.
Currently this is used for setting the write extension when saving files, so changing the image format also corrects the extension.
The same is accessible from python where its used when saving SVG/EPS/PNG files.
This fixes: [#23828] obj export problems, [#23760] Exporting OBJ and filetype ending
also fixed document submission operator.
Now the filename in the file selector is the one used for writing this means we remove the "Save Over" popup which could be overlooked too easily.
Instead display the filename field with red tint, and a note in the tooltip.
Added ND_OB_SELECT notifier to separate operator. Selected objects
aren't actually changing, but there is no existing ND which could be used
for outliner update.
- BKE_add_image_extension now sets the extension rather then appending. (no more image.jpg.tga)
- py/rna functions which have no return value now raise an error if a non-None value is returned.
- added back the red-alert flag so buttons can have a red highlight if somethings wrong.
color, made sample a modal operator now to solve this. It's an indirect
solution, but couldn't think of anything better, and it's useful to have
anyway.
Crash was caused by missed offscreen OpenGL buffer. Added checking around this stuff.
Also fixed crash of simple "Image from view operator".
Note: This commit fixes only crashing, you'll be still unable to use this tools.
- rna buttons with units set now use the units base value for snapping.
- bone head/tail radius could be set negative.
matt: removed a check in ui_is_but_unit() which made angle buttons return false, what was this for?
from Lorenzo Tozzi (oni_niubbo) with minor edits.
--- from the tracker
The present situation is this: due to bug#22274, during editing, UTF chars are stripped from buttons with a unit associated
(length, angles, etc.).
Example: if the button displays '90°' and you click on it with LMB, the editing string will become '90'.
The problem arises if you use microns: '34µm' becomes '34' that blender interprets as 34 meters. So clicking on a button
and hitting enter won't confirm the previous value, but will change it (very badly also).
Of course nobody is using microns in blender, but the problem will arise when we will implement areas and option 'Separate
Units' will be enabled. The value '2m² 3cm²' will become '2m' during editing.
This patch solves the problem rewriting the string in a smarter way than just stripping the UTF chars: the unit is translated
from unit->name_short ('µm') to unit->name_alt ('um'). So clicking on '34µm' the editing string will become
'34um'.
--- end
note: rather then allowing empty strings in name_alt field I made it so if the unit system was the default one a NULL name_alt will just strip the string, since its the default its not needed.
- ignore MSVC warnings when FREE_WINDOWS is defined to quiet warnings.
- the CMake flags were not being set correctly making blender have weirdo colors (no -funsigned-char).
was missing a call to glLoadName(-1); so drawing commands after the bone were taken into account with the selection.
made some other minor changes that dont change functionality.
By Luca Bonavita (mindrones)
The patch renames and moves gl_round_box, gl_round_box_shade and gl_round_box_vertical_shade to UI_interface.h, so the extern usages are not needed anymore.
By Luca Bonavita (mindrones)
From detailed description: This patch doesnt change functionality, but uses the existing color math functions from math_color.c into
sequencer_draw.c.
- fix for minor inconsistency in armature selection, entering editmode and selecting a bone would move the manipulator because the selected bones, childs root wasnt selected on entering editmode.
- use copy_v3_v3 rather then VECCOPY in editarmature.c
The funny thing is: I only spotted this bug in March of this year. Almost one year after the original release. I think I don't parent objects to the camera often.
In terms of code I think that I can even think in a more elegant solution. I don't really need to rotate the camera, but simply to calculate its Modelview Matrix.
"""
m_rasterizer->SetViewMatrix(viewmat, cam->NodeGetWorldOrientation(), cam->NodeGetWorldPosition(), 1.0);
cam->SetModelviewMatrix(viewmat);
"""
The reason why I originally was rotating the camera was to make sure the frustum calculation was using the right camera frustum. For the frustum it takes the camera modelviewmatrix so the rotation really shouldn't be necessary. Leaving as it's for the time being.
* Note: the bug was never officially reported
