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
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
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
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
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
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
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.
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
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
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
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
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)
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
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
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
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,
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
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
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
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
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,
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
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
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
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
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
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
On Thu, Mar 19, 2009 at 4:34 PM, Thomas Martitz
thomas.mart...@fhtw-berlin.de 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
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
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
On Thu, Mar 19, 2009 at 4:04 PM, Thomas Martitz
thomas.mart...@fhtw-berlin.de 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
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
On Thu, Mar 19, 2009 at 9:21 AM, Paul Louden paulthen...@gmail.com 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
Dominik Riebeling wrote:
On Thu, Mar 19, 2009 at 4:04 PM, Thomas Martitz
thomas.mart...@fhtw-berlin.de 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))
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
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
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
On Thu, Mar 19, 2009 at 6:47 PM, Thomas Martitz
thomas.mart...@fhtw-berlin.de 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
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.
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
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
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
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
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
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
45 matches
Mail list logo
