Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#9402 closed Patch (fixed)

Support customizable sort mode

Reported by: Francois Ferrand Owned by:
Priority: normal Component: FileZilla Client
Keywords: Cc:
Component version: Operating system type:
Operating system version:

Description

Add support case sensitive, case insensitive and natural sort modes.
The mode is used in file list view as well as directory list view.

The patch also includes the UI and settings changes and unit tests.

Attachments (3)

0001-Support-sensitive-insensitive-and-natural-name-sort.patch (49.1 KB) - added by Francois Ferrand 6 years ago.
0001-Support-sensitive-insensitive-and-natural-name-sort.2.patch (51.2 KB) - added by Francois Ferrand 5 years ago.
patch v2
0001-Support-sensitive-insensitive-and-natural-name-sort.3.patch (51.0 KB) - added by Francois Ferrand 5 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 5 years ago by Tim Kosse

Status: newmoreinfo

A couple of issues, ordered by severity:

  • Windows is case-sensitive, other platforms are case-insensitive. Hence the default value of the option should reflect the case-sensitivity of the operating system.
  • You're using Toupper, whereas wx' CmpNoCase uses Tolower. To make things symmetric, please use Tolower as well. Otherwise strings without numbers might be sorted differently in natural sort than in case-insensitive sort, leading to confusion.
  • wxChar may be defined as wchar_t, signedness of wchar_t is unspecified by the C(++) standard. Before taking the difference of the two chars, cast them both to a signed type of sufficient size (e.g. int)

Could you please address these issues?

Changed 5 years ago by Francois Ferrand

patch v2

comment:2 Changed 5 years ago by Francois Ferrand

Status: moreinfonew

Natural sort from http://sourcefrog.net/projects/natsort/ has some strange behavior as well: it produces 010 < 02, as part of its behavior of not ignoring leading zeros, which tends to give more reasonable results on decimal fractions (e.g. it produces 0.010 < 0.02).

Ignoring fractions seems more reasonable for file names, since we probably do not have fractions in file names, except for version numbers which should be sorted 'normally'.

Thus I just fixed my earlier implementation, to fix the 25 < 021 issue, and added the test cases from http://sourcefrog.net/projects/natsort/, except for the two cases '1.010' < '02' and '1.02' < '1.1' (which would break '010' > '02' and '02' > '1', respectively).

Other issues taken into account as well.

comment:3 Changed 5 years ago by Tim Kosse

Status: newmoreinfo

Version numbers usually don't have leading zeroes in each segment. FileZilla 3.008.001 would just be bizarre ;)

Two issues still:

The choice on some platforms still has the wrong item sufficed with " (default)". I'd solve it using platform attributes in the XRC file: http://docs.wxwidgets.org/trunk/overview_xrcformat.html#overview_xrcformat_platform

Inconsistent indentation in the patch. FileZilla uses tabs for indentation.

comment:4 Changed 5 years ago by Francois Ferrand

Status: moreinfonew

Should be OK now.

comment:5 Changed 5 years ago by Tim Kosse

Resolution: fixed
Status: newclosed

Thanks, I've applied and committed your patch. Keep up the good work.

comment:6 Changed 5 years ago by Tim Kosse

Small follow-up: I've refactored the sorting code to greatly reduce code duplication.

Note: See TracTickets for help on using tickets.