Feature idea: resize text by dragging its bounding rect (forum #2168)

[ispyisail]

Forum request: https://qelectrotech.org/forum/viewtopic.php?id=2168 — resize text height/width and reposition by dragging, for "line edit and label text", referencing Inkscape's text tool as the model. A QET team developer (Joshua) replied "Added to todolist," so this has some prior maintainer interest, but nothing has been built.

Problem

Right now, dragging a text item on a diagram only moves it — there's no way to resize a text box's width by dragging its bounding rectangle, the way Inkscape (and most vector editors) let you drag a text box's edge/corner to reflow it.

What the request actually covers, and why the scope below is split

Text on a diagram isn't one class — I went through all of them before writing this up:

Class	What it is	Has a width property today?
DynamicElementTextItem	Diagram-placed dynamic text (element label, "user text", "element info", composite text)	Yes — textWidth Q_PROPERTY, already round-tripped to XML as text_width (sources/qetgraphicsitem/dynamicelementtextitem.cpp:183)
IndependentTextItem	The free text box a user manually drops on a diagram — the closest match to "like Inkscape"	No. toXml/fromXml (independenttextitem.cpp:60-86) only serialize x, y, text, rotation, font — no width/frame-size attribute exists at all
PartText / PartDynamicTextField	Static/dynamic text inside the element editor (authoring custom element symbols, not diagram end-user text)	PartDynamicTextField has textWidth; PartText doesn't. Both classes' handleUserTransformation() (the element editor's existing drag-resize hook) currently only repositions, never resizes — even here, text drag-resize doesn't exist yet

So "resize by dragging" is cheap for one of these and not for the other, which is why I'm proposing them as two phases rather than one feature.

Proposed scope

Phase 1 — DynamicElementTextItem (diagram-placed dynamic text). This is the buildable, low-risk piece:

• Add hover/edge detection to the item (or a small set of grip handles) so dragging near the right/left edge changes width instead of position.
• On release, push new QPropertyUndoCommand(item, "textWidth", old_width, new_width) — the exact same call the existing properties-panel spinbox already uses (sources/ui/dynamicelementtextmodel.cpp:590). No new undo-command class, no new XML, no new data model — the property and its persistence already exist end-to-end.
• Reuse QetGraphicsHandlerItem (sources/QetGraphicsItemModeler/qetgraphicshandleritem.h) for the actual grip handles/hover animation rather than inventing new grip rendering — it's a generic class already used for exactly this in the element editor (ElementPrimitiveDecorator), not tied to that scene.

Phase 2 — IndependentTextItem (free diagram text boxes). The bigger lift, proposed as a separate follow-up once phase 1 lands:

• Requires designing and adding a new serialized width/frame property (with the format-migration considerations that implies) before any drag-resize interaction can be built on top of it — there's currently nothing to resize.

Not proposed here: resize for PartText/PartDynamicTextField in the element editor — that's about authoring element symbols, a different (smaller) audience than diagram end-users, and can be revisited later using the same approach once phase 1's interaction code exists to copy from.

Why this shape

• Element/DiagramTextItem/DynamicElementTextItem's current mousePressEvent/mouseMoveEvent/mouseReleaseEvent (dynamicelementtextitem.cpp:540-625, diagramtextitem.cpp:328-393) are pure move-only — no hover-based edge detection, no cursor change today, so this hit-testing is genuinely new regardless of which item type it targets.
• The element editor's existing grip-handle mechanism (ElementPrimitiveDecorator + QetGraphicsHandlerItem, sources/editor/elementprimitivedecorator.cpp:468-492, 526-574, 748-780) is the right pattern to imitate: handles as separate QGraphicsItems routed via sceneEventFilter, resolving to a rect-transform call — PartRectangle::handleUserTransformation (partrectangle.cpp:309-315) is the clean "real resize" example to model after, versus PartText's/PartDynamicTextField's versions which currently only move.
• Splitting phases avoids blocking the cheap, high-value 90% of the request (dynamic text on diagrams, which is what most users interact with) behind the harder 10% (a new property + XML format work for free text boxes).

Happy to build phase 1 if this scope sounds right.

[ispyisail]

Built phase 1: #591 — adds the two-handle width drag-resize to DynamicElementTextItem, reusing QetShapeItem's existing QetGraphicsHandlerItem pattern (scene-added handles + installSceneEventFilter, not the element editor's ElementPrimitiveDecorator, which is scoped to multi-item scene-space scaling). Live-drags the width with immediate visual feedback, then pushes the same QPropertyUndoCommand the properties-panel width spinbox already uses on release -- no new undo command, no new XML.

One correctness detail worth flagging: the original textWidth() can be -1 (auto-sized). Undo needed to restore that exact -1 state, not a fixed width that merely renders the same, so the drag's delta math uses a separate concrete baseline while the undo command's old_value keeps the real (possibly -1) original.

Verified headlessly: handles appear on selection, live-resize confirmed via the properties panel's width field updating in real time, undo restores exact original state (including back to auto), redo reapplies. IndependentTextItem and the element editor's PartText/PartDynamicTextField remain phase 2/out-of-scope as proposed, since neither has a serialized width property to resize yet.

[ispyisail]

Status: in progress — PR #591: #591