XavierGr wrote:
And, as a point of interest, we're already using ~20-25% of the available
RAM on the Cowon Coldfire-based players as it stands, binsize is not only
important to the Archos players. We're also looking at players that only
have 384kb of RAM, which makes binsize an even more
On Wed, Oct 29, 2008 at 12:58 PM, Paul Louden [EMAIL PROTECTED] wrote:
This again is a false comparison. The WWW doesn't have resource
restrictions in the same manner as Rockbox. Assume the internet became
slower for everyone, the instant any website was put up. Were this the case
there would
Paul Louden wrote:
That means less useful features should be considered critically even
if they have small binsize costs, just because they're useful to only
an exceptionally small group. They're a dilution of the total
usefulness density.
Let me chime in with my $0.02. I think that the
Linus Nielsen Feltzing wrote:
Let me chime in with my $0.02. I think that the binsize isn't *that*
important for the battery life. If a feature adds 10Kbytes to the
binary, it means 10Kbytes less buffering memory. That is hardly
measurable at all, only a few frames of an MP3 file.
Remember
On Wed, 29 Oct 2008, Paul Louden wrote:
I'd also like to challenge anyone here to find three features that were
actually rejected with binary size being the cause.
And I also would like to remind you all that:
it doesn't matter
Each feature is taken on case by case so just shouting
On Wed, Oct 29, 2008 at 6:35 PM, Daniel Stenberg [EMAIL PROTECTED] wrote:
This is also true if X is 'call the binsize card too often'.
Thus, it doesn't matter if we agree on this X or not...
I agree, but I think the goal of this thread is to clarify for some people
exactly how important
Roy Wallace wrote:
I agree, but I think the goal of this thread is to clarify for some
people exactly how important binary size is, by coming to a
compromise, a consensus, so as to avoid having the same argument
repeatedly on a case by case basis.
Since the original message in this wasn't
On Mon, 27 Oct 2008, Jonathan Gordon wrote:
I think its time to have a proper discussion about adding settings
Interesting discussion. Since I was gone during the better part of it, I'll
just add my sparks to the flames:
o I think referring to or assuming that discussions on IRC are good
On Mon, Oct 27, 2008, Paul Louden wrote:
XavierGr wrote:
Sorry but my memory doesn't help me much. Which are these 384kb of RAM
targets? (I hope that you don't mean the iFP).
Sansa Clip. The iFP has 1MB of RAM.
The Sansa Clip has 2MB of RAM.
I think an audio player (especially if it has
Jonathan Gordon schrieb:
none of these have a working patch yet, and yes there will be argument
if/when they ever are ready.
Depends on you define as working. They all have a working patch, but if
their committability is another question (and I quite like how my custom
list patch works).
Thomas Martitz wrote:
More then often binsize seems (to me) just to be brought up as a
reason since it's the standard reason and sounds very much better than
I won't use the feature, so it won't get in, especially not if I'd
have to look at an option more in the setting.
This sounds to me an
On Tue, Oct 28, 2008 at 6:40 PM, Thomas Martitz [EMAIL PROTECTED] wrote:
I pretty much agree with XavierGr in this discussion. Devs tend to evaluate
new features only on their own using habbits. More then often binsize seems
and people doing patches aren't doing them based on their habits? Do
Dominik Riebeling wrote:
I don't say binsize isn't a valid reason. But it's kinda stressed very much
Maybe it's stressed much lately. But as already has been said, Rockbox
is much more feature complete than it was like two years ago, and we
need to decide how much bells and whistles we
On Tue, Oct 28, 2008 at 3:15 AM, Jonathan Gordon [EMAIL PROTECTED] wrote:
We have a very high level of patch rot which is the same thing (some
but why do we have this high level of patch rot? Because all patches
in the tracker are crap or mediocre features? I don't think so. From
my impression
On Tue, Oct 28, 2008 at 3:01 AM, alex wallis
[EMAIL PROTECTED] wrote:
Sorry but I really have to disagree with you on this one, I wouldn't
describe study mode or whatever it has been renamed to as mediocre or a
useless feature.
There will always be people that call a feature you consider
Paul Louden schrieb:
It doesn't serve the community or this discussion to assume dishonesty
in advance, and without any proof other than your personal feelings on
the matter.
Sorry if it sounded like that. I didn't wan to say you lie at all about
binsize. And I wouldn't think you're not
Thomas Martitz wrote:
Don't get me wrong. Binsize (and Ram usage even more imho) is very
important and you should always take it into account before committing
something, but the more the binsize is used as a rejection reason, the
less believable it sounds at times.
Well, which is it. Do you
2008/10/27 Paul Louden [EMAIL PROTECTED]:
Jonathan Gordon wrote:
And you've heard dozens of times it's not *just* bin increase that's a
problem, but whether a feature's bin increase is worth the functionality it
adds. There's a finite limit on how much can and should be added (though
we've
Hi Jonathan,
1. bin increase
We're obviously going to have to agree to disagree here. You seem to think
that a 32MB buffer is lots of memory; I think of it as the most important
resource we have to keep battery life up. I don't know which device/setup
you use normally, but perhaps it's
On Mon, Oct 27, 2008 at 4:58 AM, Jonathan Gordon [EMAIL PROTECTED] wrote:
2. Settings bloat.
Yes, we have lots of settings (168 in the e200 sim) but why is this
bad? If you don't change a setting and are happy with the default then
good for you, your config.cfg will be a lot smaller than
2008/10/27 Nils [EMAIL PROTECTED]:
I'm with pondlife on the advanced settings menu btw, hiding stuff just makes
the whole issue worse IMHO.
I didn't say it was a good idea... its just one (of hopefully many) idea.
Hi everybody,
in general I agree to Jonathan, I personally really like to configure
everything what's possible ;-)
BUT: I usually only do it until I'm happy with the settings; from then on I
only change a few ones.
So we could consider about having an external tool (either a plugin or even
2008/10/27 pondlife [EMAIL PROTECTED]:
Hi Jonathan,
1. bin increase
We're obviously going to have to agree to disagree here. You seem to think
that a 32MB buffer is lots of memory; I think of it as the most important
resource we have to keep battery life up. I don't know which
2008/10/27 Matthias Mohr [EMAIL PROTECTED]:
Hi everybody,
in general I agree to Jonathan, I personally really like to configure
everything what's possible ;-)
BUT: I usually only do it until I'm happy with the settings; from then on I
only change a few ones.
So we could consider about
I'm with the people who are against having settings which are not
(easily) configurable on the DAP itself. The furthest away from the
core I would suggest is as a plugin.
Hi. I'm afraid that this will probably look like i'm complaining hear.
However, again as i've said before in other posts on
2008/10/28 alex wallis [EMAIL PROTECTED]:
I'm with the people who are against having settings which are not
(easily) configurable on the DAP itself. The furthest away from the
core I would suggest is as a plugin.
Hi. I'm afraid that this will probably look like i'm complaining hear.
However,
Hi Jonathan,
off the top of my head, settings which should stay but dont need to be
so high up are things like directory/playlist limits, show the title
in the browser, disk and battery options, most of the display
options... bassically anything which are set once options
set once for you
However if they were accessible with the speech interface, I would have no
objection at all to settings being turned into plugins.
Does anyone no what happened to that particular gsoc project?
I'm still alive :). School and interviews have been kicking my ass for the
past month or so and I've
On Mon, Oct 27, 2008 at 2:27 PM, alex wallis
[EMAIL PROTECTED] wrote:
Hi. I'm afraid that this will probably look like i'm complaining hear.
However, again as i've said before in other posts on other topics, with your
above comment, if we have settings as a plugin, we run into the good old
From: [EMAIL PROTECTED]
To: rockbox-dev@cool.haxx.se
Subject: discussion regarding adding settings (PLEASE add your 2 cents)
I think its time to have a proper discussion about adding settings
(and to a lesser extent, adding features which may not be used by the
vocal majority.) I'd like to keep
Mark Ganson wrote:
I like Jonathan's test for a new feature: the burden should be upon
those who don't want it to show why it shouldn't be added rather than
upon the ones who want it to justify why it should be added.
But the binsize question will ALWAYS come up, so those who think it
I suggested moving the settings to a plugin a while ago on IRC, the major
objections were:
a) Voice isn't (yet) supported
b) Requires a disk spinup (to load the plugin) each time you want to change
a setting.
Tom's work should resolve (a).
For (b), I proposed that we allow the last-loaded
Does anyone no what happened to that particular gsoc project?
I'm still alive :). School and interviews have been kicking my ass for the
past month or so and I've had zero time for Rockbox related work. The patch on
the tracker is horribly out of date too. I sent my most recent work to Daniel
there is a
solution.
I'd propose this: battery bench doesn't use the plugin buffer at all, but
steals his 512bytes from the main ram. So, stop playback - start battery
bench - start playback again. There's also other plugins doing this.
HI. I see, so am I following you right, your proposing
alex wallis schrieb:
HI. I see, so am I following you right, your proposing that battery
bench should be altered so that it doesn't use the plugin buffer at all?
is that right? or is that how it now works? sorry I just found your
english slightly hard to follow.
Also, when you talk about
As of now it uses the plugin buffer. Using the main ram would remove the
limitation to be not able to run other plugins.
As for the playback: No, in it's current form it starts with active
playback and it doesn't stop it.
In my proposal you would need to stop the playback (in order to steal
I'd propose this: battery bench doesn't use the plugin buffer at all, but
steals his 512bytes from the main ram. So, stop playback - start battery
bench - start playback again. There's also other plugins doing this.
I assume those 512 shouldn't have a huge impact on the battery life. But
I'd propose this: battery bench doesn't use the plugin buffer at all, but
steals his 512bytes from the main ram. So, stop playback - start battery bench
- start playback again. There's also other plugins doing this.
I assume those 512 shouldn't have a huge impact on the battery life. But this
alex wallis wrote:
Hi. because, what happens if a user wants to change a setting that
impacts on how music is played back they wouldn't be able to do it
if settings was turned into a plugin and battery bench was left in
its current state.
They would therefor have to disable
On Mon, Oct 27, 2008 at 7:00 PM, Thomas Martitz [EMAIL PROTECTED] wrote:
I'd propose this: battery bench doesn't use the plugin buffer at all, but
steals his 512bytes from the main ram. So, stop playback - start battery
bench - start playback again. There's also other plugins doing this.
I
alex wallis wrote:
Hi. because, what happens if a user wants to change a setting that
impacts on how music is played back they wouldn't be able to do it
if settings was turned into a plugin and battery bench was left in
its current state.
They would therefor have to disable
alex wallis wrote:
But you can almost certainly guarantee there wil be at least one
person who say decides they want to change an album so it gets
shuffled for example. Yes I no that would lead to an inaccurate
battery test, but i'm sure you will find there is at least one person
out there
On Mon, Oct 27, 2008 at 7:04 AM, Jonathan Gordon [EMAIL PROTECTED] wrote:
2008/10/27 Paul Louden [EMAIL PROTECTED]:
For example, there's a legitimate argument that we
could just compromise on the spacing value rather than making it accept a
configurable string.
Actually no, A simple strcat
Unfortunately Rockbox has become quite feature-phobic recenlty. This
wasn't the case a couple of years ago, where if the new feature in question
was implemented correctly, it was mostly accepted without any thorough
debate. The result was many and sometimes unneeded settings. Do I have
second
XavierGr wrote:
will be rejected on the shrine of binsize and the doctrine of
settings-bloat.
Can we please try to have this discussion without resorting to rhetoric
and terms like this?
And, as a point of interest, we're already using ~20-25% of the
available RAM on the Cowon
Jonathan Gordon wrote:
Put simply, my take on this issue is that I want more GNOME, and less KDE
mentality. I may use 30 out of 200 settings. Now if we say that was cut in
half, to 100 available settings, I might lose 10 settings. Would I miss
them? Probably at first, but in my experience (from
On Mon, Oct 27, 2008 at 6:47 PM, Jonas Häggqvist [EMAIL PROTECTED] wrote:
Jonathan Gordon wrote:
Put simply, my take on this issue is that I want more GNOME, and less KDE
mentality. I may use 30 out of 200 settings. Now if we say that was cut in
half, to 100 available settings, I might
Can we please try to have this discussion without resorting to rhetoric and
terms like this?
The phrase was a tongue in cheek, that's what the smiley was about in case
someone was offended by it. I don't get where the problem is with that.
And, as a point of interest, we're already using
2008/10/28 Paul Louden [EMAIL PROTECTED]:
XavierGr wrote:
will be rejected on the shrine of binsize and the doctrine of
settings-bloat.
Can we please try to have this discussion without resorting to rhetoric and
terms like this?
apparently not... 3 messages back from you agreed that it
XavierGr wrote:
The phrase was a tongue in cheek, that's what the smiley was about
in case someone was offended by it. I don't get where the problem is
with that.
Tongue in cheek or not, it creates a tone different from reasoned
discussion. That's my point: Let's keep this without the
2008/10/28 Jonas Häggqvist [EMAIL PROTECTED]:
Jonathan Gordon wrote:
Put simply, my take on this issue is that I want more GNOME, and less KDE
mentality. I may use 30 out of 200 settings. Now if we say that was cut in
half, to 100 available settings, I might lose 10 settings. Would I miss
I completely agree with Jonas. I think that there is too much focus on
what can be customized rather than basic usability. Making /sane/ defaults
for users is not such a bad thing.
Having the option of customizing something doesn't hinder focusing on
usability.
Sane defaults are good but
XavierGr wrote:
Sane defaults are good but when hard-coded they can be very limiting.
Sane, hardcoded defaults can also let you get on with your life, rather
than waste your life configuring everything, and having unimportant
configuration options get in the way of the actually important ones.
Jonathan Gordon wrote:
2008/10/28 Paul Louden [EMAIL PROTECTED]:
XavierGr wrote:
will be rejected on the shrine of binsize and the doctrine of
settings-bloat.
Can we please try to have this discussion without resorting to rhetoric and
terms like this?
apparently not... 3
how about bringing them back to a sane level like they used to be?
another thing that adds nothing. study mode only got in because it was
a drive-by-commit... oh and its still there...
Sorry but I really have to disagree with you on this one, I wouldn't
describe study mode or whatever it has
alex wallis wrote:
But you can almost certainly guarantee there will be at least one person
who say decides they want to ...
Making decisions based on the at least one (hypothetical) person
criteria is a recipe for extremes.
Sorry but I really have to disagree with you on this one, I wouldn't
describe study mode or whatever it has been renamed to as mediocre or a
useless feature.i really like the feature, its particularly useful for
moving around in large audio books especially if whoever rips them doesn't
rip
2008/10/28 Paul Louden [EMAIL PROTECTED]:
If they wouldn't make the cut, why are we even considering multifont? Why
did we add conditional viewports? Why are we interested in positional list
viewports and skinnable progress bar?
none of these have a working patch yet, and yes there will be
XavierGr wrote:
The whole discussion is summed up to: How to resolve preference
conflicts and how aggressive should the rejection policy be.
Well, in the case of skip length it solves the fact that, prior to its
existence, it was physically impossible to accurately seek in files
blindly.
Jonathan Gordon wrote:
you're putting words in my mouth... and well thats another point,
patches arent outright rejected untill they come up for discussion,
there are left to rot in the tracker.
Which word? You said we need to bring them back to sane standards. By
definition of the words
I think its time to have a proper discussion about adding settings
(and to a lesser extent, adding features which may not be used by the
vocal majority.) I'd like to keep the two topics separate but I don't
think it's really possible.
This is being prompted by XavieGr's email and patch (FS#9455)
Jonathan Gordon wrote:
1. bin increase
Well, As civil as I'd like to be, I think everyone knows my views on
this argument… Its nonsense. What's the point of the project if every
time a red delta happens everyone complains? May as well close up shop
here.
And you've heard dozens of times it's
62 matches
Mail list logo
