D21249: Test current filter before setting a new one

Jan-Marek Glogowski noreply at phabricator.kde.org
Sun May 19 13:01:05 BST 2019


jglogowski marked an inline comment as done.
jglogowski added inline comments.

INLINE COMMENTS

> elvisangelaccio wrote in kfilewidget.cpp:132
> Nitpick: I'd make `filter` the first parameter. And we usually don't use `const boll` in signatures, but just `bool`.
> 
> `bUpdate` doesn't tell the reader what this variable is used for. How about calling it `updateCurrentFilter` or similar?

Kind of Done.

> dfaure wrote in kfilewidget.cpp:2463
> Is the bUpdate bool necessary?
> 
> Without it, we'd call setCurrentFilter(currentFilter()) which should be a no-op, right?
> 
> Alternatively, the method could return a QString, and the (second) caller could call setCurrentFilter.
> 
> I just don't like a method that's sometimes a getter and sometimes a setter (basically).

> Is the bUpdate bool necessary?



  void KFileFilterCombo::setCurrentFilter(const QString &filter)
  {
      setCurrentIndex(d->m_filters.indexOf(filter));
      emit filterChanged();
  }

filterChanged will unconditionally start the "cycle", which will set the wrong filter.
Wanted to keep my changes more local.

> Alternatively, the method could return a QString, and the (second) caller could call setCurrentFilter.
>  I just don't like a method that's sometimes a getter and sometimes a setter (basically).

Also had that. It "felt" strange, but I don't care much.

REPOSITORY
  R241 KIO

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

To: jglogowski, #frameworks, ngraham, dfaure
Cc: elvisangelaccio, ngraham, michaelweghorn, kde-frameworks-devel, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190519/8763b7b7/attachment.html>


More information about the Kde-frameworks-devel mailing list