* 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.
Fixed one of oldest annoyances in Blender: the text input button!
It always behaved stupid when you had clipped text in a button.
Now while using arrows the cursor will move as expected, and only
internally shift contents when cursor reaches edge of button.
Report was that move-to-layer menu failed. The real cause was
more complex; had to dive deep in the dungeons of the interface
code that handled undos and operators. Found several issues:
- popup menus (like redo operator, color picker) executed again
on a mouse-exit
- far too many buttons were sending undo pushes; even worse, in
the operator redo-panel each button action was pushed twice
- in case operator redo-buttons have own callbacks (like layer
buttons) the redo wasn't working
- layerbutton menu was called without creating a proper undo/redo
case
Things should all work smoother now!
On todo:
- better definition and handling of all versions for operator menus
(four types now, not fun)
also: make operator "do" menu, which on first action does operator
and then switches to redo-ing
- bring back Undo menu, to list the undo stack and jump in it.
Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items.
keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used.
- active key is shown underlined.
- only ascii keys are assigned currently.
- can run operators, open menu items.
- currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
[#25159] Vertex locations dont read correctly and are not labeled correctly in the properties bar.
- non rna buttons can now have units set.
- calls with invalid units system now raises an assert().
- include .mxf in filter.
Also use const char in many other parts of blenders code.
Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
Bringing back missing feature: Create new directory by typing a not existing name into the directory button.
Note: Small issue still with autocomplete -> if typing the new directory directly after autocomplete, it doesn't execute the operator yet.
Also fixed some minor compile/cleanup issues with warning about signed/unsigned comparison and missing header.
WM_operator_poll() could fail in cases WM_operator_name_call() would succeed because calling the operator would setup the context before calling poll.
this would result in python raising an invalid error or menu items being greyed out.
now python can also check with an operator context:
bpy.ops.object.editmode_toggle.poll('INVOKE_SCREEN')
- made interface, windowmanager, readfile build without unused warnings.
- re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
- moved files in proper directories and adapted paths where needed
- deleted doc/oldbugs.txt (asked confirmation to jesterking a week ago in irc)
- still working on doxygen files, for now I'll leave them in doc/
- NOTE: while checking if other files were referring to these files, I noted that
"GPL-license.txt" is also used in the files below:
- release/windows/installer/00.sconsblender.nsi
- release/windows/specific.sh
but these files should't be affected by this commit, but please check :)
- 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.
- pick the closest unit that matches the existing step size.
- set the distance subtype on some camera flags.
- commented mesh flag 'ME_ISDONE' its nolonger used.
- Also made it so sys.stdin isnt overwritten anymore, instead the interactive consoel overwrites while it executes and restores after.
- removed hope folder from sphinx patch path
Now, rather than the bit-too-alarming stop sign, threaded wmJobs
display a progress indicator in the header. This is an optional feature
for each job type and still uses the same hardcoded ui template
(could use further work here...).
Currently implemented for:
Render - parts completed, then nodes comped
Compositor - nodes comped
Fluid Sim - frames simulated
Texture Bake - faces baked
Example: http://mke3.net/blender/devel/2.5/progress.mov
[#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders
Blenfont was not thread safe, that is why one thread can change
the font properties (size, dpi, color, etc) at the same time
that the stamp draw on the image, and then the problem.
To make blenfont thread safe I have to change two important things:
1) Every BLF_* function take one argument, the font id.
2) We have two new function to make font "thread safe":
BLF_load_unique
BLF_load_mem_unique
This two function are for case like stamp, that need and own font
that don't share the glyph cache, so can draw without problem
in a different thread.
Why the BLF_*_unique function ?
Because blenfont keep only one copy of a font and keep a list of
"glyph cache". Every glyph cache have size and dpi, so if two
different thread access the same font at the same time, they can
change value and finish with something like the stamp problem.
Why don't remove the glyph cache ?
Because if we do that, we finish with a font object for every size
and dpi, and the stamp is really a special case that happen in
the rendering process, so I really thing is better keep the
glyph cache and make this two new function to handle this
special case.
(When I say "font object" I mean have the same freetype font multiple
times just to have differents size and dpi)
As Matt point we still can have one case that two thread access
the BLF_*_unique function at the same time, but I am looking to
fix this with some class of thread lock.
For now I test and work fine, so if some one found problem, please
let me know.
Campbell I have to change the python api (python/generic/blf_api.c)
to the new syntax, so maybe you can take a look at this.
