Home Button suggestion for menu


mjohansson

Supporter
Joined
Feb 10, 2011
Messages
409
Recently I was playing Zelda in the dark and was gonna push select to view the map, but since I couldnt see the buttons in the dark I accidentally pushed the HOME button and emulator quitted out to os without warning, I had to replay a dungeon later wich was annoying to say the least, and that made me think of mandating a standard for programs to call upp a menu screen when the HOME button is pressed so you can see an option to quit program or return.
 
I get a pop-up asking me which application I want to kill. If you cancel, you should be back in the emulator.


I can't imagine why the application would be killed right away
 
Recently I was playing Zelda in the dark and was gonna push select to view the map, but since I couldnt see the buttons in the dark I accidentally pushed the HOME button and emulator quitted out to os without warning, I had to replay a dungeon later wich was annoying to say the least, and that made me think of mandating a standard for programs to call upp a menu screen when the HOME button is pressed so you can see an option to quit program or return.

To be honest, I think your problem is not about what emulator authors should do, but more that OPT should address this issue once and for all by finally making use of the keypad LED pads on the main PCB and giving us a lit keyboard.


D.
 
There was some discussion regarding standard interfaces that included discussion into what the Pandora button should do. That thread is here.


I had suggested that the Pandora (Home?) button be used to pull up menus instead of quitting apps, while other combinations of the Pandora button and the others in the middle row would do something else:


Menu In-Emulator/Game/App: Press Pandora button


Quick Quit: Press Pandora button and Start


Force Quit: Hold Pandora button for * seconds


Would be nice to have a backlit keypad, though. I would love it if there was a replacement keymat with a translucent rubber and clear/translucent letters so LEDs could be modded into the board.
 
Last edited by a moderator:
A "best practice" for packaging sensible defaults for key-bindings might be a good idea, but "mandate" seems a bit strong - it's kind of against the open development process, and may not even possible without locking down hardware functionality.


I have to ask - can you not rebind the keys yourself? If you think other users could benefit from your changes, then maybe contact the pnd maintainer with suggestions? Even better - submit a patch?


If community collaboration is too hard, then THAT is an area we should be focusing on. Not handing down some "Pandora Ten Commandments of Development". Most of the devs seem to be available on IRC, but maybe we should have more formalised tools for users to get involved with application development. Bug trackers? Mailing lists? We do have a source repository for the core OS, but what about one for apps?


I'd love to be told we already have these tools... in that case just letting users know about them seems to be the problem.
 
Last edited by a moderator:
I wish the Pandora button worked exactly like the PS button on PSP/PS3.
Granted, but OPT starts doing many other things exactly like Sony. Soon all your PandoraNetwork information (including passwords and credit cards) are released onto the internet.


Wait... sorry, wrong thread :p
 
I've posted a few times.. the reason we don't do a fancy schmancy 'overlay' screen when you push a button, like PSP/PS3, is because it needs lots of work and we donm't have the blood to do it -- if anyone has spare timke and knows how to code, feel free :) (remember, all of this is done in spare time.)


ie: a PSP and PS3 is solely controlled by Sony, with a single way to render to the display; here, we're a general purpose machine (not just a single controlled game machine), so applications can render to framebuffer, or use GL/GLES, or use X11, or SDL, or any number of ways of getting at the screen. Doing a 'good solid' job of doing an overlay over all of that, that also handles lid open/close and properly manages input (ie: so overlay is up, input goes to overaly not to the apps underneath)... its actually quite a bit of work.


(Think about coying a file.. users think about how easy ti is -- just copy and paste a file; but in pract,ce develoeprs have to wrry about if theres space free, if the source or target is over a network and what protocols, data integrity and compression, any thousand of things. Same for overlay.. it may sound easy, but theres more to it than you think :)


jeff
 
Back
Top