Standard interfaces.


craigix

craigix

Mega GP Mania
Joined
Feb 3, 2003
Messages
11,008
Location
England
Website
twitter.com
It has been spoken about for a long time and now I'm ready to push it.


My vision is this: All emulators and programs which require selectors should have a system which is very similar to the menu system Notaz uses. Super simple and to the point.


These interfaces should use the same font and key mappings. There should be no clutter.


I realised how much we need this after giving my cousin a Pandora. He really struggled with the various menus and was confused why they were all different.


I suggest the Space bar as a way of entering the menu, although this might not be ideal in all programs. The Pandora key is out as that quits the program usually.


I'm thinking we can put up a bounty for getting this in order if someone wants to do some modifications on what we have, but I'd like to hear your thoughts.
 
isnt this what pickle launcher does already? as long as emulators have some sort of commandline ability to run this would be perfect.
 
yup agree with pickle but I think he means to edit frameskip/ save states etc in game,


I tried to make pickle launcher open different emulators depending on the file type,


e.g open pcx emu if it finds a iso,


that way you could easily make a multi emulator launcher, but after I had it working with 3 emulators I stopped working on it, emulators were changing too quickly and I would have had to change the pnd alot,


It would work but no roms could be zipped (unless the file type could be found before passing to the emulator or have the command dependant on the folder and not the file? e.g anything in /media/sdcard/roms/snes would launch snes9x
 
We talked about this (i.e. the problem, not the solution) a bit in this review thread as well.


I'm a bit afraid that not all options can be easily forced into a uniform interface though. There is nothing wrong with defining some interface guidelines, but not all environments are created equal. Native Xfce applications prefer rich desktop oriented widgets with heavy mouse and keyboard support, mini-menu is more game-control oriented and for instance Android applications would be touchscreen oriented.


These three different environments have quite a distinct look-and-feel. To me this suggests that an API should be defined for launching the emulators and changing their settings to allow the creation of various front-ends for the emulators. If the API provides an introspection interface such that functionality and settings are discoverable, then we would not need to build these front-ends into the emulators themselves. I.e. each emulator would use the same button to push the emulator into the background (pausing the game) and popup the (external) front-end for configuration through said API.


The advantage would be that only a single front-end needs to be built per environment which can automatically support multiple emulators. On the side of emulator developers, they only need to implement the API and not care about the front-end details. The disadvantage is that some emulators (e.g. the ones using plugins) have quite an extensive array of different options which are difficult to capture in a single uniform interface. Naturally, not ALL options have to be configurable through these front-ends. So perhaps we can (initially?) restrict the API to only the basic and common functionality.


Although, I don't really have a problem with the emulators in their current state. Hence, I'm not sure the effort is worth the investment.
 
Last edited by a moderator:
milkshake said:
isnt this what pickle launcher does already? as long as emulators have some sort of commandline ability to run this would be perfect.
Click to expand...

The initial selection would indeed be the same since the launcher itself doesnt change.


there are some differences, my launcher is more of a launch and forget. What i mean is that you cant go back to picklelauncher without completely quitting the current running game. Usually with built-in menus of emus the emulation is paused and the user can resume.


Writing a common built-menu for all emulators sounds like a pretty big task and a boring one.
 
meandu229 said:
It would work but no roms could be zipped (unless the file type could be found before passing to the emulator or have the command dependant on the folder and not the file? e.g anything in /media/sdcard/roms/snes would launch snes9x
Click to expand...

You are correct in a way that built-in zip support from the emulator side could not be used. The built-in zip support from the launcher side reads the files in the zip and shows them to the user to select the file to run.


So in fact someone could create a super pnd that could launch any emulator based on file type if it was in a zip or not. Provided the emulator can be controlled via command arguments.
 
While this sound like a very good idea, I'm not convinced.


All the emulators does use different video-output system (mostly GLES and SDL). The menu overlay have to support all of them.


Each emulator use different way to manage input (SDL, raw, X11, libjs, libpnd) so this need to support them all.


When the menu is displayed, the emulation have to be stopped so this will interfer with all the dynarec/interpreter of the emulators.


All this is a _large_ pile of work. (yet doable but still).


On the other hand, you've to remember that this is the "open"pandora. Open is there to remember the freedom it give. This freedom have been granted to the user but also to the hackers/coders.


Android and maemo manage to provide that consistant look/menus by forcing the coder to use a language/API.


Are we about to remove some of the coder freedom here ?
 
sebt3 said:
Are we about to remove some of the coder freedom here ?
Click to expand...
This is what worries me as well. If such a thing should be supported then I think it should be optional and based on an inter-process API (e.g. D-Bus or just a plain socket) such that at least there are no language restrictions or need to integrate with external libraries through a foreign function interface.


The initiative and control should be on the emulator side, we don't want emulators to have to interact with incoming commands at arbitrary moments in time. Only when the menu is activated from within the emulator such commands should be processed (current emulators also need to pause their game when they open their own (internal) menu).
 
While I don't think we should restrict coders, is having some sort of unified key system too much to ask? I don't think we should force anyone into a single menu style or navigation system, but I think a unified menu button (like the space bar) and consistent accept/cancel buttons would be much appreciated by new users.


It's not a huge deal, but I was certainly irked at first having x be select in one menu and then cancel in another.


If someone were to code a "one size fits all" launcher which was easy to use like picklelauncher but also had better integration like pickle said, I think that would be worth a bounty. Yes it would be a lot of work, but that's what the bounties are for, right? Nobody would be forced to use it, but I like to think that devs would opt to do so it if it were good enough.
 
I hate that "q" key exits a lot of emulators, losing my game and progress :angry: It's too close to the D-pad and I've hit by accident more then once...
 
sebt3 said:
While this sound like a very good idea, I'm not convinced.


All the emulators does use different video-output system (mostly GLES and SDL). The menu overlay have to support all of them.


Each emulator use different way to manage input (SDL, raw, X11, libjs, libpnd) so this need to support them all.


When the menu is displayed, the emulation have to be stopped so this will interfer with all the dynarec/interpreter of the emulators.


All this is a _large_ pile of work. (yet doable but still).


On the other hand, you've to remember that this is the "open"pandora. Open is there to remember the freedom it give. This freedom have been granted to the user but also to the hackers/coders.


Android and maemo manage to provide that consistent look/menus by forcing the coder to use a language/API.


Are we about to remove some of the coder freedom here ?
Click to expand...
Sebt3 - Totally agree with you. I wouldn't want any developer to not do something if they thought the Pandora crampt their style.


However there is a serious point here. I have just been using my Gp2x on the train this afternoon jumping from one emm to the other. Nightmare trying to work out the layouts. This is something I find hard to do.


A good Standard, or code of practice would/should be agreed by you top devs.


Usage is optional but some consistency would be most user friendly. End user, your target audience, speaking here. :p


We are just starting out and if this sort of thing is going to fly then it needs the work and buy-in soon.


It may be we start with a different menu system for each variation but these should attempt to behave and look the same.


I do like notaz's style when it comes to menus.
 
Well, this device is not really made for "Cousins"! That's why I like it, let's not get "STEVE JOBS" crap going here. :p


Now with that being said, when SteveM was touching up Mame4All, a lot of the suggestions came from users who liked certain things in other emu's, and he put them in. Now MAME has a set user interface in place, but the added touches made it shine. It works a little differant than Notaz's front ends, but I still find it easy to use.


I know a lot of the Pandora's emu's are quick ports, and a lot of time has not been spent making them universal or to improve the menu systems in place. I'm a long time open source user, and some of this stuff defies logic even for me. I don't want to take away a programmers creativity, but a few things should be standard in every emu. Stuff like "space" for menu is a good idea.


The great thing about the Pandora is a full keyboard, and sadly most of our ports come from lesser devices that don't have one. Most PC emu's have similar hot keys, as they all have a keyboard. So we should be moving more in that direction for sure. Now how we get there is up in the air, but I like the idea.


Chris
 
As an end user, I have to say my favorite interface so far is the one in Picodrive and PCSX ReARMed. Clean, simple, and fast. It would be awesome if more emulators sported a similar frontend, but that's naturally up to the coders if they want to adopt it or not.
 
This isn't some bloody attack or set of restrictions on open source, its common sense.


Look at Mupen, the menu system is horrible. Even I sometimes am not quite sure if I've clicked or set something in it.


Some other programs I was not even able to get to run because of the mystery of the internal menu or sometimes the lack of one altogether.


Personally I believe less is more, I'd rather have fewer programs for the Pandora if they had better interfaces and ease of use.


You could argue that the PND system is restricting your open source ideals, but I don't see that now it's established.


The same will be true of a proper set of interface rules.


If we get this going now it's one less thing to worry about later, or for a Pandora2.
 
Dead1nside said:
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?
Click to expand...

Because I want to hear your opinions.


I think picklelauncher could be used for a lot of programs, and I saw someone has tried to make Mupen work with it.
 
You must log in or register to reply here.

Similar threads

God Ginrai
  • Poll
Pandora Key As Universal Menu Key Part 2
2
Replies
23
Views
3K
emil10001
emil10001
Loon
Standard Proposal - Exit Application
2
Replies
32
Views
3K
tazg
T
foxblock
Standardized Controls
4 5 6
Replies
116
Views
13K
Neelix
Neelix
R
Clutter Toolkit
Replies
3
Views
1K
DDd
D
Wrath Of Khan
Proper Bounty Section on new Website?
2
Replies
24
Views
3K
erico
erico
Back
Top