Centralize tree-filter class?

[John Tapsell]

Sorting by child added only 2 lines of code (to call sort recursively)
compared to the 20 lines of other specific code in there.  I don't see
the point :)

What _is_ really needed in an equivalent for KSearchLine for kde4.
Just a text box with the "search:" label and the  |x>  button.  It
should just emit a signal when changed.

John

On 10/07/06, Stephan Kulow <coolo at kde.org> wrote:
> Am Montag, 10. Juli 2006 21:23 schrieb Frans Englich:
> > Here and there, people need to sort & filter hierarchial item models, and
> > currently the wheel is reinvented for this. Known cases:
> >
> > * Recent thread "How to make QSortFilterProxyModel search through children
> > in a treeWidget?" on kde-devel
> > * kdebase/workspace/ksysguard(as mentioned by Tapsell)
> > * kdenonbeta/kdom/patternist/
> > * It often creeps up on qt-interest
> > * Others?
> >
> > This makes me consider if such functionality should be centralized. The
> > code is small, but can be tricky to write(due to the complex contracts
> Qt's
> > classes have in this area). The documentation for one such class is here:
> >
> >
> http://patternist.sourceforge.net/documentation/API/classKXQTS_1_1TreeSortF
> >ilter.html
> >
> > Should something like this be put centrally? Alternatives:
> >
> > A: Nope, it should not.
> > B: One flirts with the trolls to get such functionality included in Qt 4.3
> > C: One puts KTreeSortFilter in kdegui
> >
> > Currently, my preference is B. I have no particularly strong opinion about
> > this, but perhaps others can give direction.
> >
>
> I don't think such a class has to be centralized as the application specific
> demands usually outweight the common base. So putting such a class on some
> webpage and a reference to patternist would suffice. Unfortunately all tries
> to come up with such a "solution base" always suffered from outdating too
> quickly ;(
>
> Greetings, Stephan
>