Extending use of the Pandora-Key

[McLovin]

We have a special key, just for us. It's something WE have for ourselves and ports aren't directly using. Why not define a standard-set of combinations that is part of the firmware AND dev's may adopt their software to?


What I think about is something like this:


Pandora + Power: Reboot


Pandora + Q: term current application (may be left to be implemented by the application)


Pandora + K: kill current application


Pandora + T: open task-manager


Pandora + E: Execute/minimal terminal


Pandora + Return: Open minimenu/xfce-menu


Pandora + W: toggle wlan


Pandora + B: toggle bluetooth


Pandora + L/R: switch window


Reserved for applications:


Pandora + S: Save(state)


Pandora + L: Load(state)


Pandora + O: Open (data/rom)


Pandora + R: Reset


Feel free to discuss the concept/individual combinations/add additional combos.


As we are currently on the way to super-saxxon, it may be about time to discuss usability-improvements like this.

 

[DaMummy]

have you ever tried holding the pandora key?

 

[skeezix]

Currently (he may know this) the pandora key is caught by pndevmapperd (see /etc/pandora/conf/eventmap) and invokes a script; that script handles key up/down and hold-duration and decides what to do. Currently the script checks for xfce or !xfce and reacts.. if xfce, it tries to pop up the pnd-list for killing; if !xfce, it tries to kill the pnd(s).


We could extend the script and pndevmapperd as needed to add stuff, though.. nothing against that. Pretty cool ideas there actually.. toggle wlan? neat idea. Not sure its needed per se, but neat all the same; power users like their keys.....


jeff

 

[gruso]

I like these ideas. It would be particularly nice to see more definitive app-killing options; I run XFCE and holding the button to bring up a list only works some of the time.


A combo to toggle TV out would be good.

 

[Prometheus]

A combo to toggle TV out would be good.

And a related one to toggle between the two modes for TV-out, too.


All too often I forget to go back to the tool and switch to overlay mode, or vice-versa...

 

[Askarus]

That's a good idea McLovin.

 

[Wally]

A mini menu for the pandora button would be kinda cool.. So that we could choose options (Some people might like to play music in the background while they play a game so maybe the option to change song?)

 

[Linux-SWAT]

Just ideas.


OP button + w : wifi on/off


OP button + b : bluetooth on/off


OP button + t : cycles tv out on/ntsc/pal/off


OP button + y (near) : cycles tv overlay

 

[Askarus]

Pandora + Space: Back to XFCE (Brings every running app to the toolbar and clears the screen so you don't have to shut down full screen apps if you need the desktop shortly.)


Pandora + (choose any buttons): Next/Previous workspace.


Pandora + C: CPU clockspeed menue.

 

[skeezix]

A mini menu for the pandora button would be kinda cool.. So that we could choose options (Some people might like to play music in the background while they play a game so maybe the option to change song?)

The reason we didn't do this day one is because its actually pretty complex; on something like PSP or xbox, one company controls the single way to access the display.. but on somethign open lik this with a variety of systems, its quite problematic -- apps could be fullscreen or windowed, they could be using opengl or just direct framebuffer, or multiple layers, or a number of things. Trying to arrest control from an app without screwing it up is .. it'd need lots of work, and probably app changes :/


But button+button chord key combinations should be doable, since thats just a launcher to things to do stuff.


jeff

 

[WizardStan]

it'd need lots of work

Yes, yes it does <_<

 

[McLovin]

Hey, I'm pleasently surprised there is a consense that this would be a usefull extension.


Now let's concentrate on suggestions and form. Maybe we should start a wiki-page for this?

 

[TrashyMG]

I wouldn't mind some Nub mode cycling done similar to Linux-Swat's TV out idea..

 

[Cloudef]

I'm running fork of monsterwm on my ArchLinux ARM rootfs.


I might put the rootfs up to download eventually, but I need to at least first compile every package to softfp, cause hardfp FPU operations are not compatible with the SGX binaries


(nor the PND's compiled on repo).

/** commands **/

static const char *termcmd[] = { "urxvt", 	NULL };

static const char *menucmd[] = { "dmenu_run", NULL };


#define DESKTOPCHANGE(K,N) \

	{  MOD_VI, 		K,          	change_desktop, {.i = N}}, \

	{  MOD_VI|SHIFT,  K,          	client_to_desktop, {.i = N}},


/** Shortcuts **/

static key keys[] = {

	/* modifier      	key        	function   		argument */

	{  MOD1,        	XK_b,      	togglepanel,   	{NULL}},

	{  MOD_VI,   		XK_BackSpace,  focusurgent,   	{NULL}},

	{  MOD_VI,   		XK_q,      	killclient,    	{NULL}},

	{  MOD_VI,   		XK_Right,  	next_win,      	{NULL}},

	{  MOD_VI,   		XK_Left,   	prev_win,      	{NULL}},

	{  MOD_VI,   		XK_9,      	resize_master, 	{.i = -1}},  /* decrease */

	{  MOD_VI,   		XK_0,      	resize_master, 	{.i = +1}},  /* increase */

	{  MOD_VI|SHIFT, 	XK_9,      	resize_stack,  	{.i = -10}}, /* shrink */

	{  MOD_VI|SHIFT, 	XK_0,      	resize_stack,  	{.i = +10}}, /* grow   */

	{  MOD_VI|SHIFT, 	XK_Left,   	rotate,        	{.i = -1}},

	{  MOD_VI|SHIFT, 	XK_Right,  	rotate,    	{.i = +1}},

	{  MOD_VI,   		XK_space,  	last_desktop, 	{NULL}},

	{  MOD_VI,   		XK_Return, 	swap_master,	{NULL}},

	{  MOD_VI,   		XK_Down,   	move_down, 	{NULL}},

	{  MOD_VI,   		XK_Up, 		move_up,   	{NULL}},

	{  MOD_VI,   		XK_t,      	switch_mode,   	{.i = TILE}},

	{  MOD_VI,   		XK_m,      	switch_mode,   	{.i = MONOCLE}},

	{  MOD_VI,   		XK_b,      	switch_mode,   	{.i = BSTACK}},

	{  MOD_VI,   		XK_g,      	switch_mode,   	{.i = GRID}},

	{  MOD_VI|CONTROL,   XK_q,      	quit,          	{.i = 0}}, /* quit with exit value 1 */

	{  MOD_VI|SHIFT, 	XK_Return, 	spawn,   	{.com = termcmd}},

	{  0,            	XF86XK_MenuKB, togglevi,      	{NULL}},

	{  MOD_VI,   		XK_r,      	spawn, 		{.com = menucmd}},

   	DESKTOPCHANGE(	XK_1, 							0)

   	DESKTOPCHANGE(	XK_2, 							1)

   	DESKTOPCHANGE(	XK_3, 							2)

   	DESKTOPCHANGE(	XK_4, 							3)

};


static Button buttons[] = {

	{  SHIFT,	Button1, 	mousemotion,   {.i = MOVE}},

	{  SHIFT,	Button3, 	mousemotion,   {.i = RESIZE}},

};

You press pandora key once, and enter into "vi mode" where you can control windows just by pressing buttons. Press pandora key again or touch screen to give key focus back to applications.

Also here is pndevmapper that doesn't depend on libpnd and has some cleanups. The scripts are also modified to be more portable (don't use sudo or zenity, and changes paths to /etc/pandora/scripts instead of /usr), but you can use the original scripts and paths too. It's good for those who are running lightweight rootfs or don't want libpnd, especially since the battery charging fix isn't yet on kernel.


I might work on that more too later, and port more pandora related tools && scripts that do not depend too much on things, nor spawn things all over the place.

 

[notaz]

A mini menu for the pandora button would be kinda cool.. So that we could choose options (Some people might like to play music in the background while they play a game so maybe the option to change song?)

The reason we didn't do this day one is because its actually pretty complex; on something like PSP or xbox, one company controls the single way to access the display.. but on somethign open lik this with a variety of systems, its quite problematic -- apps could be fullscreen or windowed, they could be using opengl or just direct framebuffer, or multiple layers, or a number of things. Trying to arrest control from an app without screwing it up is .. it'd need lots of work, and probably app changes :/

It is possible though, there is one OMAP layer left free that could be used for this. I could maybe do some proof of concept code and somebody can develop it further, there are far too many things on my plate already to start something like this..

 

[milkshake]

oooh sounds interesting.

 

[Cloudef]

It is possible though, there is one OMAP layer left free that could be used for this. I could maybe do some proof of concept code and somebody can develop it further, there are far too many things on my plate already to start something like this..

Totally forgot about the OMAP layers, there should be 3 of them?


Anyways, this sounds quite nice indeed. If you manage to whip some code, I would be more than interested to take a look.

 

[foxblock]

Good idea, maybe one could add


Pandora + P = Save screenshot to /media/FirstValidSDCard/pandora/screenshots/


while we are at it (so we don't have to set-up that script after every new hotfix ourselves).


I would love to see a Steam or Console like overlay, if the framework and API behind that is solid it could solve a great amount of problems (like showing documentation for currently run PND, show controls, easy way to exit, maybe even kill when PND hangs, unified menu, etc.).

 

[skeezix]

The other side of the coin is input handling though; using extra layer for rendering is one side, but we also need to capture nub, keyboards, toiuchscreen inputs so they dont' go to apps but instead to the overlay menu.


Thats where the work goes imho Capturing and releasing inputs


jeff

 

[steveway]

The other side of the coin is input handling though; using extra layer for rendering is one side, but we also need to capture nub, keyboards, toiuchscreen inputs so they dont' go to apps but instead to the overlay menu.


Thats where the work goes imho Capturing and releasing inputs


jeff

We could pause the currently running apps with

kill -STOP <pid of foregroundprocess>.

Then we show our menu using the framebuffer directly and do our stuff there.

And when we are finished and exit the menu, the process gets it's live back with

kill -CONT <pid of the process again>

Theoretically we could get the pid by first issuing

 xdotool getwindowfocus

which gives us the windowid of the process, that has the focus currently or

xdotool getactivewindow

which should do the same.

Then we could get the pid for the window using:

xdotool getwindowpid <windowid>

save this pid, issue the kill -STOP with it and kill -CONT at the end with the same pid.


The problem is that xdotool getwindowpid does not alway work.


I tried it with some programs and many don't work, GMU for example does not and many other PNDed apps will presumably not work too.


If you look up the pid manually for kill -STOP and -CONT it seems to work for most apps.