The UserPrefs Default was never getting initialised correctly, so new scenes would not get the default AutoKeying mode set correctly ("add but off"). I remembered fixing some problems like this before, but it seems that fix only fixed old files vs the user-prefs for new scenes.
- re-arranged UI in a way that gave far too much vert scrolling.
- was added all over for simple things like making text="", layout engine should handle this.
- Ton and Brecht are ok with removing this now. Ton would like to work on the layout engine to make it better support these cases.
* Fix: unify strength and size did work consistently with other paint modes
* Fix: If [ and ] keys were used to resize a brush it was not possible to increase the size of the brush if it went under 10 pixels
* Fix: Made interpretation of brush size consistent across all modes, Texture/Image paint interpreted brush size as the diameter while all the other modes interpret it as radius
* Fix: The default spacing for vertex paint brushes was 3%, should be 10%
* Fix: due to fixes to unified strength, re-enabled 'Unify Size' by default
* Fix: Unified size and strength were stored in UserPrefs, moved this to ToolSettings
* Fix: The setting of pressure sensitivity was not unified when strength or size were unified. Now the appropriate pressure sensitivity setting is also unified across all brushes when corresponding unification option is selected
* Fix: When using [ and ] to resize the brush it didn't immediately redraw
* Fix: fkey resizing/"re-strength-ing" was not working consistently accross all paint modes due to only sculpt mode having full support for unified size and strength, now it works properly.
* Fix: other paint modes did expose the ability to have a custom brush colors, so I added the small bit of code to allow it. Note: I made all of the other paint mode brushes white. Note2: Actually, probably want to make the paint modes use the selected color for painting instead of a constant brush color.
* I had removed OPTYPE_REGISTER from some Sculpt/Paint operators but in this commit I add them back. I'm not completely sure what this option does so I don't want to disturb it for now.
Note: I think this will enable paint/sculpt in all files, even when user has turned it off, unless subversionfile is bumped to 6 and the comparison is changed to subversionfile < 6.
I'll leave that to somebody else who knows better when to change the subversionfile.
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
*The narrowui value was hard coded in all ui scripts, made an user preferences option. Basically this value determines on which area width, it should switch between dual/single column layout.
ToDo: The Changes only take effect when reloading scripts/restarting Blender (after saving as default). Will maybe add the "Reload Scripts" operator next to the button in the future.
* Small fix for Fluid Add Button, when in single column mode. Didn't expand like the other "Add" Buttons.
Curve->lastselbp field was renamed to Curve->lastsel and now not last
either BPoint or BezTriple is storing here. It's not easy to determine
type of selected point, but operator which depends on such point reviews
the full nurbs, so this shouldn't be a problem.
Made changes to curve undo stuff to restore last selected point on undo/redo.
Added new theme color for curve last selected point.
This commit fixes reports #21638 and #21818, which were both also Durian feature requests.
Cbanges:
* Added new default setting for the type of handles created when creating keyframes. This can be found in the user-preferences, and is used whenever existing keyframes aren't being overwritten (instead of the value being always taken from the keyframes either side, #21638).
* When keyframing over existing keyframes, only the values will be changed. The handles will be offset by the same amount that the value of the keyframe changed, though how well this works in practice still needs to be tested more thoroughly (#21818, already fixed earlier, but this commit is the full fix).
* When 'free' handles are added by default, they are offset to be +/- 1 frame on either side of the keyframe so that it is obvious that they can be moved. However, they just take the same value of the keyframe since this is easiest.
* Properly initialising handle colour defaults for 3D-View and Graph Editor. Graph Editor's theme userprefs also show these settings now, though the layout is really quick hack-style.
Emulate 3 button mouse is now disabled when Left mouse select is used, to
prevent keymap conflicts. Configs for single button macs etc we can do with
keymap presets.
Theme colours were getting overwritten on startup with defaults (as in 2.4
system). Changed this to allow changing the default theme, and added a
'Reset to defaults' operator in user prefs. Perhaps next step to look into the
py presets system for themes too (nice and easy to share).
If you're using a custom B.blend you may get some strange theme colours on
startup if they weren't saved properly before. 'Reset to default' button in theme
preferences should fix it back to defaults.
Only source/blender/editors/ dir, should not give errors on different platforms
Only removing: UI_*.h, ED_*.h, WM_*.h, DNA_*.h, IMB_*.h, RNA_*.h, PIL_*.h
- Replaced hardcoded nurbcol array with theme colors
- Send notification in duplicate curve operator (this operator could
reset/change active nurb)
- Edge seam color added to the user preferences dialog
set the draw method to triple buffer or overlap depending on the
configuration. Ideally I could get all cases working well with triple
buffer but it's hard in practice. At the moment there are two cases
that use overlap instead:
* opensource ATI drives on linux
* windows software renderer
Also added a utility function to check GPU device/os/driver.
This commit introduces a few cleanups and tweaks to the way that timecodes (i.e. the timing indications used instead of frame numbers) get displayed.
1. Custom Spacing of TimeCodes/Gridlines
Made the minimum number of pixels between gridlines/timecode indications a user-preference, instead of being a hardcoded constant. This allows to set the spacing tighter/looser than the defaults, and is also used for the other changes.
2. Default timecode display style, (now named 'minimal') uses '+' as the delimeter for the sub-second frames. This hopefully makes it a bit clearer what those values represent, as opposed to the '!', which can sometimes look too much like a colon.
3. Added various timecode display styles as user-preference. - These include always displaying full SMPTE, to showing milliseconds instead of frams for sub-second times, and also an option to just show the times as seconds only.
- When changing the timecode style, the spacing setting is automatically modified so that the timecodes are spaced far apart enough so that they won't clash (under most circumstances). This automatic modification is only done if the spacing is too tight for the style being set.
4. Unified the code for generating timecode strings between the View2D scrollbar drawing and the current frame indicator drawing.
This patch by Guillaume Lecocq (lguillaume) adds user preference settings for setting the playback frame-rate and delay between captured frames for the screencasting feature.
--
I've made a few tweaks for a few minor issues
- Made DNA vars for these settings shorts instead of ints, reducing the number of unnecessary extra pad vars
- Added version patching to ensure that these settings are initialised by default
- Made tooltips for the settings more descriptive
* Added a generic 'histogram' ui control, currently available in new image editor
'scopes' region (shortcut P). Shows the histogram of the currently viewed image.
It's a baby step in unifying the functionality and code from the sequence editor,
so eventually we can migrate the sequence preview to the image editor too,
like compositor.
Still a couple of rough edges to tweak, regarding when it updates. Also would
be very nice to have this region as a partially transparent overlapping region...
* Added Theme support for the console.
You can change:
-Header Color
-Text Color of Output, Input, Info and Error Messages. (Inside the User Preferences -> Themes)
A solid color backdrop is now drawn behind the mute/protect toggles and sliders, reducing the visual clutter with long names still appearing behind the UI widgets.
* Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries.
* Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language.
This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
Also put a bit more logic for guessing player paths based on my system.
If anyone can make this a bit more clever/bulletproof, please feel free to
get involved in it, it's all python!
Changed the rounding of action buttons. The round style looked pleasing when they were isolated, viewed by themselves, but looked terrible when grouped, or at small sizes with icons as it was often used. The old Filebrowse or Render This Window buttons were examples of how badly they looked with an icon, and the rounding in the tools area made for some weird visual shapes. When combined in groups of widgets, such as the datablock selectors it looked even weirder, because one side of the group would be square and the other would be round, causing some spatial clashes.
http://www.reynish.com/files/blender25/actionbuttons_new.png
Also tweaked the tools sub-area color which stood out as being much brighter than the rest of the UI. When the tools area was open in the default layout, the overall impression was asymmetrical, non-harmonic.
* Added basic infrastructure to layout user preferences. The
intention is that you open a user preferences space in place
of the buttons space, and have panels there.
* The existing sections don't have to be followed, it's easy
to create different ones, just change the user_pref_sections
enum in RNA.
* This will get separated from the info header later.
Logic editing back!
Test screenie:
http://download.blender.org/institute/rt9.jpg
I gave the buttons a bit more width, added nicer linkline draw.
Not working yet:
- theme colors for sensor/actuator types (was old button colors)
- moving sensors up/down (used bad pupmenu... better is icons like
used for modifiers)
- Linkline mouse-over select. Currently deleting a link goes by
drawing the same line again.
Needs to be fully tested for functionality too, leave that to the GE
department. :)
I noted there's bad button hacking with reading button values,
like check_state_mask(). uiBut structure was not meant to be exported
outside of interface module.
Added SpaceLogic, to restore the old logic buttons into.
In future it can be used for a more advanced logic editor, with
states, behaviour, whatever. We'll see!
This commit only adds the backend for new space. Committed this
now as reference for when we need another space type. It's still
not well plugin-able (dynamic space types), but my idea is to just
have a new SpacePlugIn for this, with a neat small API to define
all relevant callbacks.
Also note the icon for the spacetype is wrong still.