Make Dolphin's SortFilterProxyModel for KDirModel public

Nick Shaforostoff shafff at ukr.net
Fri Jul 20 15:27:07 BST 2007


On Пятница 20 июля 2007, Rafael Fernández López wrote:
> PLEASE on the SVN rules there is clearly said: Do not make changes you dont
> understand. Therefore:
> 
> +#if 0 //didnt get what's the purpose of the function...
> +bool KDirSortFilterProxyModel::lessThanGeneralPurpose(const QModelIndex
> &left,
> +                                                         const QModelIndex
> &right) const
As you can see, i have removed this function from  (or just didn't move to) _KDirSortFilterProxyModel_ (class going to kdelibs).
BUT I have left it in DolphinSortFilterProxyModel.
SO to the users of DolphinSortFilterProxyModel _nothing_ is changed.

I dont have to understand lessThanGeneralPurpose() function as I did nothing with it.

maybe i had to use 'Separate general KDirModel stuff from Dolphin's SortFilterProxyModel into kdelibs' title
instead of 'Make Dolphin's SortFilterProxyModel for KDirModel public'

> So, this method is ESSENTIAL on the categorized view. We could either do
> this or add another method that sets a QSortFilterProxyModel for the
> categorized view apart from the model itself. The main reason is that the
> lessThanGeneralPurpose method will do a "basic" sorting, just for finding
> out categories, and their order. Then over those elements DISORDERED on
> categories, the lessThan method will be applied for each category. That is
> because we can't just apply the same sorting for those two different tasks.

Thanks, I'll put this explanation into dolphinsortfilterproxymodel.h for future contributors

So, in dolphin, view first calls lessThanGeneralPurpose(), then usual lessThan() is called.
And if we dont have categories (eg in filedialog) then we just use lessThan(). right?

If so, then i propose to change the name of lessThanGeneralPurpose() to
lessThanMetaPurpose() or lessThanPresort() or lessThanDivideIntoCategories() to avoid confusion
 
> Basically, if you commit your changes (or if they are already committed),
> KCategorizedView is broken.
> 
> I don't think is the best moment to push this kind of changes to kdelibs
> right now, since we said it is pretty frozen. And this kind of changes (as
> well as KCategorizedView moving to kdelibs) were dated for 4.1 at least. So
> please, don't push this kind of changes to kdelibs.
> 
> Bye and thanks,
> Rafael Fernández López.
> 




More information about the kde-core-devel mailing list