[Patch] Sort by time of modification in iconview + multicolumsnview

[Anna Nymos]

On Friday 14 February 2003 02:18, Carsten Pfeiffer wrote:
> The string is simply the filename or whatever else one might want to use.

I do understand this.

> > file is a directory(second argument) and to OR together QDir::IgnoreCase,
> > QDir::Reversed(doesn't even affect the resulting QString) and
> > QDir::DirsFirst if they apply(third argument). So I can't see what this
>
> Whether it's a file or directory should be known already (see
> KFileItem::isDir()). The other arguments do affect the resulting QString
> (otherwise they would not be there).

I tried some arguments but didn't look at the sources, so I didn't see the 
effects of Reversed - my fault.

> Or do you prefer everything being sorted strictly by modification time?
> Directories and files all mixed together? I don't think we want that.

The separation between files and directories is done elsewhere (though I don't 
know where) and doesn't need to be done in the sorting key, I think. Same for 
taking care of case or not.
The difference I see is, that directories are put at the end of the list if 
dirsFirst and Reversed are ORed together. I'm not sure if this is wanted.

> See the implementation:
>[code]

Now looked at it.

> All three parameters together form the sort criterion. QDir::Name, Time and
> Size are not useful here, because they only refer to a value out of several
> (i.e. "sort by name and not by time or size"). We don't need that, as we
> just pass the value we want to sort by as first parameter (i.e. the name,
> or date or size (using the overloaded sortingKey() method for the latter)).

I first (before my last mail) thought one could centralize the creation of 
sorting keys in KfileView::SortingKey(). But because this function has only 
access to the criterion, not the file, this is senseless. I then (after last  
mail) imagined some function like that:
QString KFileView::sortingKey(int criterion, QIconViewItem item , int
 sortSpec )
 {
    QString key;
    switch (criterion)
    {
     case Time: key=<insert here what is now done in konq_iconview.cc>
     case Name: key=...
    }
//This is done somewhere else
//     bool reverse   = sortSpec & QDir::Reversed;
//     bool dirsFirst = sortSpec & QDir::DirsFirst;
//     char start = ( (KFileIVI)(item).key().isDir() && dirsFirst) ? (reverse 
? '2' : '0') : '1';
//     QString result = (sortSpec & QDir::IgnoreCase) ? key.lower() : key;
//     return result.prepend( start );
    return key;
 }
But now I noticed that the Q*ViewItem classes don't have a common base class 
to use as second argument (in fact they have one: Qt) and that's why it is 
better to keep it how it is now (because key-creation can't be centralized, 
only moved). Sorry for the bit confusing way of expression and first not 
deeply thinking about this.

In hope to have understand it now
  Anna
__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Bis zu 100 MB Speicher bei http://premiummail.yahoo.de