Content-Type: multipart/signed;
Content-Transfer-Encoding: 7bit

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 15 March 2006 5:33 pm, Sebastian Gottfried wrote:
> Hi all,
> After being a happy KDE user for a long time I thought now is the right
> time to pay something back
> In a recent thread Micha=EBl Larouche mentioned KListView still needs to =

> ported, so here comes my proposal for the new KlistView. First, I
> think, it's wise to rename the class to KTreeView, because the new base
> class will be QTreeView.
> By using the model/view concept it should be possible to move the most
> features of the old KListView into the models:

Many of the features could really be in a custom delegate where they could =
used in any view or widget

> - the table headers and all the data editing features are now provided by
> the model automatically. A feature I could imagine is column selecting by
> the user like in firefox.

I am not sure what you mean. Are you talking about how in a table view whe=
you click on a header it selects the row/column? QTableView does do this.

> - for the column sorting the class should hold a own private
> QSortFilterProxyModel (or a derived class) as a private member for
> reasonable sorting, e.g. sorting number as numbers, not as strings

A models that implements=20
shouldn't need the extra weight of a QSortFilterProxyModel. And if not the=
developer can always add a QSortFilterProxyModel between the model and the=
view and turn on sorting in the view.

> - drag and drop support is also complete, but a little a bit complicated.
> The model can specify which items are dragable and/or dropable. The view
> only have to specify if dropping and/or dragging is this view generally is
> allowed

This will be a little less complicated in 4.2.

> - the search line widget could be easily incorporated, it must only take
> the original model and expose the filtered model to KTreeView.

It would be much preferred if the search line widget could work with any mo=
and any view (Many apps will use a table view). I can not think of a reaso=
why our generic search widget should be tied to one view or model.

> Questions:
> What about FileManager selection mode. Is this really necessary? Or can t=

> defined keyboard strokes generally accessible (if the selection mode allo=

> it).
> I have attached my first version of the class interface and I would like =

> implement it after some discussion if no one objects.
> Sebastian Gottfried

Here are a few comments on the header.

isExecuteArea(), isExecuteArea(), and depthToPixels() - something that is i=
the style. visualRect() should already return the correct results (and if=
not it is a bug).=20

setFullWidth() sounds like it does the same thing as qheaderview already do=

setSorting() ->

columnSorted() ->

ascemdingSort() ->

setShadeSortColumn() should be in a delegate that anyone can use

menuShortCutPressed <- When would this be used?

I see there are 5 apps in kde that use this function according to lxr. Qt's=
doesn't have this, perhaps we should request it as a wish item? It is a ni=
convenience feature which you can easily do manually.=20

emitExecute should take a QModelIndex

activateAutomaticSelection() & friends. This doesn't belong in kdelibs. T=
is an application specific functionality not a general feature. The file=20
manager can create a subclass (if even needed) for this feature (without al=
the extra functions too).

virtual_hook() - Need to double check with the core archives, but I don't=20
think we are using these in QObject subclasses in KDE4.

=46un, once you remove the above there isn't much work for you to do =20
There might be value in making inline KDE_DEPRECATED functions that call th=
qt equivalent, but sense most apps have to be re-worked anyway maybe just=20
documenting it will be good enough?

=2DBenjamin Meyer

aka icefox
Public Key: http://www.icefox.net/public_key.asc

Content-Type: application/pgp-signature

Version: GnuPG v1.4.2.2 (GNU/Linux)



Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<