This is a discussion on Re: [PROPOSAL] New KListView - KDE ; --===============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 ...
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
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.
> What about FileManager selection mode. Is this really necessary? Or can t=
> defined keyboard strokes generally accessible (if the selection mode allo=
> 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=
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?
Public Key: http://www.icefox.net/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v126.96.36.199 (GNU/Linux)
-----END PGP SIGNATURE-----
Content-Type: text/plain; charset="us-ascii"
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<