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
Daniel Stenberg wrote:
On Wed, 24 Sep 2008, Stephen Harker wrote:
So, in short, can you please update your DNS so that the one A record
in the RR DNS corresponding to our server:
download.rockbox.org.A216.116.68.8
Thanks, this is now done!
Hi me again, can you change the A record
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
50 matches
Mail list logo
