[Gui] Fix string encoding for document, object and subobject names in PropertyLink, SelectionSearch, PD Sketch Based Tasks, Part Primitives and Document handling.
For some platforms due to event loop and timer triggering being not
deterministic stylesheets could be loaded before style parameters were
fully loaded. This caused warnings about style parameters to appear
potentially confusing users.
This commit changes the stylesheet loading to happen much earlier in the
process so the stylesheet is applied before theme preselection has
chance to happen.
Assigning a material without an appearance reset the appearance to the
default appearance.
There were two main problems. One was the comparison function for
App::Material objects. It would return false when the UUID or MatType
values were different although there are many circumstances where this
could be true and the appearance be the same. It also incorrectly
compared the imagePath.
The second problem was the logic for detecting if an object has already
been assigned an appearance by assigning a material or manually setting
the appearance. If assigned a material, the appearance should update but
not if it has been set manually. This logic has been corrected.
* Core: Convert transparency to alpha
Create new `Base::getVersion()` function for extracting a program
version enumeration given a version string.
Convert transparency to alpha value for old project files.
* Base/App: Address review comments
---------
Co-authored-by: wmayer <wmayer@freecad.org>
* Core: workaround for Building US unit system bug
Fixes#11345
This workaround should hopefully fix the Building US unit system bug at the level of the InputField code. This is the most feasible solution given that we are currently in the v1.1 feature freeze.
I use the word "hopefully" because I have not compiled and tested the code. But replacing `+` with `--` works in Python examples.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Fix typo in comment
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Currently `ExpLineEdit::apply()` passes `QString::constData()` to a
printf-style format string with %s. `QString::constData() returns a
const QChar* (UTF-16, 2 bytes per char), but %s expects a const char*
(UTF-8/ASCII with 1 byte per char).
This results in a string being interpreted as in "Container":
Byte 0: 'C'
Byte 1: 0x00 (high byte of UTF-16 'C', which gets interpreted as null
terminator)
So this patch uses proper conversion to null-terminated C-String before
passing it further.
For some reason the empty layout was not saved for users with existing
config. To ensure that the change does not affect existing users and is
persistent for current ones we need to save value with older default
before using it. Previous solution did not work correctly as the widgets
were not persisted correctly.
Currently if user tries to press TAB during Expression Editor, it
inserts both the entry and its first subentry. Also, if user browses the
dropdown with arrows keys, it inserts it's values.
Root cause of that is the regression made in latest changes to chaining
completion logic which is triggered for all completion modes including
TAB, which already has its own refresh mechanism. Also,
ExpressionTextEdit connected both activated (Enter/click) and highlight
signals to the same slot, resulting in arrow key navigation inserting
completions.
So, this adds separate slots for ExpressionTextEdit to differentiate
completion modes. And also updates tab handling to pass
ActivationMode::Highlighted to prevent double chaining.
This basically is due to how OverlayTabWidget::setRect is implemented. If it faces width (or
height) of 0 it forces the width to be minimumOverlayWidth * 3, which in the default config
appears to be 90. 90 is obviously way too small of a value to display any widget in the side
panel, so we need to basically need to treat anything smaller or equal to that as an
incorrect value for width. We use here 100 just to be safe.
For the height value of 100 may be reasonable, so we leave it as is.
