-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Controller preferences: add searchbars to mapping tables #11165
Conversation
02ac407
to
a7fed6b
Compare
…g Return in searchbars
…o base class ... and add respective new Qt6 method
a7fed6b
to
2f7a3a6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. Just a few comments for improving code.
A test is pending.
@@ -189,6 +190,53 @@ QVariant ControllerOutputMappingTableModel::data(const QModelIndex& index, | |||
return QVariant(); | |||
} | |||
|
|||
QString ControllerOutputMappingTableModel::displayString(const QModelIndex& index) const { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not clear from the function name if the function is an imperative or a getter.
Can we improve it? Something like getStringForSearch()
Alternative we may integrate the code into data() itself using a new user role
e.g. SearchRole = Qt::UserRole + 1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, let's call it getDisplayString
then?
Tbh I'd rather stick to explicit QString getDisplayString
instead of having to deal with even more type conversion and more safety checks in data().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the idea to use a custom role!
if (tokenMatch) { | ||
break; | ||
} | ||
column++; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the main use case for the good old for() loop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
What is the state of https://github.com/ronso0/mixxx/tree/mapping-table-search_wsearch? Is the issue?
I think here we need to use |
It's a test / WIP until someone can figure out the cause.
No, that's unrelated to WSearchLineedit. Locally with Qt5 it builds and runs fine, only CI with Qt6 failed because of this. |
connect(m_ui.inputControlSearchBtn, | ||
&QPushButton::clicked, | ||
this, | ||
&DlgPrefController::slotInputControlSearch); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These connections can be done in the constructor.
This is also an issue in https://github.com/ronso0/mixxx/tree/mapping-table-search_wsearch
after a while these controls are 10 times connected and a search is done that often slowing down the process.
After moving them to the constructor there is no longer an extra GUI lag.
Another possible issue is that ControllerMappingTableProxyModel::filterAcceptsRow()
is quite slow.
In case of searching during typing, it is called often but is acting always on the same data.
Maybe there is a way to cache the heavy work of retreaving and fromating all strinsg over and over again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, true, I moved the conection to the constructor.
However that is not the issue with WSearchLineEdit since the GUI lockup occurs when the mapping is shown for the first time (only one conection) and no search signal has been fired, yet.
I guess it's related to some show/resize event or a conflicting QWidget/WWidget method, because occasionally I also experience another issue with the WSearchLineEdit in DlgDeveloperTools (dialog is extremly wide, ~10x screen width).
Since the current simple search works well I'm not motivated to debug that further right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case of searching during typing, it is called often but is acting always on the same data.
Maybe there is a way to cache the heavy work of retreaving and fromating all strinsg over and over again.
With the simple search there is no search-as-you-type, it's only triggered by Return or the Search button (and after editing items).
Also, data
and the delegates' displayText
get called every time the view changes (scroll, show, hide ...) so I'm not sure if custom caching is worth the effort for this view of rather small data models (after all, even with huge mappings, each table holds like ~200 items max?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Thank you.
Adds simple searchbars above the mapping control tables:
Actually I used
WSearchLineEdits
from the beginning, but with those, showing the Controller preferences (first show, overview tab) would randomly slow down the GUI and glitches occured as if something was processed concurrently (or while the model was about to be built), but I just couldn't figure out what exactly was causing this.The branch is https://github.com/ronso0/mixxx/tree/mapping-table-search_wsearch, in case you have some spare minutes to take a fresh look at it.