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

[Ahmad Samir]

ahmadsamir marked an inline comment as done.
ahmadsamir added a comment.


  I thought that adding the "comment" as a tooltip makes sure it's always available if the dialog is shown with the flag for the comment column unset... but looking on lxr.kde all the usage of KMimeTypeChooserDialog always show the comments column; so that idea is redundant.
  
  A tooltip isn't good enough here? I think the mimetype name and extension are more recognisable/useful than the comment; especially since the comment sometimes isn't that useful:
  AMR        AMR Audio
  troff      Troff document
  x-base32   Base32 encoded data
  x-rpm-spec RPM spec file
  
  but I haven't set in lines in the sand about that column, bringing it back should be easy.
  
  In D28675#645714 <https://phabricator.kde.org/D28675#645714>, @dfaure wrote:
  
  > I'm also curious about the use of QStandardItemModel which I consider to be at best a class for unittesting proxies and views. Just like QTreeWidgetItem it stores the data.
  >  Of course compared to QTreeWidgetItem it's one step into the "right" direction of item/view separation, so why not, but it's not exactly more efficient.
  
  
  That answers a question that kept popping in my mind while working on this, whether to try sub-class'ing QAbstractItemModel, or just use QStandardItemModel; basically whether one is better than the other. Certainly the documentation that I read so far doesn't tell me exactly which way to go. Of course I noticed lots of sub-classing of QAbstractItemModel in KDE, but it seemed easier (less work :)) to use an existing model rather than sub-classing.
  
  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?)

INLINE COMMENTS

> dfaure wrote in kmimetypechooser.cpp:44
> In my experience a vector of const pointers is usually a pain to work with, e.g. for find(). But you're lucky here it seems, it doesn't create trouble ;)

A vector of non-const pointers is better in that regard?

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/8891a0f2/attachment.html>