SummaryQueryWidget::queryStr() built its ORDER BY from the columns the user
chose to display, in the order they chose them:
column += key;
order_by += key;
So a summary whose first column is Title came out sorted alphabetically by
title, and one starting with Author sorted by author. A table of contents
lists the folios of a project; its order is the project's order, not
whatever the first column happens to be.
It now orders by "pos", the folio position that project_summary_view already
exposes from diagram.pos. That column is an INTEGER, so the sort is numeric
and folio 10 does not land between folio 1 and folio 2. One row per folio
means pos fully determines the order, so no secondary key is needed.
Demonstrated against a stand-in view holding four folios:
ORDER BY title, pos Apple(2) Banana(3) Mango(10) Zebra(1)
ORDER BY pos Zebra(1) Apple(2) Banana(3) Mango(10)
The hand-written query path (m_edit_sql_query_cb) returns before this and is
untouched, so anyone wanting a different order still has one.
ctest 4/4, Qt 5.15.18.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
Replace QETApp::diagramInfoKeys() by QETInformation::diagramInfoKeys()
and QETApp::diagramTranslatedInfoKey(str) by
QETInformation::translatedInfoKey(str)
ispyisail