D28675: [KMimeTypeChooser] Add the ability to filter the treeview with a QSFPM

[David Faure]

dfaure added a comment.


  In D28675#645733 <https://phabricator.kde.org/D28675#645733>, @ahmadsamir wrote:
  
  > A tooltip isn't good enough here?
  
  
  I don't know. I don't claim to be a UI expert.
  But for instance your lineedit could filter on the comment as well, to help the user locate a mimetype based on a keyword in its description. If it's "hidden" in a tooltip then that doesn't really work.
  This allows user to use words in their own language for that search (e.g. "lecteur audio" when looking for x-content/audio-player)
  Or imagine looking for "3D Studio" files for instance -- but I can see how finding by extension is the most useful way, users know those are called *.3ds.
  
  > but I haven't set in lines in the sand about that column, bringing it back should be easy.
  
  I think filtering *is* a great reason to bring it back.
  
  > it seemed easier (less work :)) to use an existing model rather than sub-classing.
  
  Certainly.
  
  > So what you're saying here is that sub-classing QAbstractItemModel is better; I'll try that, but I am curious about why a sub-class is better than using QStandardItemModel (are there any docs/blogs... etc about that?)
  
  I'm used to explaining it at length as a professional Qt trainer, but I don't really know all about online resources ;)
  
  Yes, for anything above trivial sizes (like 10 items), subclassing QAbstractItemModel is generally better.
  With QStandardItemModel (or Q*WidgetItem) you're *copying* the data into the model. In general that data is then twice in memory, once in the underlying application-specific data structures and once in the model. QStrings are cheap to copy, but when thinking about non-readonly models, it also means the two things need to be kept in sync.
  
  Here the situation is a bit different, though. First it's readonly, and second, the data comes from a temporary QMimeDatabase instance (which reads and converts from a mmaped file, it doesn't *store* QStrings in memory). So the underlying data actually goes away, we don't actually have real duplication in memory.
  Therefore this is one case where I cannot argue against QStandardItemModel ;)
  It is just slightly more heavy (map of variants) than a simple model that would store 4 strings per node.
  But the amount of code required for a custom tree model is, I think, not worth it here.
  Let's go with QStandardItemModel. This dialog doesn't even stay in memory very long anyway.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D28675

To: ahmadsamir, #frameworks, cfeck, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200411/46b76310/attachment-0001.html>