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

List:       kde-core-devel
Subject:    Re: Review Request: Add global option to turn off "natural sorting"
From:       Peter Penz <peter.penz () gmx ! at>
Date:       2009-08-18 20:58:26
Message-ID: 200908182258.26555.peter.penz () gmx ! at
[Download RAW message or body]

On Tuesday, 18. August 2009 18:03:41 Matthew Woehlke wrote:
> Peter Penz wrote:
> > On Tuesday, 18. August 2009 01:48:27 Matthew Woehlke wrote:
> >> Peter Penz wrote:
> >>> I'm really against a per-directory option, as this hexadezimal-example
> >>> is a corner case for a small group of users which does not justify a
> >>> user visible UI option "[x] Natural Compare" inside a top-level-menu
> >>> IMO.
> >>
> >> I'd be fine with a hidden option... from your argument, the people that
> >> would need it are most likely to be comfortable dealing with such an
> >> option.
> >
> > But in your case "hidden option" would mean that you want adjust your
> > ".directory" file manually.
>
> Correct.
>
> > This would not work with the file dialog, as it ignores the
> > .directory files...
>
> Hmm... well I guess that would need to change :-).

I don't think this is realistic. I've checked bugs.kde.org and could not find 
a single report which wants the file dialog to respect the .directory 
settings. The current behavior is there since KDE 1.0 and I think using your 
corner case to change it is - well - not really an obvious trigger ;-)

> > If I don't miss a thing, the problem in the file-dialog can only be
> > solved by: - a global option (= my suggestion in the reviewboard)
>
> ...but a global option means I lose natural sorting where it makes sense
>
> :-(.
> :
> > I'd be interested into more details of your usecase:
> >
> > - How often do you need to select a file in Dolphin or the file-dialog
> > that is named in hexadezimal way?
>
> When I am working on a project that deals with the base-36 dirnames, it
> can be pretty common... though I don't often work on such projects.

The background of my question was whether this usecase might be valid for 
other KDE users out there too. From your answer it seems that even for you 
this workflow is a corner case.

It is not possible to optimize the user interface for all usecases perfectly. 
The important thing is to know your target user group and optimize the 
userinterface for their workflow.

I don't have any numbers, but I doubt there are a lot of people out there who 
know what base-36 is and even less people that need to work with those files 
in their daily workflow. And even if they work with the files, it might not be 
that important that the ordering is unicode based... If someone searches a 
definition for a corner case, then I think this would be a good candidate ;-)

So if I tell the reporters from https://bugs.kde.org/show_bug.cgi?id=169883 
that they need to adjust their .directory files manually to turn off the 
natural sorting, then I know for sure that this is no acceptable solution for 
their problem (BTW: there are users that prefer a global view setting instead 
of remembering it per directory [Dolphin Settings -> General -> Behavior -> 
(x) Use common view properties for all folders]).

The more we discuss about remembering this setting per directory level, the 
more I think it brings more problems than it solves. After reading again 
https://bugs.kde.org/show_bug.cgi?id=169883 and related reports, the wish is 
quite clear: Some people don't like natural sorting because they named their 
directories and files by rules where natural sorting was not standard and they 
simply want to turn it off on a global level (-> in the file dialog, 
Konqueror, Dolphin and all applications that use KDirSortFilterProxyModel).

>
> > - Is the number of named hexadecimal files really so large that you lose
> > a lot of time in your daily workflow?
>
> Probably not a lot of time, it's just that it's a rough edge.
>
> > Taking the file dialog as example: If you'd
> > have a user visible configuration "[x] Natural Sorting" you'd need to
> > disable this setting each time you enter such a directory and would need
> > to enable it again each time before you leave it :-(
>
> Right, which is why it needs to be per-directory.
>
> I've been trying to think of a better heuristic, but I don't know that
> it is possible to know how "12" and "1a" should be ordered without user
> input. (Also a "good" heuristic needs to consider the list as a whole,
> which I suspect is expensive.)

Beside being expensive from a performance point of view, it is just impossible 
to find a heuristic that works. How will you sort this?
a1gf.txt
a12f.txt
b1fg.txt
best12.txt
readme.txt

You cannot know whether "a1fg.txt" is a hexadezimal filename or just a 
shortcut for "Appendix 1 Graphics Framework.txt"....

>
> > - Wouldn't it be faster anyhow that you use the filter functionality
> > (Strg+I) from Dolphin or the filename-combo in the file-dialog?
>
> Right now the most practical solution is to remember to type everything.
> In my experience, that's still disruptive though, as my inclination is
> to use the list first. (IOW the disruption is having to remember to do
> something different, so filtering wouldn't help, the cost has already
> been incurred by the time I would think to use filtering.)
[prev in list] [next in list] [prev in thread] [next in thread]