Re: Licenses of bundled themes
Jonas Häggqvist wrote: As a followup to the earlier discussion about themes, do we want to relicense all the currently bundled themes as CC-BY-SA 3.0? If there's no good argument not to, I'll go ahead and attempt to contact the authors soon. As a bonus question, do we also want to move the themes (except cabbiev2) unto the theme site (which is hopefully now closer to returning than ever) and stop bundling them? In my opinion, yes to both. Relicense, and remove from builds (once the theme site works).
Licenses of bundled themes
As a followup to the earlier discussion about themes, do we want to relicense all the currently bundled themes as CC-BY-SA 3.0? If there's no good argument not to, I'll go ahead and attempt to contact the authors soon. As a bonus question, do we also want to move the themes (except cabbiev2) unto the theme site (which is hopefully now closer to returning than ever) and stop bundling them? -- Jonas Häggqvist rasher(at)rasher(dot)dk
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: Alternatively we can also think about ignoring chars like . and _ (and possibly more) in the beginning of a file name (e.g. .rockbox is sorted under r). Just an idea. It doesn't really add complexity, but would definitely do more than the setting advertises. But, this is also something windows/nautilus/more do. Huh? Windows Explorer at least *does not* ignore "_" and does not sort "_something" among the "s" but puts it at the top before "a", even before numbers. The ".rockbox" folder is also sorted above the "Music" folder in my "simdisk" directory... It also respects number of spaces and *does not* collapse it to one. Resulting order in a small test: ! Test ! A If it would ignore the second space it would sort "! Test" last. In reply to an earlier mail here, I am one who occasionally (ab)uses this function of sorting to put temporary data at the top, somwhere outside the rest of the list. This is not specific to Rockbox because I don't use it for my music collection but for other files on my computer. I like the described way for file/directory names starting with special characters and think they should be treated like this in Rockbox, too (as they are currently?). And as you said yourself, adding this will do more than "advertised"; the same thing applies to spaces as well (as Dominik pointed out), so the setting either has a wrong name or should be fixed in this regard. My preference would also be to treat leading zeros as intentional, just looking at a list in explorer, "01, 02, 3, 04" seemed weird to me - guess it's the same effect Paul described and reported about his friends. About the mathematical rule: that's true without a doubt but if I read "04 + 03 = 07", I would suspect some weird reasoning behind (something intentional that I only don't know about). One just doesn't write a leading zero if (s)he doesn't have to. To summarise: first a strong wish that more than one space is treated as such and no ignoring of even more "special" chars - also to comply with the setting name. Perhaps don't ignore leading zeros, although I could understand the reason "all major file browsers do, so should we"; so far I found Paul's example in favour of not ignoring them more realistic though. Regards, Marianne.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Al Le wrote: Paul, I think we can agree that there are different cases. There are cases where a leading zero is intentional and there are cases where it's just there (because you used a wrong setting in the ripping software or because you copied the file from somewhere else). The problem is that a single "natural" sort won't fit all. Maybe we should have two natural sort procedures? One would ignore the leading zeroes, i.e. just consider numbers as in mathematics (it would put "007" after "6") and the other wouldn't (it would put "007" before "6"). Neither of your described cases would result in a mix of leading zeros and no leading zeros though. If you set the wrong setting, all your files would have leading zeros and still sort fine. So what's the problem? This is what I don't get - nobody's described a real case where acknowledging leading zeros causes a *bad* sort except the one "mix folder" case where the user chooses to rename some, but not all, of his files.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
On 19.03.2009 00:13, Paul Louden wrote: Al Le wrote: > My personal position is also that if a user adds a 0 before a number, they expect it to change something, rather than being ignored. I think, on average, more 0s (in lists meant to be sorted) will be intentional than "accidental." Paul, I think we can agree that there are different cases. There are cases where a leading zero is intentional and there are cases where it's just there (because you used a wrong setting in the ripping software or because you copied the file from somewhere else). The problem is that a single "natural" sort won't fit all. Maybe we should have two natural sort procedures? One would ignore the leading zeroes, i.e. just consider numbers as in mathematics (it would put "007" after "6") and the other wouldn't (it would put "007" before "6"). The major file browsers (since produced by a techies :-) operate on just numbers, without special treatment of the leading zeroes.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: Thomas Martitz wrote: I've uploaded the patch to FS#10030. Any final comments? If not, I consider to commit it before release. I'm not sure whether it should be backported too, though. Please also read the recent comments on the task. In my opinion, we should disable the option and revert to basic ASCII sort for this release, and make "natural" sorting a feature of the next one. We shouldn't change the "default" sort method in a release version until we have a more or less final algorithm, and it certainly seems like even outside of my own objections, there's still several opinions on how this should go. People have got by with ASCII before, they can wait with it 3 more months (or use current builds) until we've settled our algorithm issue.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: I've uploaded the patch to FS#10030. Any final comments? If not, I consider to commit it before release. I'm not sure whether it should be backported too, though. Please also read the recent comments on the task.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
On Thu, Mar 19, 2009 at 6:47 PM, Thomas Martitz wrote: > The problem with his proposal was, that it looked 3 times at every char. > That's hardly optimal. Which doesn't imply that it can't be done better. An inefficient solution is therefore no reasoning against fixing a feature. > And I think that a file-listing is relatively timing critical. I wouldn't > want to have noticeably delay just due to sorting on each folder I enter. Then you need to define what time-critical means. For me, this is interrupting some real-time process (playback, communication with a chip on a bus, data corruption etc). A file browser should be fast, but it's definitely not time-critical -- nothing bad will happen if it takes slightly longer. Except maybe the user getting annoyed. But I'd rather call that time-relevant. It's not critical. - Dominik
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
codemonkey wrote: > Are you guys aware that there's a quasi-standard regarding this in > the GNU libraries? See the following excerpt from Fedora "info ls" > and "man strverscmp". > > ~ray > > PS: I've found that "ls -v" works well for sorting MP3s with track > numbering, etc. I don't know if it handles all of the cases described in > this thread though. Maybe GNU's implementation is worth borrowing for > rockbox? > > -- > > $ info ls > > (...excerpt...) > > 10.1.4 More details about version sort > -- > > The version sort takes into account the fact that file names frequently > include indices or version numbers. Standard sorting functions usually > do not produce the ordering that people expect because comparisons are > made on a character-by-character basis. The version sort addresses > this problem, and is especially useful when browsing directories that > contain many files with indices/version numbers in their names: > > $ ls -1$ ls -1v > foo.zml-1.gz foo.zml-1.gz > foo.zml-100.gz foo.zml-2.gz > foo.zml-12.gz foo.zml-6.gz > foo.zml-13.gz foo.zml-12.gz > foo.zml-2.gz foo.zml-13.gz > foo.zml-25.gz foo.zml-25.gz > foo.zml-6.gz foo.zml-100.gz > >Note also that numeric parts with leading zeros are considered as > fractional one: > > $ ls -1$ ls -1v > abc-1.007.tgz abc-1.007.tgz > abc-1.012b.tgz abc-1.01a.tgz > abc-1.01a.tgz abc-1.012b.tgz > >This functionality is implemented using the `strverscmp' function. > > -- > > $ man strverscmp > > STRVERSCMP(3) Linux Programmer’s Manual > STRVERSCMP(3) > > NAME >strverscmp - compare two version strings > > SYNOPSIS >#define _GNU_SOURCE >#include > >int strverscmp(const char *s1, const char *s2); > > DESCRIPTION >Often one has files jan1, jan2, ..., jan9, jan10, ... and it > feels >wrong when ls(1) orders them jan1, jan10, ..., jan2, ..., jan9. In >order to rectify this, GNU introduced the -v option to ls(1), which > is >implemented using versionsort(3), which again uses strverscmp(). > >Thus, the task of strverscmp() is to compare two strings and > find >the "right" order, while strcmp(3) only finds the lexicographic > order. >This function does not use the locale category LC_COLLATE, so is > meant >mostly for situations where the strings are expected to be in > ASCII. > >What this function does is the following. If both strings are > equal, >return 0. Otherwise find the position between two bytes with the >property that before it both strings are equal, while directly after > it >there is a difference. Find the largest consecutive digit strings >containing (or starting at, or ending at) this position. If one or > both >of these is empty, then return what strcmp(3) would have returned >(numerical ordering of byte values). Otherwise, compare both digit >strings numerically, where digit strings with one or more leading > zeroes >are interpreted as if they have a decimal point in front (so that in >particular digit strings with more leading zeroes come before digit >strings with fewer leading zeroes). Thus, the ordering is 000, > 00, >01, 010, 09, 0, 1, 9, 10. > > RETURN VALUE >The strverscmp() function returns an integer less than, equal to, or >greater than zero if s1 is found, respectively, to be earlier than, >equal to, or later than s2. > > CONFORMING TO >This function is a GNU extension. > > SEE ALSO >rename(1), strcasecmp(3), strcmp(3), strcoll(3), > feature_test_macros(7) > > GNU 2001-12-19 > STRVERSCMP(3) > > Seems very close. My understanding is natural sort would interpret as: 000, 00, 0, 01, 1, 09, 9, 010, 10.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
codemonkey wrote: Are you guys aware that there's a quasi-standard regarding this in the GNU libraries? See the following excerpt from Fedora "info ls" and "man strverscmp". ~ray PS: I've found that "ls -v" works well for sorting MP3s with track numbering, etc. I don't know if it handles all of the cases described in this thread though. Maybe GNU's implementation is worth borrowing for rockbox? -- $ info ls (...excerpt...) 10.1.4 More details about version sort -- The version sort takes into account the fact that file names frequently include indices or version numbers. Standard sorting functions usually do not produce the ordering that people expect because comparisons are made on a character-by-character basis. The version sort addresses this problem, and is especially useful when browsing directories that contain many files with indices/version numbers in their names: $ ls -1$ ls -1v foo.zml-1.gz foo.zml-1.gz foo.zml-100.gz foo.zml-2.gz foo.zml-12.gz foo.zml-6.gz foo.zml-13.gz foo.zml-12.gz foo.zml-2.gz foo.zml-13.gz foo.zml-25.gz foo.zml-25.gz foo.zml-6.gz foo.zml-100.gz Note also that numeric parts with leading zeros are considered as fractional one: $ ls -1$ ls -1v abc-1.007.tgz abc-1.007.tgz abc-1.012b.tgz abc-1.01a.tgz abc-1.01a.tgz abc-1.012b.tgz This functionality is implemented using the `strverscmp' function. -- $ man strverscmp STRVERSCMP(3) Linux Programmer’s Manual STRVERSCMP(3) NAME strverscmp - compare two version strings SYNOPSIS #define _GNU_SOURCE #include int strverscmp(const char *s1, const char *s2); DESCRIPTION Often one has files jan1, jan2, ..., jan9, jan10, ... and it feels wrong when ls(1) orders them jan1, jan10, ..., jan2, ..., jan9. In order to rectify this, GNU introduced the -v option to ls(1), which is implemented using versionsort(3), which again uses strverscmp(). Thus, the task of strverscmp() is to compare two strings and find the "right" order, while strcmp(3) only finds the lexicographic order. This function does not use the locale category LC_COLLATE, so is meant mostly for situations where the strings are expected to be in ASCII. What this function does is the following. If both strings are equal, return 0. Otherwise find the position between two bytes with the property that before it both strings are equal, while directly after it there is a difference. Find the largest consecutive digit strings containing (or starting at, or ending at) this position. If one or both of these is empty, then return what strcmp(3) would have returned (numerical ordering of byte values). Otherwise, compare both digit strings numerically, where digit strings with one or more leading zeroes are interpreted as if they have a decimal point in front (so that in particular digit strings with more leading zeroes come before digit strings with fewer leading zeroes). Thus, the ordering is 000, 00, 01, 010, 09, 0, 1, 9, 10. RETURN VALUE The strverscmp() function returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be earlier than, equal to, or later than s2. CONFORMING TO This function is a GNU extension. SEE ALSO rename(1), strcasecmp(3), strcmp(3), strcoll(3), feature_test_macros(7) GNU 2001-12-19 STRVERSCMP(3) Sounds exactly like strnatcmp. It behaves the same for the two examples.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Are you guys aware that there's a quasi-standard regarding this in the GNU libraries? See the following excerpt from Fedora "info ls" and "man strverscmp". ~ray PS: I've found that "ls -v" works well for sorting MP3s with track numbering, etc. I don't know if it handles all of the cases described in this thread though. Maybe GNU's implementation is worth borrowing for rockbox? -- $ info ls (...excerpt...) 10.1.4 More details about version sort -- The version sort takes into account the fact that file names frequently include indices or version numbers. Standard sorting functions usually do not produce the ordering that people expect because comparisons are made on a character-by-character basis. The version sort addresses this problem, and is especially useful when browsing directories that contain many files with indices/version numbers in their names: $ ls -1$ ls -1v foo.zml-1.gz foo.zml-1.gz foo.zml-100.gz foo.zml-2.gz foo.zml-12.gz foo.zml-6.gz foo.zml-13.gz foo.zml-12.gz foo.zml-2.gz foo.zml-13.gz foo.zml-25.gz foo.zml-25.gz foo.zml-6.gz foo.zml-100.gz Note also that numeric parts with leading zeros are considered as fractional one: $ ls -1$ ls -1v abc-1.007.tgz abc-1.007.tgz abc-1.012b.tgz abc-1.01a.tgz abc-1.01a.tgz abc-1.012b.tgz This functionality is implemented using the `strverscmp' function. -- $ man strverscmp STRVERSCMP(3) Linux Programmer’s Manual STRVERSCMP(3) NAME strverscmp - compare two version strings SYNOPSIS #define _GNU_SOURCE #include int strverscmp(const char *s1, const char *s2); DESCRIPTION Often one has files jan1, jan2, ..., jan9, jan10, ... and it feels wrong when ls(1) orders them jan1, jan10, ..., jan2, ..., jan9. In order to rectify this, GNU introduced the -v option to ls(1), which is implemented using versionsort(3), which again uses strverscmp(). Thus, the task of strverscmp() is to compare two strings and find the "right" order, while strcmp(3) only finds the lexicographic order. This function does not use the locale category LC_COLLATE, so is meant mostly for situations where the strings are expected to be in ASCII. What this function does is the following. If both strings are equal, return 0. Otherwise find the position between two bytes with the property that before it both strings are equal, while directly after it there is a difference. Find the largest consecutive digit strings containing (or starting at, or ending at) this position. If one or both of these is empty, then return what strcmp(3) would have returned (numerical ordering of byte values). Otherwise, compare both digit strings numerically, where digit strings with one or more leading zeroes are interpreted as if they have a decimal point in front (so that in particular digit strings with more leading zeroes come before digit strings with fewer leading zeroes). Thus, the ordering is 000, 00, 01, 010, 09, 0, 1, 9, 10. RETURN VALUE The strverscmp() function returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be earlier than, equal to, or later than s2. CONFORMING TO This function is a GNU extension. SEE ALSO rename(1), strcasecmp(3), strcmp(3), strcoll(3), feature_test_macros(7) GNU 2001-12-19 STRVERSCMP(3)
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Dominik Riebeling wrote:
On Thu, Mar 19, 2009 at 4:04 PM, Thomas Martitz
wrote:
Now imagine this for every char in a string, and for every string in a file
list (with some 100 files). It's three-times (or even more) more complexity
than just.
while (is_zero(a))
a = next;
This "natural sorting" is more complex than ASCII sorting anyway. And
what's the added complexity by simply going back by one to get the
last 0? That's only an added check, and everything else only if you
hit a digit.
if(is_digit(a)) {
/* is_digit() had a hit */
while(is_zero(a))
a = next;
/* if current one is not a digit anymore we've just skipped the
value 0 and need to take that back to not remove that value */
if(!is_digit(a)) /* no need to check if there is a prev value --
we skipped at least one 0. If not we still have a digit. */
a = prev;
}
That's how did it now (see FS#10030).
We're on embedded, and thus slow systems. Your would surely work well on a
desktop app, but for mp3-players we need fast and small code. The gain has
to justify the code, and I don't think it does it in this example.
We're talking about high-level functionality here. There's nothing
timing-critical, and even on the Archos players I'm confident doing
this properly wouldn't cause a serious slowdown compared to the
current state, but feel free to measure it and present numbers. We can
play mp3 files at <45MHz (at least on coldfire, don't have all the
numbers at hand right now) which is much more calculating-intensive
than doing a few additional comparisons on a list of maybe some 100
files.
You're basically saying we shouldn't fix the functionality because
it's too expensive runtime-wise. If it's really too expensive to have
a functionality working properly (which I doubt) we shouldn't ship the
functionality at all.
- Dominik
The problem with his proposal was, that it looked 3 times at every char.
That's hardly optimal.
The original algorithm looks only once through each char. And the
version you proposed does it too (except in the case where it goes back
1 char). That's why it's not much more expensive than normal strcmp.
And I think that a file-listing is relatively timing critical. I
wouldn't want to have noticeably delay just due to sorting on each
folder I enter.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
On Thu, Mar 19, 2009 at 9:21 AM, Paul Louden wrote: > I've stated my position several times: I think we should decide whether we > want to mimic the file browsers or not. If we do, I think we should mimic > all their sorting quirks that we can, rather than suggest we're "like" them > but with our own choices as to where to go our own way. Well, I think we still have two options here: 1. completely mimic the file browser. In this case I agree with you that we should mimic all quirks the browser used as reference has. 2. only mimic the browser in regards of numbers (or any other subset). I think this is a viable alternative, though not all might agree. Doing it this way we're not "like" the reference browser but simply doing a (the most commonly noticed?) subset. If we chose to minic a browser completely we immediately come across the question of which browser to use as reference. I'm quite sure Explorer / Konqueror / Nautilus behave differently in regards of prefixes like space, dot and underscore. Which is a reason why I'd go for mimicing the part of this "natural sorting" that's common among them. - Dominik
Re: Default on or off
Linus Nielsen Feltzing wrote: >> I would vote for new features which change existing functionality to be >> disabled by default. Do we have a general policy on this? > > There is no written policy, but the general opinion among us developers > is that the defaults should be as "sensible" as possible for the > first-time user. I agree. As Paul said, when adding a setting, the default should be chosen using the following considerations: 1. Will changing the default behaviour help new and less technical users? If so, change it. 2. If not, keep the existing behaviour. The sorting change is a case of the first. -- Jonas Häggqvist rasher(at)rasher(dot)dk
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
On Thu, Mar 19, 2009 at 4:04 PM, Thomas Martitz
wrote:
> Now imagine this for every char in a string, and for every string in a file
> list (with some 100 files). It's three-times (or even more) more complexity
> than just.
> while (is_zero(a))
> a = next;
This "natural sorting" is more complex than ASCII sorting anyway. And
what's the added complexity by simply going back by one to get the
last 0? That's only an added check, and everything else only if you
hit a digit.
if(is_digit(a)) {
/* is_digit() had a hit */
while(is_zero(a))
a = next;
/* if current one is not a digit anymore we've just skipped the
value 0 and need to take that back to not remove that value */
if(!is_digit(a)) /* no need to check if there is a prev value --
we skipped at least one 0. If not we still have a digit. */
a = prev;
}
> We're on embedded, and thus slow systems. Your would surely work well on a
> desktop app, but for mp3-players we need fast and small code. The gain has
> to justify the code, and I don't think it does it in this example.
We're talking about high-level functionality here. There's nothing
timing-critical, and even on the Archos players I'm confident doing
this properly wouldn't cause a serious slowdown compared to the
current state, but feel free to measure it and present numbers. We can
play mp3 files at <45MHz (at least on coldfire, don't have all the
numbers at hand right now) which is much more calculating-intensive
than doing a few additional comparisons on a list of maybe some 100
files.
You're basically saying we shouldn't fix the functionality because
it's too expensive runtime-wise. If it's really too expensive to have
a functionality working properly (which I doubt) we shouldn't ship the
functionality at all.
- Dominik
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: Ok, I've implemented ignoring very leading zeros now, and fixed FS#10031, in my local repo. It could be committed, I think. It seems the consensus is reached. Alternatively we can also think about ignoring chars like . and _ (and possibly more) in the beginning of a file name (e.g. .rockbox is sorted under r). Just an idea. It doesn't really add complexity, but would definitely do more than the setting advertises. But, this is also something windows/nautilus/more do. I've uploaded the patch to FS#10030.
Re: Default on or off
Paul Louden wrote: > Linus Nielsen Feltzing wrote: >> >> Yes, I believe it should. I think the average user would appreciate if >> it by default sorted in the same way as most modern file browsers do, >> i.e natural sorting. >> > I agree here - Generally we shouldn't change existing functionality. But > in this case we added an option that is supposed to help _less_ > technical users. The kind of person who prefers the old sorting will > (theoretically) be the kind of person who will actually pay attention to > the changes before he updates (or check them as soon as he notices his > files sorting differently). We have a published changelog. Meanwhile if > we don't change the default, plenty of users will never know there's a > new sort and will continue filing bug reports against the ASCII sorting. Just to complete the circle here, I agree as well, now that the original branch of this thread has apparently reached consensus on exactly how the natural sorting should work, which now works for the corner case that I defined by my usage. -- Mike Holden http://www.by-ang.com - the place to shop for all manner of hand crafted items, including Jewellery, Greetings Cards and Gifts
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
On Thu, Mar 19, 2009 at 4:34 PM, Thomas Martitz wrote: >> I've found a simpler solution for this. Trying the code raises the >> following problem: >> >> 00 < 0b < 01 < 1 [...] > Nautilus has this problem too. I don't know what windows does in this case. I don't see any problem here. You just need to distinguish between strings and values on sorting: a. 00 -> value 0 b. 0b -> value 0, followed by string "b" c. 01 -> value 1 d. 1 -> value 1 so while the strcmp() is the tie-breaker between c. and d., sorting of a. and b. is also rather simple -- you sort by the leading numbers first. This makes a. and b. come before the others. Then, as a. and b. are a "starting with zero"-group you have to resort that again as there is a tie with the numbers. Thus b. comes after a. That's how ASCII-sorting would do it (and also how windows explorer does it). You can't simply sort by leading numbers and ignore that the string has other characters in it too. - Dominik
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Mike Holden wrote: Thomas Martitz wrote: Thomas Martitz wrote: I've found a simpler solution for this. Trying the code raises the following problem: 00 < 0b < 01 < 1 Zeros before except the final zeros are ignored, and the final zero before characters is not ignored. But the leading zeros of numbers are (so that 01 is 1). Obviously 0 sorts before 1. Nautilus has this problem too. I don't know what windows does in this case. I thought we'd already established that those 4 files are in the right order? Windows orders them as below, which is the same as above: 00 0b 01 1 I didn't establish anything, the mail about nautilus was sent before I received yours. But if Nautilus and Windows sort this way, (and we want to mimic it), then it's right, indeed.
Re: Default on or off
Linus Nielsen Feltzing wrote: Yes, I believe it should. I think the average user would appreciate if it by default sorted in the same way as most modern file browsers do, i.e natural sorting. I agree here - Generally we shouldn't change existing functionality. But in this case we added an option that is supposed to help _less_ technical users. The kind of person who prefers the old sorting will (theoretically) be the kind of person who will actually pay attention to the changes before he updates (or check them as soon as he notices his files sorting differently). We have a published changelog. Meanwhile if we don't change the default, plenty of users will never know there's a new sort and will continue filing bug reports against the ASCII sorting.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: > Thomas Martitz wrote: >> I've found a simpler solution for this. Trying the code raises the >> following problem: >> >> 00 < 0b < 01 < 1 >> >> Zeros before except the final zeros are ignored, and the final zero >> before characters is not ignored. But the leading zeros of numbers are >> (so that 01 is 1). Obviously 0 sorts before 1. > > > Nautilus has this problem too. I don't know what windows does in this > case. > I thought we'd already established that those 4 files are in the right order? Windows orders them as below, which is the same as above: 00 0b 01 1 -- Mike Holden http://www.by-ang.com - the place to shop for all manner of hand crafted items, including Jewellery, Greetings Cards and Gifts
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: I've found a simpler solution for this. Trying the code raises the following problem: 00 < 0b < 01 < 1 Zeros before except the final zeros are ignored, and the final zero before characters is not ignored. But the leading zeros of numbers are (so that 01 is 1). Obviously 0 sorts before 1. Nautilus has this problem too. I don't know what windows does in this case.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote:
> Bryan VanDyke wrote:
>> Thomas Martitz wrote:
>>
>>> Bryan VanDyke wrote:
>>>
Thomas Martitz wrote:
> Linus Nielsen Feltzing wrote:
>
>> Mike Holden wrote:
>>
>>> Maybe leading zeros should only be stripped if another digit follows
>>> them?
>>>
>>> I use names like 00RockFaves.m3u, 00ClassicRock.m3u for playlists
>>> that I
>>> have created (as opposed to original artist albums), and the leading
>>> zerozero is deliberately there to sort them at the top.
>>>
>> That's an interesting observation. I believe leading zeroes are
>> treated like whitespace in the current code, but in this case I think
>> that the final zero should be kept.
>>
>> Linus
>>
> That's not trivial, and adds complexity. You basically need to
> look at
> the current, the next, and one more for this, instead of just the
> current char.
>
>
Actually it not that bad.
Pseudo code:
get current
get next
while (current != null && next != null && current == '0' && next is a
number)
{
current = next
next = get next
}
>>> Now imagine this for every char in a string, and for every string in a
>>> file list (with some 100 files). It's three-times (or even more) more
>>> complexity than just.
>>> while (is_zero(a))
>>>a = next;
>>>
>>> We're on embedded, and thus slow systems. Your would surely work well on
>>> a desktop app, but for mp3-players we need fast and small code. The gain
>>> has to justify the code, and I don't think it does it in this example.
>>>
>>>
>>
>> What about something like this. Taking in consideration the isspace
>> function/comparison was removed? And isdigit is supposed to give nonzero
>> on nodigit values.
>>
>> /* skip over leading zeros */
>> while ('0' == ca && nat_isdigit(ca_next) )
>> {
>> ca = to_int(a[++ai]);
>> ca_next = to_int(a[ai+1]);
>> }
>>
>>
>>
> I've found a simpler solution for this. Trying the code raises the
> following problem:
>
> 00 < 0b < 01 < 1
That look right. Zero is a valid number. A leading zero before a zero is
still zero.
00 -> 0
0b -> 0b
01 -> 1
1 -> 1
01 == 1
strcmp -> 01 < 1
right?
>
> Zeros before except the final zeros are ignored, and the final zero
> before characters is not ignored. But the leading zeros of numbers are
> (so that 01 is 1). Obviously 0 sorts before 1.
>
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: > Sounds to me that you're better off using ascii sort. Well that is what I currently use, but there's no reason why natural sorting shouldn't be appropriate if it works in the right way! > Windows does it in the same way as nautilus and other major file > browsers. It ignores leading zeros. Well it doesn't completely ignore them, they have some significance (see my other email a short while ago). -- Mike Holden http://www.by-ang.com - the place to shop for all manner of hand crafted items, including Jewellery, Greetings Cards and Gifts
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Bryan VanDyke wrote:
Thomas Martitz wrote:
Bryan VanDyke wrote:
Thomas Martitz wrote:
Linus Nielsen Feltzing wrote:
Mike Holden wrote:
Maybe leading zeros should only be stripped if another digit follows
them?
I use names like 00RockFaves.m3u, 00ClassicRock.m3u for playlists
that I
have created (as opposed to original artist albums), and the leading
zerozero is deliberately there to sort them at the top.
That's an interesting observation. I believe leading zeroes are
treated like whitespace in the current code, but in this case I think
that the final zero should be kept.
Linus
That's not trivial, and adds complexity. You basically need to look at
the current, the next, and one more for this, instead of just the
current char.
Actually it not that bad.
Pseudo code:
get current
get next
while (current != null && next != null && current == '0' && next is a
number)
{
current = next
next = get next
}
Now imagine this for every char in a string, and for every string in a
file list (with some 100 files). It's three-times (or even more) more
complexity than just.
while (is_zero(a))
a = next;
We're on embedded, and thus slow systems. Your would surely work well on
a desktop app, but for mp3-players we need fast and small code. The gain
has to justify the code, and I don't think it does it in this example.
What about something like this. Taking in consideration the isspace
function/comparison was removed? And isdigit is supposed to give nonzero
on nodigit values.
/* skip over leading zeros */
while ('0' == ca && nat_isdigit(ca_next) )
{
ca = to_int(a[++ai]);
ca_next = to_int(a[ai+1]);
}
I've found a simpler solution for this. Trying the code raises the
following problem:
00 < 0b < 01 < 1
Zeros before except the final zeros are ignored, and the final zero
before characters is not ignored. But the leading zeros of numbers are
(so that 01 is 1). Obviously 0 sorts before 1.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote:
> Bryan VanDyke wrote:
>> Thomas Martitz wrote:
>>
>>> Linus Nielsen Feltzing wrote:
>>>
Mike Holden wrote:
> Maybe leading zeros should only be stripped if another digit follows
> them?
>
> I use names like 00RockFaves.m3u, 00ClassicRock.m3u for playlists
> that I
> have created (as opposed to original artist albums), and the leading
> zerozero is deliberately there to sort them at the top.
>
That's an interesting observation. I believe leading zeroes are
treated like whitespace in the current code, but in this case I think
that the final zero should be kept.
Linus
>>> That's not trivial, and adds complexity. You basically need to look at
>>> the current, the next, and one more for this, instead of just the
>>> current char.
>>>
>>>
>>
>> Actually it not that bad.
>>
>> Pseudo code:
>>
>> get current
>> get next
>> while (current != null && next != null && current == '0' && next is a
>> number)
>> {
>> current = next
>> next = get next
>> }
>>
>>
>>
> Now imagine this for every char in a string, and for every string in a
> file list (with some 100 files). It's three-times (or even more) more
> complexity than just.
> while (is_zero(a))
>a = next;
>
> We're on embedded, and thus slow systems. Your would surely work well on
> a desktop app, but for mp3-players we need fast and small code. The gain
> has to justify the code, and I don't think it does it in this example.
>
What about something like this. Taking in consideration the isspace
function/comparison was removed? And isdigit is supposed to give nonzero
on nodigit values.
/* skip over leading zeros */
while ('0' == ca && nat_isdigit(ca_next) )
{
ca = to_int(a[++ai]);
ca_next = to_int(a[ai+1]);
}
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: Mike Holden wrote: Thomas Martitz wrote: After this discussion and the ones in IRC, it seems to me that the majority is in favor of ignoring leading zeros. This would also match with Nautilus' and Windows Explorer's sorting. And we can do that. Give that the usual browsers do it that way, it's also what the user expects, so it can't be bad. FS#10031 needs changing the algorithm anyway. So, should we do that? It at least seems to be the opinion of most people. Just had a quick look in My Computer on an XP box to see how this does it. 1. 001 sorts before 01 and 01 sorts before 1, giving the conclusion that more leading zeroes sorts before less leading zeroes, where the underlying number is the same (i.e. 000x < 00x for any number x). 2. 1 sorts before 2, 2 before 10, 10 befoer 11 etc, as expected giving numeric sorting. 3. 001 sorts before 10 and 010, again giving expected sorting for the numeric part. 4. Introducing letters into the equation, we can see that 00A sorts before 00aa, 001 and 1. This satisfies my expectation that leading zeroes before letters should sort first in the list, and not be sorted among the letter part only. All of these individual items line up to give a file listing that doesn't produce any surpries for me, so I would be happy with this set of rules. This is what we'll be doing too. comparing 001 and 1, will yield 001 < 1, because if strnatcmp sorts the same, strcmp is asked. Err, I guess point 4) isn't covered with my modification.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Bryan VanDyke wrote:
Thomas Martitz wrote:
Linus Nielsen Feltzing wrote:
Mike Holden wrote:
Maybe leading zeros should only be stripped if another digit follows
them?
I use names like 00RockFaves.m3u, 00ClassicRock.m3u for playlists that I
have created (as opposed to original artist albums), and the leading
zerozero is deliberately there to sort them at the top.
That's an interesting observation. I believe leading zeroes are
treated like whitespace in the current code, but in this case I think
that the final zero should be kept.
Linus
That's not trivial, and adds complexity. You basically need to look at
the current, the next, and one more for this, instead of just the
current char.
Actually it not that bad.
Pseudo code:
get current
get next
while (current != null && next != null && current == '0' && next is a
number)
{
current = next
next = get next
}
Now imagine this for every char in a string, and for every string in a
file list (with some 100 files). It's three-times (or even more) more
complexity than just.
while (is_zero(a))
a = next;
We're on embedded, and thus slow systems. Your would surely work well on
a desktop app, but for mp3-players we need fast and small code. The gain
has to justify the code, and I don't think it does it in this example.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Linus Nielsen Feltzing wrote: Bryan VanDyke wrote: 1. Numbers sort before Non-numbers. - Leading zeros are striped. A leading zero on a zero is still zero. - 000 becomes 0. - Some of the code that has been used has trouble with this. 2. Lesser number before greater. - 1,2,3,4 etc 3. Anything else strcmp. Sounds simple and sane, and seems to be the way Windows Explorer works as well. Linus Well, this is what SVN does, currently. And if we we want 02 after 1, just a (relatively) small modification is needed, without messing up decimal numbers like 1.02 and 1.1
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Mike Holden wrote: Thomas Martitz wrote: After this discussion and the ones in IRC, it seems to me that the majority is in favor of ignoring leading zeros. This would also match with Nautilus' and Windows Explorer's sorting. And we can do that. Give that the usual browsers do it that way, it's also what the user expects, so it can't be bad. FS#10031 needs changing the algorithm anyway. So, should we do that? It at least seems to be the opinion of most people. Just had a quick look in My Computer on an XP box to see how this does it. 1. 001 sorts before 01 and 01 sorts before 1, giving the conclusion that more leading zeroes sorts before less leading zeroes, where the underlying number is the same (i.e. 000x < 00x for any number x). 2. 1 sorts before 2, 2 before 10, 10 befoer 11 etc, as expected giving numeric sorting. 3. 001 sorts before 10 and 010, again giving expected sorting for the numeric part. 4. Introducing letters into the equation, we can see that 00A sorts before 00aa, 001 and 1. This satisfies my expectation that leading zeroes before letters should sort first in the list, and not be sorted among the letter part only. All of these individual items line up to give a file listing that doesn't produce any surpries for me, so I would be happy with this set of rules. This is what we'll be doing too. comparing 001 and 1, will yield 001 < 1, because if strnatcmp sorts the same, strcmp is asked.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Bryan VanDyke wrote: 1. Numbers sort before Non-numbers. - Leading zeros are striped. A leading zero on a zero is still zero. - 000 becomes 0. - Some of the code that has been used has trouble with this. 2. Lesser number before greater. - 1,2,3,4 etc 3. Anything else strcmp. Sounds simple and sane, and seems to be the way Windows Explorer works as well. Linus
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: > After this discussion and the ones in IRC, it seems to me that the > majority is in favor of ignoring leading zeros. This would also match > with Nautilus' and Windows Explorer's sorting. > > And we can do that. Give that the usual browsers do it that way, it's > also what the user expects, so it can't be bad. FS#10031 needs changing > the algorithm anyway. > > So, should we do that? It at least seems to be the opinion of most people. > Just had a quick look in My Computer on an XP box to see how this does it. 1. 001 sorts before 01 and 01 sorts before 1, giving the conclusion that more leading zeroes sorts before less leading zeroes, where the underlying number is the same (i.e. 000x < 00x for any number x). 2. 1 sorts before 2, 2 before 10, 10 befoer 11 etc, as expected giving numeric sorting. 3. 001 sorts before 10 and 010, again giving expected sorting for the numeric part. 4. Introducing letters into the equation, we can see that 00A sorts before 00aa, 001 and 1. This satisfies my expectation that leading zeroes before letters should sort first in the list, and not be sorted among the letter part only. All of these individual items line up to give a file listing that doesn't produce any surpries for me, so I would be happy with this set of rules. -- Mike Holden http://www.by-ang.com - the place to shop for all manner of hand crafted items, including Jewellery, Greetings Cards and Gifts
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote:
> Linus Nielsen Feltzing wrote:
>> Mike Holden wrote:
>>> Maybe leading zeros should only be stripped if another digit follows
>>> them?
>>>
>>> I use names like 00RockFaves.m3u, 00ClassicRock.m3u for playlists that I
>>> have created (as opposed to original artist albums), and the leading
>>> zerozero is deliberately there to sort them at the top.
>>
>> That's an interesting observation. I believe leading zeroes are
>> treated like whitespace in the current code, but in this case I think
>> that the final zero should be kept.
>>
>> Linus
> That's not trivial, and adds complexity. You basically need to look at
> the current, the next, and one more for this, instead of just the
> current char.
>
Actually it not that bad.
Pseudo code:
get current
get next
while (current != null && next != null && current == '0' && next is a
number)
{
current = next
next = get next
}
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Dominik Riebeling wrote: > Hi, > > I started wondering how the value "as whole numbers" for the setting > "interpret numbers while sorting" is intended to work. Currently it > seems to get changed in svn quite often. However, I haven't seen a > consensus how this feature is supposed to work (read: sort) gathered, > especially before committing. A recent discussion is here: > http://www.rockbox.org/irc/log-20090317#17:53:35 > > Maybe I've missed such a consensus -- in this case someone please > point me to the right direction and ignore this mail :) Changing the > behaviour of this setting frequently is a rather bad thing IMO. We > need to specify how we want it to work and implement it that way. > Doing this kind of "discussion in svn" is a bad thing and can only > lead to confusion among users. We didn't do this for the "study mode" > feature either, even if there was a consensus to change it. > > Now, how should this feature sort? From my point of view, I'd expect it to > - treat digits as numbers. A value of "00" equals to zero and thus > gets sorted before the number 1, regardless if that is "1", "01" or > "001". Completely skipping the zero (as it's only leading zeros) is as > broken as to not strip leading zeros -- "003" should equal to 3 and > "01" to 1, thus the latter sorting before the former. A situation > where a folder can contain files starting with "02" and "4" the same > time is something that could happen and still not being intentional > (just think of copying files from various albums to a mix folder). > Either treat digits as number or don't treat them as numbers at all. > - Spaces shouldn't get collapsed. A space is a space, and "interpret > numbers" doesn't tell anything about spaces. At least at some point > during the lifetime of this setting spaces were collapsed. Nothing > that is a number ... > > This still leaves some open issues I'm not sure how to deal about: > - how are floating-point numbers to be treated? "1.001" is smaller as > "1.01" when treating as numbers, so on the one hand I'd expect them to > sort that way. On the other hand, recognizing the dot as decimal > separator is broken as well -- not all languages use it as decimal > separator (like german using the comma). Stopping the number-treating > at dots is also kinda broken -- how should a naming be handled as > "discnumber.tracknumber", i.e. like "1.2", "1.10" -- which one has to > be sorted first? The best solution here might be to treat all numbers > as single numbers, regardless if they might be floating point numbers > -- I guess it's more common to have a "1.3" numbering to mark > discnumber.track instead of a floating point number "1.003". > > I'm pretty sure I've missed some of my points right now :) What do > people think about this sorting thing? > > > - Dominik > I think it should just be the simplest and easiest to understand. Any consecutive run of numbers [0-9] are treated as a its value for sorting purposes. This means any non-digit is treated like a separator. Which would include punctuation, spaces, etc. This also avoid trying to figure out what the person meant by using a period. Was it a separator, equivalent to US comma, region setting, real number, etc? That's just a road nobody is going to agree on. Same thing if a person is using punctuation, leading zeros, etc to control the sort order. There's no way to read the persons mind on what they intended. In all likelihood they're going to use the ASCII sort anyways. The various implementation that have been used by RB have tried to eat spaces so a 1 a001 a 01 Are all equal to a1. I say throw that out too. 1. Numbers sort before Non-numbers. - Leading zeros are striped. A leading zero on a zero is still zero. - 000 becomes 0. - Some of the code that has been used has trouble with this. 2. Lesser number before greater. - 1,2,3,4 etc 3. Anything else strcmp.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Thomas Martitz wrote: Dominik Riebeling schrieb: Maybe I've missed such a consensus -- in this case someone please point me to the right direction and ignore this mail :) After this discussion and the ones in IRC, it seems to me that the majority is in favor of ignoring leading zeros. This would also match with Nautilus' and Windows Explorer's sorting. And we can do that. Give that the usual browsers do it that way, it's also what the user expects, so it can't be bad. FS#10031 needs changing the algorithm anyway. So, should we do that? It at least seems to be the opinion of most people. Ok, I've implemented ignoring very leading zeros now, and fixed FS#10031, in my local repo. It could be committed, I think. It seems the consensus is reached. Alternatively we can also think about ignoring chars like . and _ (and possibly more) in the beginning of a file name (e.g. .rockbox is sorted under r). Just an idea. It doesn't really add complexity, but would definitely do more than the setting advertises. But, this is also something windows/nautilus/more do.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Linus Nielsen Feltzing wrote: Mike Holden wrote: Maybe leading zeros should only be stripped if another digit follows them? I use names like 00RockFaves.m3u, 00ClassicRock.m3u for playlists that I have created (as opposed to original artist albums), and the leading zerozero is deliberately there to sort them at the top. That's an interesting observation. I believe leading zeroes are treated like whitespace in the current code, but in this case I think that the final zero should be kept. Linus That's not trivial, and adds complexity. You basically need to look at the current, the next, and one more for this, instead of just the current char.
Re: Default on or off
Bryan VanDyke wrote: > Mike Holden wrote: >> As a side debate (subject line altered appropriately), should it be >> enabled by default? >> >> Personally I would say no, since it changes current functionality. I have >> no need for this feature since I only play playlists directly, so the >> names of the actual music files have no interest or meaning for me. >> > > I vote off by default. > >> However I do have some "custom" playlists (i.e. mixes, not original artist >> albums), and I labelled them all beginning with 00 (zero zero) so that >> they sorted first in my list of playlists. Once this new feature was >> implemented, my playlists suddenly disappeared into the big list of >> playlists, so that 00Rock.m3u sorted under R while 00ClassicRock.m3u >> sorted under C. > > > The implementation from before the revert had a bug where it stripped > ALL zeros instead of just LEADING zeros. So if the number was 0, with or > without leading zeros,it was removed. ie > > 0 -> 0 > 00 -> nothing > 01 -> 1 > 002 ->2 > > This was reported in FS#10029. I submitted a fix for it FS#10030 but > unfortunately it got lost in the revert. > > The fix did this > 0 -> 0 > 00 -> 0 > 01 -> 1 > 002 -> 2 > > >> Fortunately I follow the discussions on here so I was aware of the change >> and what I needed to alter in my settings to disable it. >> >> I would vote for new features which change existing functionality to be >> disabled by default. Do we have a general policy on this? > > oops. too quick with the copy and paste. before 0 -> nothing 00 -> nothing 01 -> 1 002 -> 2 after 0 -> 0 00 -> 0 01 -> 1 002 -> 2
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Mike Holden wrote: Maybe leading zeros should only be stripped if another digit follows them? I use names like 00RockFaves.m3u, 00ClassicRock.m3u for playlists that I have created (as opposed to original artist albums), and the leading zerozero is deliberately there to sort them at the top. That's an interesting observation. I believe leading zeroes are treated like whitespace in the current code, but in this case I think that the final zero should be kept. Linus
Re: Default on or off
Mike Holden wrote: > As a side debate (subject line altered appropriately), should it be > enabled by default? > > Personally I would say no, since it changes current functionality. I have > no need for this feature since I only play playlists directly, so the > names of the actual music files have no interest or meaning for me. > I vote off by default. > However I do have some "custom" playlists (i.e. mixes, not original artist > albums), and I labelled them all beginning with 00 (zero zero) so that > they sorted first in my list of playlists. Once this new feature was > implemented, my playlists suddenly disappeared into the big list of > playlists, so that 00Rock.m3u sorted under R while 00ClassicRock.m3u > sorted under C. The implementation from before the revert had a bug where it stripped ALL zeros instead of just LEADING zeros. So if the number was 0, with or without leading zeros,it was removed. ie 0 -> 0 00 -> nothing 01 -> 1 002 ->2 This was reported in FS#10029. I submitted a fix for it FS#10030 but unfortunately it got lost in the revert. The fix did this 0 -> 0 00 -> 0 01 -> 1 002 -> 2 > > Fortunately I follow the discussions on here so I was aware of the change > and what I needed to alter in my settings to disable it. > > I would vote for new features which change existing functionality to be > disabled by default. Do we have a general policy on this?
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Mike Holden wrote: Maybe leading zeros should only be stripped if another digit follows them? I use names like 00RockFaves.m3u, 00ClassicRock.m3u for playlists that I have created (as opposed to original artist albums), and the leading zerozero is deliberately there to sort them at the top. At the moment using natural sorting, 00RockFaves.m3u is sorted among the "R" entries, totally defeating my intention in choosing that naming (and not "natural" to my view!). 01Rock should sort before 02Rock, agreed, but should 01Rock sort before A or before S? Sounds to me that you're better off using ascii sort. In any case, it would be interesting to see how windows does the sorting, as the most users will be used to that way of doing it. Maybe many, but we shouldn't assume that is the case. I personally have no idea how Windows does it, and I wouldn't necessarily agree that just because MS does it that that is the _right_ way to do it. Windows does it in the same way as nautilus and other major file browsers. It ignores leading zeros.
Re: Default on or off
Mike Holden wrote: As a side debate (subject line altered appropriately), should it be enabled by default? Yes, I believe it should. I think the average user would appreciate if it by default sorted in the same way as most modern file browsers do, i.e natural sorting. I would vote for new features which change existing functionality to be disabled by default. Do we have a general policy on this? There is no written policy, but the general opinion among us developers is that the defaults should be as "sensible" as possible for the first-time user. Linus
2009 Google Summer of Code Student Interest
Hi All, I'm a student interested in a gsoc project for 2009. I'm a 5th (final) year studying BEng (Electronics and Computer Systems)/BSci (Research and Development) at Swinburne University in Melbourne, Australia. I'm interested in two ideas listed in the wiki: Touchscreen improvements and Rockbox as an Android application. I'm an owner and regular user of an iriver H140 and Cowon D2. I find the touchscreen driver on the D2 inadequate for reliable usage, while the main thing it probably needs are some tweaks (to reduce sensitivity etc), I think it would be good to extend the WPS to include onscreen buttons for interaction. This could be useful for rockbox as it is ported to more touch screen devices. I'm also interested in an attempt to "port" Rockbox to Android. I realise that would mostly likely be a complete code rewrite and it may not be practical. I've done a little bit of investigation and it seems possible to run native code on the G1, but it is unsupported and I don't know if a native library can be accessed though the Dalvik VM. OpenMoko is also a possibility for a port, but I prefer the idea of Android over OpenMoko as it is more stable, the development environment seems better and it could reach a wider audience, it is less free however. I also think it could be possible to combine both ideas, improve the touchscreen interface and then use that knowledge and apply it to an Android rewrite. Please let me know what you think. Thanks, Alex
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Dominik Riebeling wrote: > well, treating a number as such includes stripping leading zeros from > it, at least from my understanding. It won't do any harm on properly > named files, and I don't see a reason why a user would want to prefix > with 0 just to change sorting. Maybe leading zeros should only be stripped if another digit follows them? I use names like 00RockFaves.m3u, 00ClassicRock.m3u for playlists that I have created (as opposed to original artist albums), and the leading zerozero is deliberately there to sort them at the top. At the moment using natural sorting, 00RockFaves.m3u is sorted among the "R" entries, totally defeating my intention in choosing that naming (and not "natural" to my view!). 01Rock should sort before 02Rock, agreed, but should 01Rock sort before A or before S? > In any case, it would be interesting to see how windows does the > sorting, as the most users will be used to that way of doing it. Maybe many, but we shouldn't assume that is the case. I personally have no idea how Windows does it, and I wouldn't necessarily agree that just because MS does it that that is the _right_ way to do it. -- Mike Holden http://www.by-ang.com - the place to shop for all manner of hand crafted items, including Jewellery, Greetings Cards and Gifts
Default on or off (was: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?)
As a side debate (subject line altered appropriately), should it be enabled by default? Personally I would say no, since it changes current functionality. I have no need for this feature since I only play playlists directly, so the names of the actual music files have no interest or meaning for me. However I do have some "custom" playlists (i.e. mixes, not original artist albums), and I labelled them all beginning with 00 (zero zero) so that they sorted first in my list of playlists. Once this new feature was implemented, my playlists suddenly disappeared into the big list of playlists, so that 00Rock.m3u sorted under R while 00ClassicRock.m3u sorted under C. Fortunately I follow the discussions on here so I was aware of the change and what I needed to alter in my settings to disable it. I would vote for new features which change existing functionality to be disabled by default. Do we have a general policy on this? -- Mike Holden http://www.by-ang.com - the place to shop for all manner of hand crafted items, including Jewellery, Greetings Cards and Gifts
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Paul Louden wrote: I've stated my position several times: I think we should decide whether we want to mimic the file browsers or not. If we do, I think we should mimic all their sorting quirks that we can, rather than suggest we're "like" them but with our own choices as to where to go our own way. Sure. I don't see a problem with this, as long as it doesn't make the code overly complicated or slow. Linus
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Linus Nielsen Feltzing wrote: Or, instead of doing a poll, why not do it in the same way as the major file browsers do? After all, "normal" people would probably expect Rockbox to sort the files in the same order as the computer file browser does, wouldn't they? I've stated my position several times: I think we should decide whether we want to mimic the file browsers or not. If we do, I think we should mimic all their sorting quirks that we can, rather than suggest we're "like" them but with our own choices as to where to go our own way. If we're not going to mimic them, I think respecting intentional 0s is the way to go. Personal opinion, yes, but at least some people I know seem to think "04" is not the same as "4" linguistically, or really at all outside of actually doing math on it.
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Paul Louden wrote: The problem is, now you're arguing "mathematical rules." We've already established people don't think in mathematical rules. I doubt people see "04" and think "four". They think "oh-four." The zero is not an insignificant and ignored digit in the way people speak, read, or think the number. Except in math. But we're talking "normal people" here. You have a point there. I'm afraid most of my friends don't count as "normal" people. ;-) Instead of us trying to think about them, if we're going to base this on "normal people" let's do a poll. At least this way we're not extrapolating our opinion on them based on *mathematics*, something few people think in. Or, instead of doing a poll, why not do it in the same way as the major file browsers do? After all, "normal" people would probably expect Rockbox to sort the files in the same order as the computer file browser does, wouldn't they? Linus
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Linus Nielsen Feltzing wrote: If it sorts 007 after 6, I fail to see how it would be surprising to the user in any way. It is after all a well-known mathematical rule, and a rule that the major file browsers follow. If we claim to sort numbers, we should do so, and not change the fundamental rules of mathematics. Just as a counterpoint to this - People don't normally put 0s before a number. I would expect a lot of people would think "007" is "00 and 7" not "7" and that leading zeros are "not part of the number." I know an informal study of "all of my friends online right now" (none of whom are computers scientists and many of whom are artists or fairly nontechnical people) as told me that they expect that "04" would come before "2" because of the zero. It was presented this way "if you had a list 2, 3, 4, 5, and you were to add 04 to it, where would you put it?" so I don't think my question was presented in a leading way. The problem is, now you're arguing "mathematical rules." We've already established people don't think in mathematical rules. I doubt people see "04" and think "four". They think "oh-four." The zero is not an insignificant and ignored digit in the way people speak, read, or think the number. Except in math. But we're talking "normal people" here. Instead of us trying to think about them, if we're going to base this on "normal people" let's do a poll. At least this way we're not extrapolating our opinion on them based on *mathematics*, something few people think in.
RE: Rockbox accepted to Google Summer of Code 2009
On Wed, 18 Mar 2009, Mike Giacomelli wrote: http://www.rockbox.org/twiki/bin/view/Main/SummerOfCode2009 Perhaps you could put a note on the front page that we'll be participating like we did last year? Should make things a bit more welcome to any prospective students researching our project. Indeed! And as a reminder to everyone: every committer can do changes to the web site, it's just that one of the web site admins need to perform the actual update from svn manually. -- / daniel.haxx.se
Re: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
Paul Louden wrote: No, this isn't. This is "having intuitive handling of numbers as normally written by people." People don't normally precede numbers with a 0 unless there's a specific reason to. I'd think that many files will have names with leading zeros, especially if they are copied from a player that doesn't support natural sorting, where the user will have added leading zeros to force a correct sorting. Also, you seem to forget the very reason that we implement natural sorting in the first place, which is to sort numbers in a natural way, so the user finds numbered files where he expect them to be, without having to change the file names. Further, natural sorting strives to sort numbers in a way that humans *expect* them to be sorted. Leading zeros are insignificant when treating numbers, that is a mathematical rule that the vast majority of people knows. I dare to say that people in general expect the browser to ignore leading zeros. If it sorts 007 after 6, I fail to see how it would be surprising to the user in any way. It is after all a well-known mathematical rule, and a rule that the major file browsers follow. If we claim to sort numbers, we should do so, and not change the fundamental rules of mathematics. Linus
