The 'select' Button


foft said:
As for non-overridable functions - to ensure programs can always be exited etc - the idea makes sense. But how about a combination, then emulators are free to use the raw keypresses how they choose. Something like ctrl-alt-del or ctrl-amiga-amiga but mapped nicely to the pandora keyboard. A combination would also be better from the perspective of accidentally hitting the exit/switch app button.
Hence my reasoning of having to hold down a button for 1.5 secs or so. That way a accidental hit doesn't switch programs, and allows the app to something with it instead.

Leave start/select to be sent through to the emulated game, if any. Single tap menu = Emu menu/pause, again = Leave emu menu/resume.

If you really need to switch programs, you just hold it down.
 
Last edited by a moderator:
Gilrad said:
If you really want to go obscure gaming references, you could call it 'Mode' :)
I vote for "Mode". 6-button Genny pad homage. ;)
 
Last edited by a moderator:
I came to post my idea in this thread, but squidge had already had it!

Start -> passed to running program
Select -> passed to running program
Pandora button < 1.5s -> show application-specific menu
Pandora button > 1.5s -> show pandora menu, allow exit-to-menu, switch between programs, turning off pandora etc.
 
Chip said:
fusion_power said:
Chip said:
If Pandora is going to have a truly multitasking OS, then there needs to be a button that switches between tasks. Call it whatever you want, but one of those three buttons needs to either cycle through active programs or bring up a program switcher window.
I plan to use the SHOULDER BUTTONS for this. Fits much much better for tab-switching than another Button. See Gmenu2X onto the GP2X. ;)


I think you misunderstand. I mean that you need a button that lets you switch between already running tasks. If you're in an SNES emulator and want to switch out to another running program, or GMenu (or whatever the main UI is) to start something else, you need a button that lets you do it. L and R are going to have program-defined functions, so they're no good. The system button needs to be hooked directly into the firmware so that no matter what program you're running, you can hit the button and get to other running programs or the main UI.


Ah, ok. I'm not a big fan of Multi-Tasking so I havent thought about this. But switching out of a program this way (forced with a special Button) requires an automatic stop/pause function. If you are into a Game and in heavy fight etc. it is not very good to go out without pausing the Game/application. :D So EVERY Application needs a automatic pause when switching tabs and I doubt that the (most) coders thinking onto this. ^_^
 
Last edited by a moderator:
fusion_power said:
Ah, ok. I'm not a big fan of Multi-Tasking so I havent thought about this. But switching out of a program this way (forced with a special Button) requires an automatic stop/pause function. If you are into a Game and in heavy fight etc. it is not very good to go out without pausing the Game/application. :D So EVERY Application needs a automatic pause when switching tabs and I doubt that the (most) coders thinking onto this. ^_^
CODE
{
you_bloody_well_start_sleeping();
}
 
Last edited by a moderator:
fusion_power said:
Ah, ok. I'm not a big fan of Multi-Tasking so I havent thought about this. But switching out of a program this way (forced with a special Button) requires an automatic stop/pause function. If you are into a Game and in heavy fight etc. it is not very good to go out without pausing the Game/application. :D So EVERY Application needs a automatic pause when switching tabs and I doubt that the (most) coders thinking onto this. ^_^
No, only some of them - for instance, I imagine you'd want Pidgin or your MP3 program to keep going in the background.

And to be fair, as long as there is *some* pause funtion, it need not really be automatic. Just pause the program before you shift out of it. Though I can see that in some instances, an autopause funtion would be preferable to such...
 
Last edited by a moderator:
MWeston said:
Here's my opinion:

START and SELECT are generic and mapped however any program wants to use them. In an emulator they are exactly what they say. In a web browser, SELECT could switch tabs if multiple pages are open. These buttons can be anything to any program.

The MENU button (now considering a Pandora logo, how cool is that? :)) would be tied to the OS. Obviously, hitting it should not automatically kick you out of anything because mistakes happen but it could bring up a task manager that you can use to switch between tasks, kill tasks, go into standby (power button can do that too), enter a kernel menu with all kinds of stuff (like what to do when lid gets closed of power button cycled) or just cancel and go back to the current task running. To me that seems really handy, what do others think?
MWeston said:
Actually, I like the idea of the software application not being able to control that button. It might be a nice way to get out of a stuck program as long as the kernel isn't crashed. Plus it kind of is like the HOME button on the PSP and it should always have the same function on everyone's system all the times.
Late commenting here, but I think this is perfect. And the addition of a Pandora button (as opposed to a Menu button) will add the perfect touch to the handheld. Also, as Ayla wrote, I think the button layout should be (top - bottom):

<Pandora>
<Select>
<Start>

Since Start and select would be used more often, and this would put the less used Pandora button out of the way, meaning it would not get pressed accidentally.
 
Last edited by a moderator:
Squidge said:
MWeston said:
The MENU button (now considering a Pandora logo, how cool is that? :)) would be tied to the OS. Obviously, hitting it should not automatically kick you out of anything because mistakes happen but it could bring up a task manager that you can use to switch between tasks, kill tasks, go into standby (power button can do that too), enter a kernel menu with all kinds of stuff (like what to do when lid gets closed of power button cycled) or just cancel and go back to the current task running. To me that seems really handy, what do others think?
START & SELECT as you say.

How about a slight modification for the "MENU" button however - A quick press of "MENU" goes to the app to show something application-specific. A press and hold "MENU" for say 1.5sec or so however, and it gets handled by the OS to bring up a OS menu. That way it has two useful functions (which both the same kinda thing). The button could then be used as a standard to pause a game or emu and go back to the menu menu of that game/emu.

I realise SELECT could also be used for in game/emu menus, but wouldn't it be more intuitive to have a button called MENU to bring up the menu?

I'm with Squidge on this one..

Select Press = Select in program being used
Select + Hold = Universal program swap (Alt+Tab type)

Start Press = Start in program being used
Start + Hold = Universal pause in system software (pauses all currently running software)

Menu Press = Menu in program being used
Menu + Hold = Universal system menu

I like the sound of a Pandora button but Select, Start and Menu are more intuitive for the user. The keyboard already has an modifier key, so nothing will be lost by not making yet another one.

EDIT: I'd also go for the order of..
Menu
Select
Start
..for the reasons already given :)
 
Last edited by a moderator:
No Hold option : too difficult for many persons like me ( i'm really too slow on typing ) , i prefer the use of a modifier key like 'Shift' or 'Fn' ( maybe options in Bios always ;) )

we could have

< Menu > and under on case
Pandora OS

<Start>
Pause

<Select>
Swap
 
Arialia said:
No Hold option : too difficult for many persons like me ( i'm really too slow on typing ) , i prefer the use of a modifier key like 'Shift' or 'Fn' ( maybe options in Bios always ;) )

we could have

< Menu > and under on case
Pandora OS

<Start>
Pause

<Select>
Swap
I could live with the FN modifier key being used instead of holding the buttons. As long as you can't hit them by accident, I don't suppose it really matters :)
 
Last edited by a moderator:
I'm okay with 'hold pandora button' options, so long as there is a faster way to switch apps. It's a great way to force switch if you're in an emulator, and want to say look up something on a guide, but if I'm browsing while listening to music, then I run into a song on my playlist that I don't feel like listening to, it would be easier if there were a combination (ctrl+pandora?) to quickly switch processes.
 
Just thought of something..

@Craigix - It was originally said that the keyboard would be locked out in most applications, so people don't hit the keys by accident when using the controls. How are you planning on implementing this?
Can you lock out the rest of the keyboard but leave the FN modifier key usable (as it doesn't do anything when pressed by itself), or will you have to lock out every keyboard key and just have the game controls, volume control and middle buttons usable?
 
I think you should call it...

DO NOT PRESS THIS BUTTON1!!
 
Last edited by a moderator:
In regards to the whole "I don't want to press it accidentally" thing I wanna throw my idea about simply proving a lifted bevel or a sunken button for the Menu/Pandora button. If you still hit that accidentally, ease up on the caffeine ;)
 
Tripmonkey_uk said:
Just thought of something..

@craigix - It was originally said that the keyboard would be locked out in most applications, so people don't hit the keys by accident when using the controls. How are you planning on implementing this?
Can you lock out the rest of the keyboard but leave the FN modifier key usable (as it doesn't do anything when pressed by itself), or will you have to lock out every keyboard key and just have the game controls, volume control and middle buttons usable?
It's not a matter of "locking out" the keyboard, it just a matter of the application looking for and doing something with the input from a particular key. If a program has no function associated with the J key, then you can accidentally press J all day and nothing will happen. Same goes for all the other keys.


realyst said:
In regards to the whole "I don't want to press it accidentally" thing I wanna throw my idea about simply proving a lifted bevel or a sunken button for the Menu/Pandora button. If you still hit that accidentally, ease up on the caffeine ;)
OK, this is just getting silly. This is a button that you are going to be using a lot. Any time you want to switch to another program or back out to the UI without closing the program you're using you need to press it, and you're trying to figure out ways to make it more difficult to do so? It's already about as far from your thumbs as it can get.

We're talking about a button to bring up a task switcher / system window, not a self destruct button.

The ideal setup would have four buttons, but since we have three the best thing to do is have one for the system menu, one for the program-specific menu, and one for start / select. Of the four functions, select is used least frequently. That should be the secondary button function.
 
Last edited by a moderator:
Tripmonkey_uk said:
@craigix - It was originally said that the keyboard would be locked out in most applications, so people don't hit the keys by accident when using the controls. How are you planning on implementing this?
Quite simple - the applications not interested in keyboard input will ignore all keyboard input :)
 
Last edited by a moderator:
Chip said:
Tripmonkey_uk said:
Just thought of something..

@craigix - It was originally said that the keyboard would be locked out in most applications, so people don't hit the keys by accident when using the controls. How are you planning on implementing this?
Can you lock out the rest of the keyboard but leave the FN modifier key usable (as it doesn't do anything when pressed by itself), or will you have to lock out every keyboard key and just have the game controls, volume control and middle buttons usable?
It's not a matter of "locking out" the keyboard, it just a matter of the application programmer looking for and doing something with the input from a particular key. If a program has no function associated with the J key, then you can accidentally press it all day and nothing will happen. Same goes for all the other keys.



Squidge said:
Tripmonkey_uk said:
@craigix - It was originally said that the keyboard would be locked out in most applications, so people don't hit the keys by accident when using the controls. How are you planning on implementing this?
Quite simple - the applications not interested in keyboard input will ignore all keyboard input :)

lol good point, what was I thinking?

In that case a good layout maybe..

Select Press = Select in program being used
Select + Hold = Universal program swap (Alt+Tab type with graphical selector)
Select + Fn = Instant swap to the next program (no graphical selector)

Start Press = Start in program being used
Start + Hold = Universal pause in system software (pauses all currently running software)
Start + Fn = Pause for program being used
(Starts normaly used for pausing anyway in most game software)

Menu Press = Menu in program being used
Menu + Hold = Universal system menu
Menu + Fn = Enter bios menu for things like NeoGeo emulators etc. or whatever?

With a layout of..
Menu
Select
Start

Or just swap the Fn and Hold one's around?
The raising or lowering of the keys is a good idea, but probably too late in production for major hardware changes?
 
Last edited by a moderator:
Don't forget that there were also plans to use Start and Select (iirc) as CTRL and ALT some time back (back when the designs were first released and various people noticed the lack of such essential buttons on it).

Not that these ideas aren't cool or anything, just we need to be careful find an alternative for CTRL and ALT if this is the route to be taken...
 
Back
Top