Now this gives the line number of the scripts thats running, eg:
uiItemFullO: unknown operator 'some.operator'
/c/bin/2.56/scripts/startup/bl_ui/space_view3d_toolbar.py:73
Tried to resolve todo item "Layer change in 3d view header doesn't update
dependencies on changed previously visible objects". Code is too much spread
around now though, and the 3d view header shares RNA code for changing layers.
I'll let this be a "glitch" for now.
- look for icons in datafiles/icons (was looking in datafiles)
- was loading all images in datafiles/ on startup to check if they were the correct icon size, commented this since its unnecessary disk overhead on startup & images are checked for correctness when used anyway.
when running blender from the source dir would load splash.png every time.
also add missing NULL pointer check if the icon couldn't be loaded and ensure no buffer overflow check on icon path creation.
- Tooltip-hanging fix made the 'active' button be removed when mouse
enters another subwindow. Caused by commit of a week ago.
- Reverted the eventsystem change that sets 'active subwindow' before
it calls modal handlers. This made editors become active on using
menus, buttons, or other modal ops.
Side effect is that for transform operators called via toolbar, the
overlay-extra draw with helplines now gets skipped. Will check on
good ways for it.
Hanging Tooltips solved!
It appeared to be that an active button remained in that state when
another region/editor became active. It then kept the button-activate
state, and therefore also the optional tooltip.
This only happened on fast moves, when a mousemove event was not passed
on anymore to the previously active subwindow.
It has been solved with a new notifier (SWINACTIVE), which gets sent on
new active regions. The screen listener then calls uiFreeActiveButtons()
to find out if buttons were still active somewhere else.
-------------
Given the code perspective this is a hacky solution. However it's self-contained and documented one.
Ended having a talk with Ton and he agreed that this can acceptable in this case.
Zero chances of crashes (I've been using this myself for more than 6 months now).
Give it a shot. Although the code is +- for the user it's a really nice addition.
At the moment it makes more sense to put energy into the future Nodal Logic.
Yet, it's nice to give the current Logic Editor the love it deserves.
- Linking logic buttons had draw glitch, caused by reading
data from free'd buttons
- Doing an undo with mouse-over Curve Widget caused crash or
corruption.
Both related to code that tries to keep the "active" button in
memory. On each redraw of UI, buttons are re-created, which makes
it all tricky... hope we're safer now.
Also: added back undo pushes on adding links in logic editor.
Two bugs in one:
- Lukas commit monday for new group/socket handling accidentally removed
to set socketype in stacks, which as used by (texture) nodes to detect
whether value, color or vector had to be read.
Result was that all texture nodes were rendering as B&W
- Old 2.5 bug: preview renders for texture nodes didn't call a
NodeEndExec function, which gave crashes on deleting nodes.
The change in interface_hanlers.c is only a comment to explain
how keymaps are being found.
- WITH_OPENJPEG wasn't defined for creator.c with CMake.
- remove shadowed/redefined vars.
- remove some unused RNA report args.
- re-arrange IMB_FILE_TYPES so IRIS is not the first format tested, since its not very common test JPEG and PNG first.
* In windows the old button was tested to be equal to the new button (ui_but_equals_old()) even if their optype wasn't the same. Adding a check for optypes fixes all three reported issues.
* For some strange reason this didn't happen on other platforms.
popup appears, saving an extra click
I've separated out the "XXX"-'d event-adding-hack section from the
search-menu code into a separate API function (as recommended there).
This call is used to make sure that textboxes in popups can get
activated by default, to allow typing immediately.
Very nasty UI code issue: since every button is re-defined on a
redraw, having UI redraws while using a button was not possible.
This was solved long ago by copying over data from previous button.
However, this fails when buttons have callbacks with its own (or
a parent button) pointer.
This bug reporter found crashes in draw-overlap UI mode, this
draws entire UI over for every menu redraws, making previous button
pointers invalid. (for triple buffer, the UI is not redrawn, only
the menus).
In general: all systems falling back to old swapbuffers would have
suffered some instability because of this.
Fix is that now the old button gets lifted out from the previous
list and inserted in the new list. Works fine, but needs some tests!
Also in this commit: TIFF endian switching not needed for 16 bits tiff.
- fix mistake with grease pencil UI (&& was intended but & used).
- use (void) rather then () across _all_ blenders code.
- a few minor edits, don't shadow stack variables in roll calculation & avoid running memset() for VBO vertex map.
most local modifier,GPU,ImBuf and Interface functions are now static.
also fixed an error were the fluid modifier definition and the header didnt have the same number of args.
- modifier code was using sizeof() without knowing the sizeof the array when clearing the modifier type array.
- use BLI_snprintf rather then sprintf where the size of the string is known.
- particle drawing code kept a reference to stack float values (not a problem at the moment but would crash if accessed later).
Scene (Toolsettings, i.e. alongside "layered" option for using NLA
while doing auto-keying)
This option makes all Auto-Keying operations use the active Keying Set
to carry out keyframing operations instead of picking and choosing
their own Keying Sets to use, thus cutting down on the number of
unwanted keys.
Warning: if the older userpref option was enabled in an old
startup.blend, it may be difficult to turn this option off.
UI bug: when a button has an open menu, the menu closed on any
mouse-over of other buttons in this panel. That's not too bad,
but it didn't check for whether the mouse was already inside the
menu itself (respecting safety region).
The bug showed error on zoomed in UI, using FPS presets, in case
the menu-button was drawing aligned with other buttons. A real
boundary case... :)
