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

List:       kde-devel
Subject:    Re: [PROPOSAL] New KListView
From:       Benjamin Meyer <ben () meyerhome ! net>
Date:       2006-03-25 17:57:36
Message-ID: 200603251956.57487.ben () meyerhome ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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ël 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 
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 when 
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 
http://doc.trolltech.com/4.1/qabstractitemmodel.html#sort
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 model 
and any view (Many apps will use a table view).  I can not think of a reason 
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 the
> defined keyboard strokes generally accessible (if the selection mode allows
> 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 in 
the style.  visualRect() should already return the correct results (and if 
not it is a bug). 
http://doc.trolltech.com/4.1/qabstractitemview.html#visualRect

setFullWidth() sounds like it does the same thing as qheaderview already does 
http://doc.trolltech.com/4.1/qheaderview.html#stretchLastSection-prop

setSorting() ->
http://doc.trolltech.com/4.1/qtreeview.html#sortByColumn

columnSorted() ->
http://doc.trolltech.com/4.1/qheaderview.html#sortIndicatorSection

ascemdingSort() ->
http://doc.trolltech.com/4.1/qheaderview.html#sortIndicatorOrder

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 
doesn't have this, perhaps we should request it as a wish item?  It is a nice 
convenience feature which you can easily do manually. 

emitExecute should take a QModelIndex

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

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

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

-Benjamin Meyer

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

[Attachment #5 (application/pgp-signature)]

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


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