Standard interfaces.

[hakmanplayer]

I sir Craigix am JUST like your cousin.


What you typed would be a dream come true for me.


I wish i could help the cause but unfortunately, i am not technical enough.


I do love my Pandora very much and what i can do with it it does superbly.

 

[mhadf]

A standard interface would be nice across the various emulators.


As mentioned before as long as the emulator can accept commandline arguments it would be good with a seperated interface ala Picklelauncher.

 

[-Tj-]

I don't have my Pandora yet, but I've been using emulators on various devices for well over a decade now and do have some opinions on this matter that I hope will be useful.


For starters, I'm with those that aren't completely convinced by the idea of a 'standard'. Reasons being:


- Not all emulators use or have the same number of buttons. One emulator might need a key for input that other emulators use as a menu command.


- Different emulators have different options and requirements. Several emulators might have the same options but in others it may not even exist.


- It takes away the individual feel of different emulators. Individuality can lead to innovation.


However, I do think it'd be nice to have a sort of list of 'accepted' rules that coders could follow for meuns. Many emulators share similar layouts for buttons, and I find that very helpful when going from one emulator to another. I also find this very helpful while playing homebrew games.


More important to me overall is having a list of menus that carry over from emulator to emulator, or even game to game, much in the way most menus in almost every program on the market have File and Edit menus. I would love to see some discussion on that front especially.


Regarding the Space key, I don't like the idea of the it being the 'default' menu key. At least in a few emulators I've used in the past, especially several systems that use a keyboard, the Space key is used as a game button. While these can obviously be remapped, if there is going to be a standard, I'd rather it not be the Space key.


Is the Pandora button hard-coded as the "quit" command? If it isn't, I feel like that should be the default button for "menu", and perhaps a combination of the Pandora button and some other key as the "quit" command. This way getting to the menu is ambidextrous, easy, isn't in the way of any other buttons, and doesn't quit your game if you press it by accident. Then from there, you could have Exit or Quit as part of the menu that pops up, which is what nearly every emulator I've used does (and when it doesn't I tend to get frustrated). In this sense it'd be similar to the Xbox button on the 360, Home key on the PSP, or the PS button on the PS3.


If you wanted to quickly quit, having something like Start + Pandora button might be a good option as quick way of quitting, and is a key combination that can't be easily hit at the same time by one hand. Another option might be to hold the Pandora key to quit emulators or games quickly, and if this delay could be some kind of modifiable option outside all emulators it could be set to user preference across all programs.


EDIT:


After some thought and checking out the other threads, I think I'd like this:


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


Quick Quit: Press Pandora button and Start


Force Quit: Hold Pandora button for * seconds

 

[bzar]

I suggest UI guidelines. Use this button to do this. Use these menu structures where applicable. Use these layouts for dialogs. That sort of things. Hard rules or actual uniform menu code (more integrated than the pickle launcher) is more likely to be disregarded and forgotten. Let's first try to get something we can agree on and can work with (in any context and/or ui). When we have proven concepts, we can think about a truly uniform interface. Baby steps.

 

[Caine]

I suggest UI guidelines.

Yes, that's the least we should do. As to which button should be utilized, this thread from the gp32x boards springs to mind.

 

[the_marshal]

Guideline representing which button should be used for what function sound like a good idea to me. Having a more consistent key mapping would already go a long way to not confuse users.


Uniform interface across emulator is not a major concern for me. Pickle launcher is a good choice but as far I am concerned it should just be simple enough to navigate easily.


Also it's not all about emulator, it's also about other home-brew and open-souce game... they could also follow the guideline if desired.


I also have a idea but I don't know how hard it would be to implement. It would be a in-game help. Press a specific button or combination and a help would pop-up (an overlay) explaining the key mapping and maybe some other info on how to use the software. I know PND have support for documentation but a small in-game help would make is great for explaining the key mapping and some other basics. It could consist of a few full screen picture. The idea is that you would just need to "drop" png file into the .pnd and add some XML and magic happens.


I have no idea if there is even a way of implementing an overlay system that would work on all application though.


If an overlay is not possible maybe it could be displayed at start-up (with a skip button). That would be before the actual application starts. There could be a overall switch to turn with help on or off (never display / display on first launch only / always display)

 

[Asiyura]

I agree with the fact that emulators and softwares for pandora should follow some basics design guidelines.


That's why, LukeVP and I, we wanted to start making a unified look and feel for emulators (some kind of library that would be easy to implement in existing softs).


But we are waiting for our Pandoras.


And since I'm a late first batcher at ED's shop, the wait will be a tad longer than I would like.

 

[fearofshorts]

Yeah. We definitely need a common set of interface conventions. Whether or not this should be forced is another thing.


But may I suggest something-


Give us an OS-exclusive button combination by default (remappable, of course). Like Control-Alt-Delete on a windows machine, I think that we need at least one way of accessing the higher levels of the OS if we lose control of a full-screen program. Plus all sorts of helpful features could be tucked away into a nice menu opened via this combo: program-switching, quick access to the backlight and wifi settings, the time and remaining battery life could be shown, a task manager...


It just seems like a nice idea to me.


Now, back on to the topic of interfaces, we should be using things which seem intuitive. Particularly to people who've used other handhelds before (as big-name handhelds tend to get interfaces right) as well as those who've used a PC.


My standards suggestions (complete with conflicting mappings: just pick one or several, the user can work it out quickly)-


Move up/down/left/right in menu-


dpad, nubs


Select menuitem/file-


A (button), Return, Space, click on it


Exit level of menu/window-


B (button), Escape, click "cancel" (or the like)


Pause game/open pause menu-


Pandora (button), Start (for non-emulators, for which this should be the in-game pause menu)


Quit program-


Accessed through menus, always available and always in the same part of each highest-level menu. Force quitting should be handled by the OS- this is a last resort, not a common occurrence.


Finally, as to how these standards should be encouraged: Don't force coders to use them. Place them on key websites prominently and make them well understood. Create an API for file browsing which adhires to your standards (if someone uses this, then they'd feel foolish to use a different set of standards). OP team- I think that you hold the most authority here, so pick a set of standards (just make sure that there are still some options).


Sorry for this mess of a post.

 

[SNESFAN]

Just want to say thanks for addressing what I find to be the pandoras biggest downfall.


If I can make a novice suggestion, but perhaps creating a menu interface framework in the sdk that programmers can use, rather than have to use might be better. Out of all the emulator front ends/in game menu I prefer notaz's psx emulator or mame4all my tip of the hat goes to notaz's for the way he does the save state screen shot and last loaded rom on startup. If that is open sourced then perhaps that can be added to the pandora sdk?


As far as forced standard buttons, user configurable buttons for action and nubs, fn buttons etc. But system buttons should be forced standard. Space bar makes a good universal menu and pandora a good "home" key or quit to desktop. Forcing some buttons might reduce freedom in the same way that all software be a pnd though. The pandora os shouldn't require it, but to be listed in the app store thing it should meet the standards. The android market does this, it has a couple requirements, not be malicious and conform to button and sdk standards. You can program outside of those guidelines and distribute and install by any other distributor you choose but to be listed in the market you must play by their minimal set of rules. This gives the user the piece of mind knowing everything they download from that source will behave in at least one or two familiar ways.


Right now there really is only one major emulator for each system being emulated, and all a programmer would have to do would be to basically say "no" and that console or whatever would not be in the app store. How to redo each previous emulator and rebuild the way each one works for abandoned or no longer maintained emulators? I think this is the problem that is being presented as the biggest hurdle. But I agree this needs to be sorted out sooner rather than later or it's going to cause more and more fragmentation.

 

[McLovin]

Picklelauncher is a nice start, though I don't understand the interface to it's fullest. like - what about the arrows to the left with the colorful buttons? I'd rather have a info bar that tells me which button does what at this state.


Notaz's interface is close to optimal, though a little inconsistent between picodrive and pcsx. And I'd totally prefer x over b to apply.


Noone can tell a dev what to do, but we can define standards and create a design-document with additional info like sdl-descriptors. My guess is that most devs will be glad about such a document. The dev-fund could be used to motivate the devs to adopt their existing software to this standards.

 

[Linux-SWAT]

For the UI, i prefer the Notaz's interface since my GP2X.


For the "special" buttons, we must keep in mind it must not interfere with the emulated system (ie amiga keyboard), i mean it should be linked to pandora button, or must be an unused combination of other keys, ie Fn + ctrl, or Fn + L/R etc...

 

[Dead1nside]

Why don't you speak to the devs who've already done work on interfaces, like Pickle and Skeezix and Notaz, who you've mentioned?

Because I want to hear your opinions.

There's nothing wrong with that, that wasn't my point, it's a good thing to consult. I just think if anyone should get bounties then the opportunity should be given to existing devs first, since they're the ones who've already done so much for the Pandora.

 

[chris_c]

stumbled upon this http://gelide.sourceforge.net/index.php?sect=home&lang=en


The other option would be to beef up the pickle launcher and to encourage people to use it by documenting it extensivly from the new to pickle launcher developers view point, so on the wiki


a clear indication of what expected behaviour should be, would also be an idea, one pet peave is the pandora button quiting with out asking for confirmation....

 

[PokeParadox]

I agree with the idea to an extent... I said long before rolling out the Pandoras that one problem with GP2X was lack of standards in controls and interfaces...


But generally this is met with we will do what we want.


This is something that could have been at least partly resolved with a Pandora API, providing system menuing facilities (Like return to Wii system menu, etc) and providing button abstractions (Accept Button, Cancel Button)


So I hate to say I told you so, but I told you so and it's a bit late not... to completely too late, but this should have been tackled before really.

 

[double7]

Craig, you will encounter a general problem of different user preferences. Everybody wants "his best" keyboard config.


To serve them all, i would suggest standard variables set with ascii style config. Unusuable example:

menu=pandora-key

quit_emu=L-shoulder+R-shoulder+select


selector_up=dpad-up

selector_down=dpad-down


selector_pageup=L-shoulder

selector_pagedown=R-shoulder


#selector_pageup=dpad-up

#selector_pagedown=dpad-down

The emulators could search this from a default location followed by the appdata directory.


This way everybody can use his prefered configuration and is not "forced" to (in his opinion) uncomfortable settings.


I don't know how developers think about this, but it is another kind of communication if you say "do the menu button on the pandora key" or "could you support the standard configuration file?"


This way will satisfy all of us - you can deliver a standard config - users will have unitary ((uniform?)) selector controls - and can modfiy them to their personal needs for all emulators at once or via appdata specialized for every emulator.

 

[notaz]

I really doubt you can ever achieve this, with bounties or not.


The vast majority of software are ports, software designed specifically for pandora is more or less non-existent. The ports come with whatever frontends they originally had, which is mostly PC-like interfaces (Mupen), or GP2X/Dingoo/whatever (SNES9x4P). Even if we had standard menu available at the system level (libpnd or whatever), I still doubt this would happen, as that needs additional effort to integrate (compared to the usual straightforward recompile-and-fix-resolution-and-controls thing). Not to mention the menu itself would need some work to accommodate various things various emus can use (hardware scaler, gles mode, likely more).


Hell, look at those ginge'd emus in the appstore, there is no one to do basic ports even, and you are talking about menu unification already.

 

[renegadechic]

look and feature-wise this doesnt really float for me. i actually like all the different designs for UIs. variety is the spice of life, etc. if there is an argument for anything, however, for me it would be how you control that interface once you are in it. a standard way to quit, a standard way to bring up a menu, standard way to pause, browse folders, etc. it took me ages to work out how to exit psx4all when i first got it. that stuff at the very least should be a no brainer.

 

[PokeParadox]

I'd like to make a suggestion... let's get a set of controls at least which are "standard" (along with a something like what double7 suggested into the OS)


There should be more hooks in place at OS level to help with this sort of thing. Wii homebrew is more standardised than us and we are a completely open system...


Any app that meets the standard can get "OpenPandora Stamp of Approval" as their status and maybe a badge to display on their splash screen.

 

[White Demon]

My pet peeve with most of the emulators is that they expect you to put all your roms/disk images in a specific folder within their specific appdata folder. I like to store all my roms in one place - a 'roms' folder, which I have made and then put all the different emulator formats in there under their own folder - C64, Amiga, Megadrive, SNES etc. I like to do this so I don't have roms scattered all over the SD card and making them hard to find - instead everything is in one single place and I know exactly where to look/what for when housekeeping, adding/removing roms etc. (BIOS files, where required, are fine though - I am OK with them going in the appdata folder)


Some of the emulators allow me to navigate to where my roms are stored, sure, but I have to do this every single time I select a new rom to load, even if I have not exited the emulator after already playing a game.


Then there's the few that don't even allow this - they expect the roms to be in their own appdata folder and nowhere else. What's even more confusing in this situation is that this 'roms' folder isn't made until after the emulator is run the first time.


Can't the emulator authors make some sort of setting in their config menu/ini file to let us select the default location for it to automatically look for roms first? Or, at the very least, remember the last folder used to load from - this is what Picodrive does, and it's very handy instead of having to navigate through a whole stack of folders every single time I want to load something.

 

[Nintendo]

My pet peeve with most of the emulators is that they expect you to put all your roms/disk images in a specific folder within their specific appdata folder. I like to store all my roms in one place - a 'roms' folder, which I have made and then put all the different emulator formats in there under their own folder - C64, Amiga, Megadrive, SNES etc. I like to do this so I don't have roms scattered all over the SD card and making them hard to find - instead everything is in one single place and I know exactly where to look/what for when housekeeping, adding/removing roms etc. (BIOS files, where required, are fine though - I am OK with them going in the appdata folder)


Some of the emulators allow me to navigate to where my roms are stored, sure, but I have to do this every single time I select a new rom to load, even if I have not exited the emulator after already playing a game.


Then there's the few that don't even allow this - they expect the roms to be in their own appdata folder and nowhere else. What's even more confusing in this situation is that this 'roms' folder isn't made until after the emulator is run the first time.


Can't the emulator authors make some sort of setting in their config menu/ini file to let us select the default location for it to automatically look for roms first? Or, at the very least, remember the last folder used to load from - this is what Picodrive does, and it's very handy instead of having to navigate through a whole stack of folders every single time I want to load something.

Huh? You can put ROMS anywhere though?