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 signifi
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 e
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
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
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
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 binsi
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
Roy Wallace wrote:
Using your terms, Paul, it would seem there is disagreement in how
important "usefulness density" is as a goal. For example, the World
Wide Web has an extremely low "usefulness density", but is very
useful. Of course, the importance of usefulness density wholly depends
on
On Wed, Oct 29, 2008 at 10:02 AM, Paul Louden <[EMAIL PROTECTED]> wrote:
> 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."
>
Usin
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 be
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 hones
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 e
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
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 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? D
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
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).
I
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 i
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 t
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
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. S
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
>
> 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
>
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.
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 be
Jonathan Gordon wrote:
how about bringing them back to a sane level like they used to be?
18months ago we wernt having this disucssion, filetype colours, icons
in menus, and then custom icons happened. Would these have going in
today? I doubt it. the improved (read: pretty) line selector is
anoth
2008/10/28 Paul Louden <[EMAIL PROTECTED]>:
> Honestly, if you're going to disagree with me, I'd appreciate you not go off
> on silly tangents. The question of maturity was, again, in terms of not
> *lowering* standards for the sake of an increased rate. Which is what this
> whole discussion is abo
> 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.
The context of the subject is perpetual so sorry for moving in circles.
Who is go
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
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.
> 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
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
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 agr
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 jok
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
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 m
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
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 Coldfire-
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 tho
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 sim
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 who
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 b
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.
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 b
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
>
> 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. Bu
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 mai
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 stoppin
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 proposin
alex wallis schrieb:
However I do like the idea of settings being loaded by default even if
it meant a bit of work to implement.
I can see one problem with that though, and that is what happens for
example if you want to have something like battery bench running? I no
people won't use that plug
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 pl
pondlife schrieb:
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.
I too suggested that some time ago, and the idea was rejected for
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
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 plug
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
shouldn
For what it's worth, and probably not very much, I think a settings plugin is a
great idea if that will reduce binsize and free up buffer memory. A settings
plugin could be used for all settings options, not just the less commonly used
ones. Selecting Settings in the main menu brings up the s
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
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
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 y
Hi Alex,
> As for stripping out useless features, if we want to save bin size or just
> in general cut down on compile time, why don't we strip out doom? I mean
> doom is a bit of an old game now, takes ages to compile and I seriously
> can't imagine a majority of people play doom on there mp3
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.
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 o
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 abo
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 d
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 only
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.
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
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 be
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
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
70 matches
Mail list logo
