The goal here is to make app templates usable for default templates
that we can ship with Blender. These only have a custom startup.blend
currently and so are quite limited compared to app templates that fully
customize Blender.
But still it seems like the same kind of concept where we should be
sharing the code and UI. It is useful to be able to save a startup.blend
per template, and I can imagine some scripting being useful in the future
as well.
Changes made:
* File > New and Ctrl+N now list the templates, replacing a separate
Application Templates menu that was not as easy to discover.
* File menu now shows name of active template above Save Startup File
and Load Factory Settings to indicate these are saved/loaded per
template.
* The "Default" template was renamed to "General".
* Workspaces can now be added from any of the template startup.blend
files when clicking the (+) button in the topbar.
* User preferences are now fully shared between app templates, unless
the template includes a custom userpref.blend. I think this will be
useful in general, not all app templates need their own keymaps for
example.
* Previously Save User Preferences would save the current app template
and then Blender would start using that template by default. I've
disabled this, to me it seems it was unintentional, or at least not
clear at all that saving user preferences also makes the current
Differential Revision: https://developer.blender.org/D3690
There were two issues here, introduced by rB66aa4af836:
* Forgot to change length of some filter_glob var deep in filebrowser code.
* Truncating filter_glob in general can be dangerous, generating
unexpected patterns.
Last point was the root of the issue here, truncating to 63 chars string
left last group as 'match everything' `*` pattern.
To fix that to some extent, added a new BLI_path_extension_glob_validate
helper to BLI_path_util, which ensures we do not have last
wildcards-only group in our pattern, when there are more than one group.
atoi usage in BLI_stringdec could overflow, use strtoll instead and
check
valid range with INT_MIN and INT_MAX
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D3452
The Issue
=======
For a long time now MinGW has been unsupported and unmaintained and at this point,
it looks like something that we should just leave behind and move on.
Why Remove
==========
One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based.
However, now that this is no longer true we have basically stopped updating the need CMake files.
Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see:
https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch
If we wanted to keep MinGW then we would need to make more custom patches to the external libs and
this is not something our platform maintainers are willing to do.
For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
Fixes T51301
Differential Revision: https://developer.blender.org/D2648
Utility to get a file/dir in the path by index,
supporting negative indices to start from the end of the path.
Without this it wasn't straightforward to get
the a files parent directory name from a filepath.
Things like `BLI_uniquename` had nothing, but really nothing to do in
BLI_path_util files!
Also, got rid of length limitation in `BLI_uniquename_cb`, we can use
alloca here to avoid overhead of malloc while keeping free size (within
reasonable limits of course).
Same case as with space char really, one should not use those special chars in
filenames, but they are globally supported by all current FS/OS, so no real reason
to enforce that behvior on users here.
To be backported to 'a' release.
Filenames over 128 chars would crash.
Move BLI_newname into file_ops,
this was only used in one place and isn't all that re-usable.
Also remove special behavior for 4 digits.
- BLI_current_working_dir's return value must be checked, since it may fail.
- BLI_current_working_dir now behaves like getcwd, where a too-small target will return failure.
- avoid buffer overrun with BLI_path_cwd, by taking a maxlen arg.
BLI_filename_make_safe had several issues:
* Would replace all dots ('.'), not a great idea since it would break extensions.
* Was not checking for 'control' ASCII chars (though unlikely, better to be safe here).
* Win32 only: was not checking for forbidden names (con, aux, ltp0, com0, etc.).
New BLI_path_make_safe() simply checks each path's item with BLI_filename_make_safe().
Added a new BLI_path_utils func, `BLI_filename_make_safe()`, which for now simply
replaces unsafe chars for paths (like '\' or '/') by an underscore...
