[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Centralize tree-filter class?
From:       "John Tapsell" <johnflux () gmail ! com>
Date:       2006-07-12 22:14:40
Message-ID: 43d8ce650607121514r1c7569faxb1a434a0dc086d33 () mail ! gmail ! com
[Download RAW message or body]

And chosing whether it's the |x>   or <x|   button and putting it on
the left or right, and so on.

It's complicated enough to warrant a class.

On 13/07/06, Benjamin Meyer <ben@meyerhome.net> wrote:
> On Monday 10 July 2006 10:27 pm, John Tapsell wrote:
> > 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.
>
> When using a model and sort filter proxy model to create KSearchLine is little
> more then just connecting the label's text changed singal to the proxy's set
> text slot.  Hardly worth having a whole class in kdelibs.  When using the
> convenience views (QTableWidget, QTreeWidget and QListWidget) they can't take
> a QSortFilterProxyModel so you are forced to either remove items or hide them
> when filtering which can either be ugly of really slow and class to deal with
> it might be handy.  The main advantage of those classes is their convenience
> API, but in 4.2 QStandardItemModel has a good convenience API and I would
> highly recommend using it (or your own model) over the tree and list widgets.
>
> -Benjamin Meyer
>
> --
> aka icefox
> Public Key: http://www.icefox.net/public_key.asc
>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]