Bugtracker #309: selecting a result from the Search/Replace hit list
highlights the matching element, but on a diagram too large to fit
the current view, the view itself never scrolls -- the highlighted
element can be entirely off-screen with no indication of where it
went. The reporter pinpointed the exact spot,
searchandreplacewidget.cpp:1022, and suggested repositioning the
view's scrollbars.
SearchAndReplaceWidget::on_m_tree_widget_currentItemChanged() already
calls setHighlighted()/setSelected() on the matched element, text, or
conductor when a hit is selected; it just never brings it into view.
Added a call to QGraphicsItem::ensureVisible() alongside each of the
three existing highlight/select calls, so the view scrolls the
minimum needed for the match to be visible.
Followed the same approach as JumpToElementDialog's
activateCurrentItem() (added this session for #676) rather than
computing scrollbar positions by hand as suggested: ensureVisible()
scrolls every view showing the diagram automatically, works correctly
if a folio is open in more than one window, and needed no lookup of
which QGraphicsView the widget is attached to -- this widget doesn't
currently hold one. It was the only existing precedent for this exact
"scroll to reveal a matched item" problem anywhere in the codebase.
Verified live: built and ran the app under Xvfb, zoomed into one
corner of an example diagram until it needed scrollbars, searched for
text appearing in two different elements ("Offset null", both
op-amp offset-null pins), and confirmed selecting each result
scrolled the view to a different part of the diagram, centering the
matched element's highlight circle in the visible area each time. No
new build warnings.
QHash/QMap::keys() allocates a list of every key on each call, then
contains() searches it linearly - an accidental O(n) plus allocation
where a direct O(1) lookup was meant. 35 occurrences across 7 files,
found while profiling project load times (context: #553/#560).
The hot one is ElementPictureFactory::getPictures(), which runs once
per element instance on project load: on the 3399 KiB example project
(191 instances, 129 cache hits) the keys() detour cost 45 ms of the
1.34 s total - measured, not estimated; the fix reproducibly shaves
~35-45 ms off that load. The remaining call sites are UI paths
(search&replace, dynamic text model, undo commands) where the waste
scales with selection/model size.
No behavior change: for QHash/QMap, keys().contains(k) and
contains(k) are equivalent by definition.
(cherry picked from commit 0a7f8f072fa68de7c01a9fc134a4bc8e16d62062)
Qet crash when double click on an element/text/conductor in the tree
widget of the search and replace widget and the item is deleted from
diagram. (Call of Diagram::showme to a nullptr).
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
Fix 1 : when widget is reloaded the categories is not checked, but the
child items is. Now all category is checked when reloaded.
Fix 2 : the folio number displayed in the widget is wrong (start at 0
instead of 1)
Replace QETApp::diagramInfoKeys() by QETInformation::diagramInfoKeys()
and QETApp::diagramTranslatedInfoKey(str) by
QETInformation::translatedInfoKey(str)
Replace QETApp::conductorInfoKeys() and
QETApp::conductorTranslatedInfoKey(const QString &key) by
QETInformation::conductorInfoKeys() and
QETInformation::translatedInfoKey
Use the function QETInformation::translatedInfoKey(const QString &info)
instead of QETApp::elementTranslatedInfoKey(const QString &info).
The final goal is to remove all information from the QETApp and use
instea QETInformation who is dedicated to this
Minor gui change of conductor properties widget
git-svn-id: svn+ssh://svn.tuxfamily.org/svnroot/qet/qet/trunk@5647 bfdf4180-ca20-0410-9c96-a3a8aa849046
ispyisail