--===============0792176004==
Content-Type: multipart/signed;
boundary="nextPart1645307.ZQgcLKoKst";
protocol="application/pgp-signature";
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1645307.ZQgcLKoKst
Content-Type: text/plain;
charset="iso-8859-1"
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 =

be
> 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 =
be=20
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=
n=20
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
http://doc.trolltech.com/4.1/qabstra...odel.html#sort
shouldn't need the extra weight of a QSortFilterProxyModel. And if not the=
=20
developer can always add a QSortFilterProxyModel between the model and the=
=20
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=
del=20
and any view (Many apps will use a table view). I can not think of a reaso=
n=20
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=

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

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

to
> 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=
n=20
the style. visualRect() should already return the correct results (and if=
=20
not it is a bug).=20
http://doc.trolltech.com/4.1/qabstra...tml#visualRect

setFullWidth() sounds like it does the same thing as qheaderview already do=
es=20
http://doc.trolltech.com/4.1/qheader...stSection-prop

setSorting() ->
http://doc.trolltech.com/4.1/qtreevi...l#sortByColumn

columnSorted() ->
http://doc.trolltech.com/4.1/qheader...dicatorSection

ascemdingSort() ->
http://doc.trolltech.com/4.1/qheader...IndicatorOrder

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

menuShortCutPressed <- When would this be used?

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

emitExecute should take a QModelIndex

activateAutomaticSelection() & friends. This doesn't belong in kdelibs. T=
his=20
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=
l=20
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=
e=20
qt equivalent, but sense most apps have to be re-worked anyway maybe just=20
documenting it will be good enough?

=2DBenjamin Meyer

=2D-=20
aka icefox
Public Key: http://www.icefox.net/public_key.asc

--nextPart1645307.ZQgcLKoKst
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEJZJ51rZ3LTw38vIRAqGOAKCtBgFUIBKXLcsQUDSZQZ AfpQxHvACfQCWB
ys7X4Vh2Jdg1J9rQqHptU8c=
=S1g0
-----END PGP SIGNATURE-----

--nextPart1645307.ZQgcLKoKst--

--===============0792176004==
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 <<


--===============0792176004==--