Menu audit: two whole feature families are toolbar-only, plus a handful of orphaned actions

[ispyisail]

I had a suspicion that some QET features are only reachable from a toolbar, a
context menu or a shortcut, and never appear in the menu bar. I checked it
properly rather than guessing: I diffed every QAction against every menu, in
all three editors.

The suspicion was right, and the interesting part is that this is drift, not a
design decision — two of the three editors are already complete:

Editor	Actions reachable from a menu
Title block editor	all of them ✅
Element editor — actions declared in qetelementeditor.ui	37 / 37 ✅
Element editor — actions created in C++	0 / 8 ❌
Diagram editor	7 actions + several groups missing ❌

So there is already a house convention of "everything is in the menus". The gaps
are all in code that was added after the menus were written.

All line references below are against master 7307a59c1.

---

A. A whole feature family is toolbar-only

m_add_item_actions_group is created at qetdiagrameditor.cpp:707-713 and added
to m_add_item_tool_bar at :818. It is added to no menu anywhere:

• Ajouter un champ de texte
• Ajouter une image
• Ajouter une ligne
• Ajouter un rectangle
• Ajouter une ellipse
• Ajouter une polyligne
• Ajouter un plan de bornes

Since that toolbar is user-hideable (Configuration → Afficher), hiding it makes
all seven features unreachable — there is no menu entry, no shortcut and no
context-menu entry for any of them.

There is a fossil suggesting this was already noticed. qetdiagrameditor.cpp:841:

// QMenu *menu_outils    = new QMenu(tr("O&utils"), this);

A Tools menu was started and commented out.

B. The same gap in the element editor

Same pattern, different file. m_add_part_action_grp
(qetelementeditor.cpp:1050-1057) — line, rectangle, ellipse, polygon, text,
arc, terminal, dynamic text field — is added only to parts_toolbar at :1079.

The .ui file is a perfect 37/37. The eight drawing actions were added in C++
later and never made it into the menus.

In both editors, the toolbar-only family is the drawing primitives. That is
consistent enough to look like the same oversight repeated.

C. Two toggles that are inconsistent with their neighbours

view_tool_bar->addAction(m_draw_grid);           // :806  — also in Affichage ✅
view_tool_bar->addAction(m_draw_guides);         // :807  — toolbar only ❌
diagram_tool_bar->addAction(m_auto_conductor);   // :814  — toolbar only ❌

Grid and guides are adjacent lines doing the same kind of thing, and only one of
them is in the menu.

m_auto_conductor is the odder one: it writes a project setting
(project()->setAutoConductor()) but has no entry in the Projet menu.

D. Context-menu-only actions

Created in DiagramView, surfaced nowhere else:

Action	Line
Coller ici	diagramview.cpp:81
Collage multiple	:84
Créer un template	:91

The last one is the only way to author a .qetmak macro, and it is reachable
only by right-clicking a selection.

E. Collections panel — 12 context-menu-only actions

elementscollectionwidget.cpp:150-177. Most of these are arguably fine as
context actions, but one stands out: "Importer une pièce EPLAN (.edz)…".
That is a whole import subsystem, with its own parser, reachable only by
right-clicking inside the collection tree. Also there: Nouvel élément, Nouveau
dossier, Recharger les collections.

F. The most hidden feature I found

diagramview.cpp:616 — "Connecter les bornes sélectionnées".

It is constructed as a transient QAction inside mouseReleaseEvent, and only
appears if you make a free-rubberband selection that happens to produce more
than three points. No menu, no toolbar, no shortcut — the action does not exist
as an object until that moment.

I only found it by reading the code. I would be curious how many users know it
is there.

G. Two dead members

conductor_default and m_project_folio_list (qetdiagrameditor.h:194 and
:202) are declared but never allocated and never referenced anywhere in the
tree. Uninitialised raw pointers; harmless today since nothing dereferences
them, but worth removing.

---

Two things that are fine

Flagging these so nobody spends effort on them:

• Docks and toolbars are reachable. QETMainWindow::checkToolbarsmenu()
  (qetmainwindow.cpp:234) injects Qt's createPopupMenu() into
  Configuration → Afficher. I expected this to be missing and it is not.
• The title block editor is complete.

---

Proposed fix

Mostly addAction lines in setUpMenu():

1. Give the seven add-item actions a menu — either restoring the commented-out
   Outils, or a new Insertion menu. Same for the element editor's eight
   drawing actions in its .ui.
2. m_draw_guides next to m_draw_grid in Affichage; m_auto_conductor into
   Projet.
3. Coller ici and Collage multiple into Édition near Coller; Créer un template into Projet.
4. Importer une pièce EPLAN (.edz)… into Fichier, ideally under an Import
   submenu.
5. Delete the two dead members.
6. Find a home for "Connecter les bornes sélectionnées".

Questions before I write any of it

1. Is "every feature must be in a menu" the rule we want? I have assumed yes
   because two of the three editors already satisfy it, but it is worth stating
   explicitly rather than inferring it.
2. Where should the add-item actions go — restore Outils, or a new
   Insertion menu? Items 1, 3 and 4 together add roughly 15 entries to menus
   that are currently quite lean, so this is a menu-structure decision more than
   a code one, and I would rather agree it here than propose it in a diff.
3. Should items 2 and 5 go first as a small standalone PR? They are
   uncontroversial — one missing toggle, one project setting, two dead members —
   and they do not depend on the structural decision in question 2.
4. Is "Connecter les bornes sélectionnées" meant to be as hidden as it is?
   If it is deliberate I will leave it alone, but it currently has no
   discoverable path at all.

Happy to do the work — I would just rather settle 1 and 2 before opening a PR
that rearranges menus.

[ispyisail]

Opened #678 for question 3 — the parts that don't depend on the menu-structure decision.

It covers:

• m_draw_guides → Affichage, directly under "Afficher la grille"
• m_auto_conductor → Projet, placed with the project properties above a separator so the folio operations stay grouped exactly as they are now. It writes QETProject::setAutoConductor(), so Projet is where someone would go looking for it
• conductor_default and m_project_folio_list removed from the header

+3/-2 across two files, built clean (CMake/Ninja Release, Qt 5.15.18). No new strings — both actions already carry translated text, this only gives them somewhere to appear.

Two things I checked rather than assumed, in case they're useful to a reviewer:

• setUpMenu() runs after setUpActions() (qetdiagrameditor.cpp:122-124), so both pointers are valid where they're added. Had that order been the other way round the code would have looked correct and failed at runtime.
• That the build still links after deleting the two members is itself the proof they were dead — any reference would have broken it.

Still open here: questions 1, 2 and 4 — whether "every feature is in a menu" is the rule we want, where the add-item actions should live (restore Outils, or a new Insertion menu), and whether "Connecter les bornes sélectionnées" is meant to be as hidden as it is.

The two toolbar-only drawing families are the substance of this audit and I've deliberately kept them out of #678, since they're a menu-structure call rather than a code one. Happy to do that work once there's a direction.