It works!! (umm.. i think... It seems to work for my tests...)
I have attached the diff if you want to have a look, all it does is
show my test menu which is just the shuffle option twice.. but it
proves it works...
The problem with the whole thing is its a bit messy to add an option...
i.e for
woops.. forgot the attachment
On 24/08/06, Jonathan Gordon [EMAIL PROTECTED] wrote:
It works!! (umm.. i think... It seems to work for my tests...)
I have attached the diff if you want to have a look, all it does is
show my test menu which is just the shuffle option twice.. but it
proves it
On 8/24/06, Jonathan Gordon [EMAIL PROTECTED] wrote:
Im 99% sure that the core devs despise (sp?) the idea of users being
able customize the menu order at will...
I am thinking of a way to allow users to add any avilable option to a
special user menu (I tihnk this will be very easy after the
If e.g. the options crossfeed and stereo width would be advanced
options, you'll still find them at the sound settings menu - when
you're in advanced mode.
But crossfeed is a simple option, because it`s one of the first
options I ever used and the cause I fell instantly in love with
rockbox.
On 25/08/06, Jonathan Gordon [EMAIL PROTECTED] wrote:
Right, well I've been tweaking it a bit and I think its now useable...
attached is the diff which starts adding the sound and playback
menus.. (i've ben testing on the ipod sim, and it compiles
cleanyly...)
So just quickly, I want to explain
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,
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
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 :-)
Hey all,
This idea came to me driving home from uni today and I think it may
work, but it will be pretty massive to implement, so I want to check
if it would be at least looked at if it did work.
Assuming the biggest objection to option bloat is compiled size then
this idea could possibly solve
28 matches
Mail list logo
