Static texts (PartText) gain an optional alignment, exposed via the
existing AlignmentTextDialog behind a new "Alignement" button in the
static text editor:
- The horizontal part aligns the lines of a multi-line text relative
to each other (centered block labels no longer need one hand-placed
text per line).
- The full alignment defines the anchor: when the content or font
changes later, the selected corner/center of the bounding rect keeps
its place instead of always growing right/down from the top-left
(same prepareAlignment/finishAlignment logic as DiagramTextItem).
Format: the <text> node takes the same optional Halignment/Valignment
attributes as dynamic_text, written only when they differ from the
historical top-left behaviour - existing .elmt files are untouched and
round-trip byte-identical. The saved x/y stay the baseline-left of the
text block in all cases; ElementPictureFactory only needs the line
alignment (the anchor is editor-side behaviour), so rendered elements
match the editor exactly.
German translations for the three new strings included (qet_de stays
complete, 2686/2686).
Verified headless: a project embedding a two-line text once with
Halignment=AlignHCenter and once without exports to SVG with the short
line centered under the long one (x 102.5 vs 126.5) in the aligned
block, and identical x for both lines in the legacy block. Editor-side
anchor behaviour follows the proven DiagramTextItem implementation but
was not manually exercised in the GUI yet.
m_first_move was initialized before _linestyle in the constructor
initializer list, but _linestyle is declared first in the class. Reorder
to match declaration order.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When an item type is selected for the first time the properties dock
expands, causing the QGraphicsView viewport to shrink. Qt recalculates
scene coordinates and fires one or more synthetic mouseMoveEvents before
the user has actually moved the mouse.
The original code used a single-shot m_first_move flag in
CustomElementGraphicPart, which absorbed exactly one spurious event.
PartText and PartDynamicTextField had no protection at all.
Fix: compare screen-coordinate displacement against
QApplication::startDragDistance() (~4 px). Screen coordinates are
stable across viewport resizes, so the check correctly rejects
synthetic dock-expansion events while allowing genuine drags.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
iIn the element editor, every rotation is made around the center of the
scene, this is usefull when rotate several part but less when only one
need to be rotated, especially when it is the terminal part and we only
want to change the orientation.
This commit solve it. Now when only a terminal part is selected, the
terminal don't rotate around the center of the scene but change the
orientation.
The rotation, flip and mirror of parts are good features but always
rotate around the center of the scene and if the parts are far from the
center of the scene the behavior look inappropriate from the POV of user
(because parts move far from original position and can out of the view).
A good new features should be to solve it (rotate around the center of
the bounding rect of the selection) and probably extract the function
rotate/flip/mirror from the parts class and create a new class with for
only goal to calculate and apply these modifiaction trough an undo
command.
When reading and comparing Qt5-docs and Qt6-docs, I read,
that there are no differences in the functions!
So it is not necessary to have the differentiation
between the Qt-Versions.
Code compiles without errors or warnings for Qt5 and Qt6.
Maybe not (yet) perfect, but it looks pretty good to me!
Why am I doing this to myself?
All this crap with fonts and stuff!
It's been crap for as long as I can remember.
Now that the problem with the translations of keyboard shortcuts has been resolved and rotation using the space bar works reliably in principle, I took a closer look at the rotation function itself in the element editor.
I noticed, for example, that arcs can be rotated at an angle of 15°. This doesn't really make sense, as the “arc” part doesn't have the “rotation” property. There is only width and height.
And somehow rotating arcs didn't work well: start- and span-angles weren't adjusted.
Lines and polygons can be rotated in 15° increments, which doesn't make much sense, if other parts that can only be rotated in 90° increments are selected at the same time.
To make a long story short:
I reworked the rotation functions of the graphical parts so that now all parts are rotated in 90° steps around the origin! This means that it is now possible to mark several parts and rotate them around the same point at the same time!
In addition, the functions for mirroring graphic parts at y-axis (shortcut "M") and flipping at x-axis (shortcut "F") have been implemented.
I have saved the text elements for later!
(or someone else)
clazy is a compiler plugin which allows clang to understand Qt
semantics. You get more than 50 Qt related compiler warnings, ranging
from unneeded memory allocations to misusage of API, including fix-its
for automatic refactoring.
https://invent.kde.org/sdk/clazy
In the part list widget, the terminal name is empty if terminal haven't
got name.
Now "terminal" is always displayed and if the terminal have a name the
name is appended to "terminal".
Example :
if the terminal name is 24 then the the part list widget show "terminal
: 24"
std::variant/std::visit was only introduced with C++17. Remove its usage.
We don't even need it in these cases since QColor has an implicit constructor accepting Qt::GlobalColor.
Follow-up for b69c7b1027
Compilation using MSVC fails with a C1061 error since MSVC has a hard limit on block nesting.
Refactor the code in question to use map lookups instead.
* Some types of elements need to specialize the setRotation method in order to behave correctly :
- PartTerminal needs to call setOrientation
- PartLine, PartRectangle and PartPolygon need a different rotation center.
Fix an unwanted behavior when the properties dock widget is displayed :
1 there is no selection
2 the dock widget width is set to minimum
3 select a part, the dock widget gain new widgets used to edit the
current selected part and the width of the dock grow so the width of the
QGraphicsView is reduced and cause a mouse move event.
When this case occur the part is moved but they should not.
Dieter Mayer