Jonathan Gordon wrote:
So, Does this idea sound workable and do you like it?
I agree that the setting menu code could be made simpler and more
flexible, and your idea is as good as any other.
However, I don't think it needs to be done offline with a text file
and a script. I believe we
Hi,
Jonathan Gordon wrote:
My idea in a nutshell is have a text file (xml, or whatever) which is
converted to const arrays of some stuct (this detail needs to be
worked out) during the compilation by perl or whatever.
using the example above that item might look like this in the xml file
The
On 23/08/06, Tomas Salfischberger [EMAIL PROTECTED] wrote:
Hi,
Jonathan Gordon wrote:
My idea in a nutshell is have a text file (xml, or whatever) which is
converted to const arrays of some stuct (this detail needs to be
worked out) during the compilation by perl or whatever.
using the
On 23/08/06, Daniel Stenberg [EMAIL PROTECTED] wrote:
On Wed, 23 Aug 2006, Jonathan Gordon wrote:
I think I forgot to mention the reason for the text/xml file was so
that the entire menu structure could be done in the one file. e.g
I think XML is terrible when meant for humans to read and
Daniel Stenberg wrote:
Also, your approach seems to mostly focus how to remove unnecessary
lines in the menu code but the option bloat is also due to all little
support-functions etc that each little thing requires and not only for
the little lines in the actual menu, and I didn't see your
On Wed, 23 Aug 2006, Jonas H wrote:
Furthermore, option bloat in my eyes is more than just code-size and
code-readability. It's also the fact, that too many options make baby Jesus
cry. Or at least, it makes it harder to find what you're looking for.
Yes indeed.
Of course, in that case,
On 8/23/06, Jonas H [EMAIL PROTECTED] wrote:
Of course, in that case, people will be unable to change certain optionswithout having to use a computer. Maybe some sort of .cfg-file editorplugin could be created, which would then expose all available options
(or maybe just the hidden ones).What,
I'm increasingly of the opinion that it might be a good idea,
usability-wise if the menus were trimmed, and some of the more esoteric
options only were available through .cfg files or similar.
I strongly disagree with this idea. One man's esoteric is another man's
essential.
I don't
Jonas H wrote:
Jonathan Gordon wrote:
This is a bad option.. all settings should be available on the DAP. A
nicer option is maybe having 2 sets of options, simple and
advanced where the only difference is some options are not visible
in simple mode.
The reason I dislike (despise is
Andreas Stemmer wrote:
I foresee long discussions about which options should be kept in
place...
Steve Bavin wrote:
I strongly disagree with this idea. One man's esoteric is another man's
essential.
Of course, but if we were to eventually decide to move some options out
of the main menu,
The challenge is of course to identify which options are useless for
most, and only essential for a small group to make the remaining setting
relevant to as man people as possible. Of course it should also be taken
into considerations which options are used often, and which are used
rarely.
I
One option is to move all the playback options out of the main menu, and into the WPS context menu, as well as any of the options in the sound menu which don't affect audio in plugins with audio (for example, is bass and treble applied to gameboy games? I really don't know the answer to this one.)
Paul Louden wrote:
One option is to move all the playback options out of the main menu,
and into the WPS context menu, as well as any of the options in the
sound menu which don't affect audio in plugins with audio (for
example, is bass and treble applied to gameboy games? I really don't
know
No, all options would be in the main menu.But the context menu would have all applicable options to the current context. So, while playing music, you can go to the context menu for what would be a Simple menu, while the main menu is the Advanced on still containing all possible options on the
On 8/23/06, Jonas H [EMAIL PROTECTED] wrote:
That's of course an option, but it'd be much nicer to have a dedicated.cfg editor, that allowed you to see the possible values, so youwouldn't have to type them out, you could just select them. I imaginedsomething like the text viewer, except with a
On 8/23/06, *Jonas H* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
That's of course an option, but it'd be much nicer to have a dedicated
.cfg editor, that allowed you to see the possible values, so you
wouldn't have to type them out, you could just select them. I imagined
This is a bad option.. all settings should be available on the DAP. A
nicer option is maybe having 2 sets of options, simple and
advanced where the only difference is some options are not visible
in simple mode.
I like the idea!
The reason I dislike (despise is probably closer, in fact) the
I like the firefox about:config setting screen as well and I think
rockbox would benefit from something similer.
... and I don't like it at all.
I hate to have to search different places for the option I want.
IMHO this is even worse than having simple/advanced settings.
Can't we just sort
My point is, that when you have the simple view, and turn on advanced, a
bunch of settings just appeared, and you have no idea which, or where
they are. This makes it, in my eyes, more confusing than simply always
having all options available.
Another option is having options grayed out if
I think that a simple/advanced scheme does not solve any problems at all.First: The problem of having a hard time finding options. In the simple scheme they will theoretically be just as hard to find, they're just harder to find in a shorter list on the page they're on.
Second: You don't know
My point is, that when you have the simple view, and turn on advanced, a
bunch of settings just appeared, and you have no idea which, or where
they are. This makes it, in my eyes, more confusing than simply always
having all options available.
Another option is having options grayed out if
My opinion is that Rockbox menus are just plain Great!Lots of options for serious users. Plain and simple menus that allow the user to modify his DAP like no-other player. Of course a little discussion to where each menu should be or optimisation of the menu system would be welcome.
All the users
I agree with completely with XavierGr, rockbox menus are great as they
are and don't need a complete rework.
A few settings that you only set once (beep volume, anti skip buffer,
battery...) should be put further down,. Other options, that toggle
functions, for instance crossfade, eq, replaygain,
I think most things you've mentioned as possibly going in a quick settings menu actually fit better in the Context Menu (and in fact several of them already are).On 8/23/06,
Simon M. [EMAIL PROTECTED] wrote:
I agree with completely with XavierGr, rockbox menus are great as theyare and don't need
On 8/23/06, Jonathan Gordon [EMAIL PROTECTED] wrote:
Oh, the text file is not needed... I was just testing you all :D
But I liked the idea with the text file...
this could be made into a wms file - while menu screen :-)
On 8/23/06, Paul Louden [EMAIL PROTECTED] wrote:
I think most things you've mentioned as possibly going in a quick settings
menu actually fit better in the Context Menu (and in fact several of them
already are).
you're right, but i don't know why, but i find the context menu harder
to reach
Sound/playback settings are hardly context independent. The only setting you suggested that was actually context independent was Sleep Timer, and that's actually playback, FM Radio, and Recording too. All other contexts, the idle timer will come first, or you're involved with direct input such as
Simon M. wrote:
As I am writing this, I have a new idea:
I think it would be nice to have shortcut menu where you can toggle
features of rockbox on and of: crossfeed, replaygain, crossfade, eq,
shuffle, repeat, party mode, file view, sleep timer (not a toggle but
i'd like it there)... In the
I strongly agree with the notion of frequently changing vs. set-once
options.
A couple of related ideas:
- Sort options by last access time (after a while, your personal favorites
will always be on top)
- Have a MRU (most recently used) options submenu.
R.
-Original Message-
From:
I would strongly object to this. Imho, for blind folks (as well as
folks using Rockbox while driving in a car), having static menus that
don't reorganise themselves (or at least are predictable) is much more
preferable and easier to navigate. It's also safer for the car driver who
doesn't
MRU is a great idea! That's more flexible than my idea and has the
same effect eventually.
NOOO!
I already hate those personalized menus in Windows and Office.
It's one of the first options I always disable.
I don't like it when menus change (hide) without my impact.
with regards,
Linus wrote:
Linus I guess I can answer both questions at once: the idea that I
Linus and Daniel had was to stop the Player development. Therefore we
Linus wouldn't need a daily build for it anymore.
OK. I thought there could be parts of the Player that for instance
could be shared with the
Hello Rockbox Developers,
This is my first post to this mailing list. If this email is inappropriate
please let me know.
Note: This suggestion is dependant on having the remote buttons working in
the UI Simulator.
The iRiver H1xx and H3xx targets share the same remote connector. There are
33 matches
Mail list logo
