[mythtv] Ticket #1678: mythvideo sorting is case-sensitive

Michael T. Dean mtdean at thirdcontact.com
Fri Apr 21 01:23:36 UTC 2006


On 04/20/2006 08:19 PM, MythTV wrote:

>#1678: mythvideo sorting is case-sensitive
>
>Comment (by gnassas at mac.com):
>
> Some observations on this patch and ticket.
>
> First, respecting case during sorting is desirable behaviour. If a change
> must be made it should be to respect case everywhere.
>  
>
Which is exactly opposite the behavior requested by the reporter.  The 
reporter's requested behavior is probably what you want, too--you just 
don't know it.

The current sorting implementation uses Unicode-betical sorting.  So, it 
sorts based on Unicode value of the character.  This is /definitely/ not 
desired behavior.

The patch I wrote changes the sorting implementation to use a 
locale-aware sort.  This would allow users in locales like 
Germany--which has a "u" with an umlaut--to sort videos such that those 
with a "u" with an umlaut (and all the other special characters) sort 
appropriately.

The locale-aware sort uses the locale's LC_COLLATE collation order to 
determine the proper order for the sort.  In some locales, LC_COLLATE 
gives an order such as "AaBbCc", etc.  However, other locales--including 
en_US.iso88591 and quite possibly en_US.UTF-8 and ...--use "ABC...abc".  
I think the "case-sensitive" order you want is the first; however, the 
one you'll get is likely the second (depending on LC_COLLATE).

At least to the reporter of this issue, the second sort order did not 
seem correct (and I would agree with the reporter that it's not 
intuitive).  With it, you get a sort like:

SG
SW 2.5
SWAT
Scary Movie
Second Sight
She's All That
Spawn
Stargate
Swim Fan

So, do you still want "case sensitive" sorting everywhere?  It didn't 
seem to be what I would consider the most-user-friendly sort order, so I 
made the sort case-insensitive.

> Second, the sorting order is different because video manager uses sql
> sorting and the other views use a map. This patch doesn't touch the sql
> sort so as long as there are two ordering techniques there will be
> mismatched lists. Presumably that's the original poster's real complaint.
>  
>
I seriously doubt the reporter is going to remember in which order the 5 
videos with the exact same title appear in both lists.  However, if we 
want those sort orders to be identical, we just need to change the SQL 
query to use "ORDER BY title, filename, intid" if the list uses the sort 
in this patch.

> Third, in #1569 I have to do some key manipulation to get folder view to
> work. The code reorg introduced here makes it complicated to apply that
> patch. I ask that the earlier ticket be applied first.
>
> I like the idea of the sorting class so I'm going to poach it for #1569.
> If this ticket were to be deemed still be necessary after that it should
> focus on harmonizing the scan for videos between video manager and the
> other views.
>  
>

I still believe that the answer to getting #1569 into trunk is not to 
add more and more stuff to it, but to break it apart into small, 
easily-verifiable patches that each change one behavior--making it 
easier understand the changes (and less dangerous to commit).  Yes, this 
might mean you have to write a patch, see it through the system, then 
write another patch that builds on the previous, see it through the 
system, and ...  But, the more time /you/ can save for the developers, 
the more time /they/ can spend making Myth better for all of us.

Anyway, that's just my opinion.  Ask Anduin what he prefers an opinion 
that matters.

Mike



More information about the mythtv-dev mailing list