- Add missing <QHash> include: QHash<QUuid, QVector<QPointF>> was
only forward-declared transitively under Qt5's heavier headers;
Qt6's leaner <QPainter> etc. no longer pull it in.
- Replace QPolygonF{points_} with QPolygonF(points_): under Qt6,
QPolygonF inherits QList<QPointF>'s constructors via 'using
QList<QPointF>::QList;', including the std::initializer_list<T>
one. Brace-init-list construction with a single argument first
considers only initializer-list constructors before falling
back to regular ones, which trips up overload resolution here
even though points_ is exactly a QList<QPointF> (QVector is a
plain alias for QList under Qt6). Plain parenthesised
construction sidesteps that resolution phase entirely and binds
directly to QPolygonF(const QList<QPointF>&).
QVector::size() (== QList::size() under Qt6) returns qsizetype
(64-bit), while 'level' is a plain int. std::min(level,
m_real_terminal.size()-1) therefore tries to deduce a single T
from two different argument types, which fails - GCC reports it
against the unrelated std::min(initializer_list<T>) overload,
but the real issue is the type mismatch between the two-argument
candidates. Under Qt5, QVector::size() returned int, so this
compiled fine.
Force T=int explicitly via std::min<int>(...) and cast size()
down to int (physical terminal counts are always tiny), matching
the pattern already used safely elsewhere in the codebase (e.g.
qetgraphicstableitem.cpp).
Since Qt 6.5, QDomDocument::setContent() returns a ParseResult
struct with an *explicit* operator bool(), so 'bool x =
doc.setContent(...)' (copy-initialization) no longer compiles -
explicit conversions aren't considered there.
This exact issue was already fixed in titleblocktemplate.cpp by
dropping the intermediate bool and testing the call directly in
the if condition (contextual bool conversion in an if() is fine
even for an explicit operator bool), but this second occurrence
in templatescollection.cpp used the same pattern and was missed.
Applying the same fix here for consistency.
templateview.h only included <QGraphicsView> but uses
QGraphicsGridLayout (tbgrid_ member) and QGraphicsLayoutItem
(indexOf/removeItem signatures) directly. Some Qt5 header
apparently pulled these in transitively; Qt6's leaner headers
don't, so the class fields/methods silently failed to resolve
and the compiler picked bogus 'int*' overloads instead.
Other files in the same directory already get these symbols
either via the <QtWidgets> umbrella header or a direct include,
so this was an isolated gap.
The Qt6 branch of the #if QT_VERSION guard swapped QRegExp for
QRegularExpression but kept calling QRegExp-only methods
(exactMatch()/cap()), which QRegularExpression doesn't have.
Use the correct QRegularExpression API instead: match() returns
a QRegularExpressionMatch, tested with hasMatch() and read with
captured(n).
- qetxml.h: add missing <QUuid> include (used in propertyUuid/
createXmlProperty signatures but never included directly).
- machine_info.cpp: fix ambiguous QString/int operator> in
send_info_to_debug() for it1/it2/it3; just count every
matching file found instead of the meaningless comparison.
The project panel's "copy and paste" action duplicates a folio through
an XML round-trip (toXml/fromXml), and Element::fromXml adopts the uuid
stored in the XML - so every element on the duplicated folio kept the
uuid of its source element. On-diagram copy/paste already handles this
(PasteDiagramCommand::redo() calls newUuid()), but the folio-duplicate
path bypasses that command.
Since element.uuid is the PRIMARY KEY of the project database, the
duplicated elements failed to insert ("UNIQUE constraint failed:
element.uuid" spam in the log) and silently disappeared from
nomenclature/summary tables, even though they are valid on the folio.
Renew the uuid of every element on the freshly duplicated folio, exactly
as the paste command does. In-memory links established during fromXml
are pointer-based and unaffected; the new uuids are written on save.
On Debian/Ubuntu qt6-base-dev ships the Qt6::GuiPrivate CMake config but
the actual private headers live in the separate qt6-base-private-dev
package, so find_package succeeds and CMake only fails later at generate
time with a non-obvious "non-existent path" error. QET genuinely needs
the private QtGui API (QPdfEngine) for clickable hyperlinks in the PDF
export, so document the package instead of degrading the feature.
Observed on Ubuntu 26.04 LTS (Qt 6.10.2); Debian sid and the Qt online
installer ship the headers together.
The default build ran both lupdate (qt5_create_translation, which
rewrites the tracked .ts files in the source tree) and lrelease
(qt5_add_translation, which reads the same .ts files). Under high
parallelism lrelease could read a .ts while lupdate was rewriting it,
failing the build with "Premature end of document"; every build also
modified tracked files as a side effect, and each .qm was generated
twice (once into the build dir, once into lang/).
Keep only lrelease in the default build and move lupdate behind an
explicit developer target (cmake --build . --target update_translations).
The target scans sources/ instead of the whole source tree, which also
stops lupdate from parsing unrelated third-party .js files.
Clears the 9 non-deprecation warnings from the Qt6 build:
- qHash(QColor): hash rgba() (unambiguous QRgb) instead of name(), and
use the size_t seed signature on Qt6 (guarded for Qt5). Fixes the
ambiguous-overload warning in terminalstripmodel.h.
- Two qsizetype->int narrowings in brace-init: explicit static_cast<int>
(elementscene.cpp, terminalstrip.cpp).
- main.cpp: keep the QtConcurrent::run QFuture in a [[maybe_unused]]
variable (nodiscard).
- qetapp.cpp: guard the stylesheet load on QFile::open() succeeding
(nodiscard) instead of ignoring the result.
QVariant::canConvert(int) is deprecated in Qt6. Use the non-deprecated
canConvert<T>() template (canConvert<QString>() / canConvert<int>()),
which is available on Qt5 too. Clears the last 2 -Wdeprecated-
declarations warnings.
Three deprecated APIs have replacements that only exist in newer Qt6:
- QLocale::nativeCountryName() -> nativeTerritoryName() (Qt 6.2)
- QDomDocument::setContent() overload -> ParseResult (Qt 6.5)
- qt_ntfs_permission_lookup -> QNtfsPermissionCheckGuard RAII (Qt 6.6)
Each is wrapped in QT_VERSION_CHECK so Qt5 keeps the old path. Clears
4 -Wdeprecated-declarations warnings.
QString::count() (no-arg) is deprecated -> size(); QColor::setNamedColor()
is deprecated -> the QColor(QString) constructor. Both replacements are
non-deprecated on Qt5 too. Clears 2 -Wdeprecated-declarations warnings.
QSqlDatabase::exec(const QString&) is deprecated in Qt6. Route the
PRAGMA/CREATE TABLE statements through QSqlQuery(db).exec() instead.
Clears 11 -Wdeprecated-declarations warnings; same statements, same
database connection, no behavioural change.
QVariant::type() and the QVariant::Type enum are deprecated in Qt6.
Switch on userType() (non-deprecated, returns the QMetaType id and
works on Qt5 too) with QMetaType enum cases. Clears 6 -Wdeprecated-
declarations warnings; the numeric type ids are unchanged.
qAsConst was deprecated in Qt 6.6; std::as_const (C++17, already the
project standard) is the drop-in replacement. Clears 46 -Wdeprecated-
declarations warnings across 18 files. No behavioural change.
Regenerate lang/qet_de.qm from lang/qet_de.ts with lrelease so the
committed binary matches the strings completed in #538
(2621 finished, 0 unfinished for de_DE).
qet_de.ts had 20 unfinished entries in the PartTerminal and
TerminalEditor contexts: 12 empty ones (shown in French at runtime,
since French is the source language of the tr() literals) and 8 that
already carried German text but were still flagged unfinished.
Translate the 12 empty strings, matching the terminology already
established in these contexts (borne/terminal -> "Anschluss",
label -> "Beschriftung", cadre -> "Rahmen", police -> "Schriftart"),
and mark the 8 existing drafts as finished. lrelease now reports
2621 finished and 0 unfinished translations for de_DE.
NamesList::name() looked up the display name using the full locale from
langFromSetting() (e.g. "de_DE") and jumped straight to English if it was
absent. Element and folder names in the collection are keyed by 2-letter
codes (<name lang="de">), so a "de_DE" UI showed the whole collection in
English/French even though German names exist.
Try the base language ("de") before the English fallback, mirroring what
setLanguage() already does for the UI translations.
joshua