Support and General Use > User Interface and Voice
New patch: Settings Display Within Menus. DONE!
Rincewind:
I get a compile error with your patch.
*** No rule to make target 'select.c'
You added 'select.c' to apps/SOURCES, but this file is located in apps/gui/
I changed the line to 'gui/select.c'. This worked, but I get a lot of compiler warnings and some more errors.
Do you get them too or is there a problem with my build?
I only applied your patch and tried to compile a H120 Simulator
AM:
--- Quote from: Rincewind on August 20, 2006, 10:32:15 AM ---I get a compile error with your patch.
*** No rule to make target 'select.c'
You added 'select.c' to apps/SOURCES, but this file is located in apps/gui/
I changed the line to 'gui/select.c'. This worked, but I get a lot of compiler warnings and some more errors.
Do you get them too or is there a problem with my build?
I only applied your patch and tried to compile a H120 Simulator
--- End quote ---
Damn. Actually no, the problem was that in the latest patch I forgot to include select.c and select.h :-[, these are new files that should be in apps. The select.c and select.h in apps/gui/ on the other hand have been obsolete since the setting selection list was included in CVS and should be deleted. I've now uploaded the (hopefully this time) corrected patch.
Rincewind:
It is working now.
One small suggestion: How about adding the submenu indicator ( > ) in the "always" and "for selected only" modes, too?
AM:
--- Quote from: Rincewind on August 20, 2006, 12:04:01 PM ---It is working now.
One small suggestion: How about adding the submenu indicator ( > ) in the "always" and "for selected only" modes, too?
--- End quote ---
I've done some thinking about that, but I'm still undecided. Theres already the risk of the screen feeling cluttered with the single line setting as it is, and turning it on for those modes too increases that further imo.
While on the subject, currently the ">" doesn't actually tell you it's a submenu, just that it's not a setting. Do we want that to be handled differently for menu items that actually open submenus vs ones that perform actions? And should there in that case be a different indicator for menu items that perform actions or just no indicator at all (personally I don't like the look of empty lines in a menu)?
If we opt for any of this I'd be happy to implement support for this, but I don't feel like going through all the menus once again to designate which options are actions vs. submenus. It would be dead easy to (anyone could do it), just tiresome and time consuming...
Rincewind:
differentiating between actions and submenu items would be useful.
My first thought for actions was an asterisk * but I don't know if I really like it.
There are not that many actions, i can only think of Radio, Recording Screen, Graphic EQ, Rockbox Info, View Current Playlist.
But there is Browse cfg files, plugins, themes etc, which is not really a submenu. I don't know how we should handle these.
I just don't like it when there is 'something' for some items and nothing for others on the right side of the screen.
btw, a graphic for > would be cool, but this has to be in different font sizes...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version