Age | Commit message (Collapse) | Author |
|
previous commit (54102) actually reintroduces an old bug where Blender sigfaults when
the sensor and controllers are not from the active object.
The real fix for report #33746 is to clear the "object" property after the operator ran.
I'm not sure why when I call the operator from command line the property is cleared, but not
when I called it from C. Either way all should be working now.
|
|
(live from the global game jam Vancouver ;)
|
|
|
|
|
|
|
|
insensitive for int buttons.
|
|
|
|
Full log is here:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability#Matcap_in_3D_viewport
Implementation notes:
- Matcaps are an extension of Solid draw mode, and don't show in other drawmodes.
(It's mostly intended to aid modeling/sculpt)
- By design, Matcaps are a UI feature, and only stored locally for the UI itself, and
won't affect rendering or materials.
- Currently a set of 16 (GPL licensed) Matcaps have been compiled into Blender.
It doesn't take memory or cpu time, until you use it.
- Brush Icons and Matcaps use same code now, and only get generated/allocated on
actually using it (instead of on startup).
- The current set might get new or different images still, based on user feedback.
- Matcap images are 512x512 pixels, so each image takes 1 Mb memory. Unused matcaps get
freed immediately. The Matcap icon previews (128x128 pixels) stay in memory.
- Loading own matcap image files will be added later. That needs design and code work
to get it stable and memory-friendly.
- The GLSL code uses the ID PreviewImage for matcaps. I tested it using the existing
Material previews, which has its limits... especially for textured previews the
normal-mapped matcap won't look good.
|
|
|
|
|
|
ui_draw_aligned_panel
|
|
from Gavin Howard (gdh)
|
|
not entirely select the start of the text.
|
|
and no need to calloc memory for string selection.
|
|
Ancient issue: on much zoomed in UIs, text selecting or cursor placement
in Text-input buttons was off.
|
|
|
|
|
|
also - when expanding rna enums into existing menus - don't nest inside a row/column.
|
|
- cycles ui used 'cscene' for scene.cycles and scene.cycles_curves
- style cleanup
|
|
context arrow wasn't scaling with the DPI.
|
|
|
|
Y values/.
|
|
Ancient annoying thing for zooming in 2d views: when a view was restricted to keep
aspect ratio, it only allowed vertical or horizontal MMB-drag zooms, depending
portrait or landscape size of editors. Same for trackpad and magic mouse.
Now vertical zoom drag always works for editors like buttons, nodes.
|
|
Post 2.65a issue
Now scrollbars appear/disappear correctly, a bug in checking if mouse clicks
where on panel headers popped up. That disabled using scrollers next to a
panel header.
|
|
to float values.
|
|
Blender's data link button (typically with menu and searching options)
now has a X icon to clear its contents.
Before you had to click, delete text, enter.
For example:
- Object Parent
- Modifier objects or vertexgroups
This fix saves each user 100 clicks per day, with 100k users
that's 3 billion clicks per year!
|
|
registering/unregistering.
|
|
could leave the interface pointing to freed memory.
|
|
|
|
almost certainly a typo/accident.
|
|
|
|
This was difficult to do because we group theme colours and display them
together in user preferences. To make the background options more
presentable and keep them grouped and separate, I needed to group the
two gradient colours somehow. I added a separate ThemeSpaceGradient RNA
struct as opposed to ThemeSpaceGeneric. This struct is the same as
ThemeSpaceGeneric but it lacks the window background option (which does
nothing now) and includes the UiGradient struct which now has both
gradient colours. I modified the clear functions to use a new high
colour from the gradient. Now all options appear grouped and any other
editor that may use a gradient for the window background may do so.
Also corrected incorrect MAIN_VERSION_ATLEAST macro, it would not detect
versions correctly
|
|
|
|
- Old issue: on scrolling button views, tooltips could open or stayed open.
- New fix: alt+swipe now changes button values again
- Removed test print, from WIP code project.
|
|
preferences under themes->3D view->Theme Gradient Color. This is only used when use render only is not ticked and for now it may interfere with grid lines. Will investigate how to adjust contrast.
Tidying up of options after advisory session on irc: Move all RNA code
in Themes.
Changes after merging trunk's commit that renders sky
|
|
Trackpad zoom (swipe + CTRL) direction was inverted compared to MMB-drag
or scrollwheel usage. In the 3D viewport it was OK, in all others not.
Now the same physical gesture maps identical to zooming everywhere. Or to
recap (with blender factory settings)
Zooming in:
- MMB-drag, move mouse towards screen
- Scroll wheel, move finger towards screen
- Magic Mouse, move finger towards screen
- Trackpad 2-finger swipe: move fingers toward screen.
To make this extra confusing: this is only consistent if you set your system
to inperpret trackpad swipes as "inverted" (pan view left = swipe to right).
This is a typical default, although Apple wants you to call this "Unnatural" :)
Next commit will be testing on laptop if all pinch gestures zoom consistent.
And following to that, a sensible user preference to map trackpad use for
Blender yourself, to invert system defaults again. :)
Blame and thanks goes to Sebastian Koenig, for his perseverance on getting this
solved :)
|
|
- Trackpad swipes now behave same as scrollwheel for listview scrolls
(disabling 2d view scroll when mouse over)
- Added back 2.4 debug print for glGetError()
Only useful for developers - to check what goes on when ogl messes up.
- Made more clear print for read factory default. It's not error :)
|
|
|
|
also minor change to cylinder_project_exec() - delay getting the MTFace.
|
|
|
|
When trackpad swipes don't convert to ScrollWheel steps anymore, several hardcoded
wheel events need to support swipe too.
This adds swipe support to:
- Menu item scroll
- Search item scroll
- ALT + number/slider/swatch values
The amount of old style scroll "clicks" is calculated based on how trackad is
being mapped to move a mouse pointer. Move it one widget unit = 1 click.
The swatch option applies trackpad swipe motion in analog way.
|
|
checker script detects this now so easy to detect this if new code is added that doesnt follow blenders style.
|
|
|
|
from Patrick Boelens (senshi). with modifications to split it into its own function.
also added C style multi-line comment support /* ... */
I've left out the part of this patch that sets the language in the space, since I think this might be better stored in the text block.
For now it simply uses OSL syntax highlighting when the extension is '.osl'.
|
|
|
|
- UV Image editor and other 2d views didn't zoom for CTRL+swipe yet.
(2 finger trackpad, 1 finger mighty mouse)
- Switched defaults for 3D window swiping...
- default rotate view
- SHIFT for translate
- CTRL for zooms
This makes all editors use 'swipe' like 'middle mouse', and not
like scrollwheel (as in releases).
This is nice for consistancy, but it still feels a bit weird...
Of course users can config this in keymaps. We need a sensible
default though, and to make a 2D input input device behave like
middle mouse seeems more sensible than like a 1D wheel...
Proposal therefore for defaults:
- 1D scrollwheels: zoom in 3d, zoom in 2d, but scroll for list views.
- 2D trackpads: pan for all 2d views, rotate for 3D
I'll check with frequent trackpad users about this and we can freeze it
before release. Give it a try :)
|
|
between two logic bricks doesn't match the mouse cursor location. The issue was the last line segment for the bezier curve was not getting drawn. This is why the error increased as the curve got longer.
|
|
|
|
be fixed in the icons code!
|
|
|