Pandora Gmenu2X For Pandora


PokeParadox

Founder of Pirate Games - Penjin Coder
Staff member
Joined
Dec 8, 2005
Messages
6,603
Age
40
Location
UK
Website
pokeparadox.itch.io
WEBSITE
https://github.com/pokeparadox
YOUTUBE
pokeparadox
Hi guys! :)

Many of you from the GP2X era will know the popular menu GMenu2x. It was originally planned as the default launcher interface as an alternative to full-desktop.
There were some problems (I don't remember what) and basically all effort to get it working nicely on Pandora was abandoned. Ryo has even removed the WIP Pandora code from the current repo.

In any case I have been hacking around the source and managed to write some code that can read the .desktop files that the PND system creates and use those to launch the actual apps. This kinda works but What I'm actually going for are the following features...

  • Ability to add GPE files to the menu and have them launch automatically with GINGE (currently not working)
  • The ability to toggle NotaZ SDL for a Pandora app for VSync and scaling benefits (working with some issues.)

The GPE files feature, is probably just malformed commandline. The issues with NotazSDL is that after running an app with it... everything else tries to use it... Finally for some reason the Scanner is not working... I have to add links manually..

To cut to the chase I'm wondering if anyone would still be interested in GMenu2X? I'm also wondering if anyone would like to help me work out these issues and get it to a user-friendly state?
 
I am not sure what advantages it brings at this point.

MiniMenu is basically GMenu2X. If you shut off the detail panel it is pretty much the same damn thing, catagories across the top, icon grid below.

If there are features it lacks that you want such as some scripting things etc you may be better off using the Minimenu source and adding features.
 
I forget too what the issues with gmenu2x in specific were .. I know there was a lot of 'gp2x' type assumptions in there which were goofy .. ie: busy loops to spin and use up time, rather than sleeping for partial seconds, that sort of odditiy, that needed ripping out. But it can't have been much work .. I imagine a couple nights of hacking and it'd run okay on pandora. New theme needed for the higher resolution and such but no biggy I imagine

Heck, pulling libpnd into gmenu2x or anything wouldn't be _that_ bad I imagine; libpnd returns a list (with api for traversal) of the app info and supplies the app-exec function to invoke from those references; if gmenu builds up an app list at startup, just call libpnd discovery routines there and populate its normal list, and add the exec-function in place of its one, and good to go :)

Adding stuff to minimenu wouldn't be hard either, but if you like gmenu2x, port her on over :)

Feel free to PM me or email me if you need help.

jeff
 
DaveC said:
I am not sure what advantages it brings at this point.

MiniMenu is basically GMenu2X. If you shut off the detail panel it is pretty much the same damn thing, catagories across the top, icon grid below.

If there are features it lacks that you want such as some scripting things etc you may be better off using the Minimenu source and adding features.
You have a point to some extent although GMenu still trumps MiniMenu in certain regards
- The ability to add applications to the menu, MM relies completely on the PND system
- Explorer-style launcher and Selector for emulators etc built-in
- Documentation viewer built-in

I did actually look over MiniMenu code, but it was a little intimidating since it's C-style coding and I'm much more comfortable with c++ which GMenu2X is written in. So obviously I was going to hack around with ideas with code I'm more comfortable.
This is about features though so yes maybe it would be worth working towards getting features to the Pandora rather than resurrecting a different project.


skeezix said:
I forget too what the issues with gmenu2x in specific were .. I know there was a lot of 'gp2x' type assumptions in there which were goofy .. ie: busy loops to spin and use up time, rather than sleeping for partial seconds, that sort of odditiy, that needed ripping out. But it can't have been much work .. I imagine a couple nights of hacking and it'd run okay on pandora. New theme needed for the higher resolution and such but no biggy I imagine

Heck, pulling libpnd into gmenu2x or anything wouldn't be _that_ bad I imagine; libpnd returns a list (with api for traversal) of the app info and supplies the app-exec function to invoke from those references; if gmenu builds up an app list at startup, just call libpnd discovery routines there and populate its normal list, and add the exec-function in place of its one, and good to go :)

Adding stuff to minimenu wouldn't be hard either, but if you like gmenu2x, port her on over :)

Feel free to PM me or email me if you need help.

jeff

Yeah there are other quirks too... like icon sizes are hard-coded to 32x32 but regardless I managed to get it functioning on the Pand so I'm not entirely sure why efforts were abandoned in the first place... I would have been able to help hack this into a working state, but whatever.

Anyway yes I started hacking GMenu because I felt there a couple of features missing from PandoraOS... I feel Ginge should be an installable component of the OS and you should be able to use GP2X/Wiz software as you would Pandora software, without having to write scripts or repackage or running a separate menu in Ginge... just add the GPE file to your menu(if Ginge has been installed) and boom!

Also maybe apps including some I have released are using plain old SDL as opposed to Notaz optimised flavours. I want to install it to a location and flag an app to use NotazSDL if present

I'm not sure which way to go from here, hence starting this thread.

Also thanks for your support Skeezix!
 
Last edited by a moderator:
minimenu does have a file browser explorer mode, its just disabled by default; see the config menu.

If you can handle C++, but not C, thats.. weird, nev er heard that before :) I chose C to make things ncie and 'obvious' and easier to link anythign into python and other runtimes without trickery.

Minimenu is all 'brute force', since it was started really quick, so its not how I'd like it, but it runs really well and is pretty simple codebase, if goofy in some spots.

All the app 'scan' logic is in one place, in the applications_scan function in mmenu.c iirc, where it does the pnd_disco_* auto discovery bit; I've 2wanted to (but will not have time for) make it plugin based, so coudl drop a pnd-scanner plugin, and an executable-scan plugin, etc; but lacking that, it'd be pretty easy to just drop another function call into appllications_scan() where by it walks thr devices looking for just plain executables and lists them .. make a pnd_disco_t struct that points to them and sets a flag that its not a pnd, and then in the execute handler, just put an if around the flag, and run it direct with exec() instead of pnd_apps_exec()

Note that mmenu can already run pure executables if you use the directory browser to run them as well.

ie: You coudl have mmenu _not_ do pnd scanning, and just run pnds and executabels from the dir browser (which is noramlyl turned off, to avoid confusing people.) The way that works is, when you open a directory it does the directory listing and if its a pnd, it gets the icon in real time, otherwise it just shows a basic icon type for directory or other. When user hits 'run', if its a pnd it tries a pnd-run on it, otherwise it tries (if its an executabnle mime type) to run it.

We coudl easily just modify the dir browser part to specially handle the .gpe, and invoke ginge (if ginge can run a command line specified app, I've never looked.)

--

So in terms of gpe handling, it woudl be pretty easy to add to minimenu; being that I know the code anyway.. I coudl do it in a night probably, if wanted. But I'm not stepping on your toes, so if you want to do it in mmenu, feel free and I can guide.. or if you wanna do gmenu2x, feel free, I'm not in your way :)

mmenu has a help viewer as well, but it does currently rely on pnd to get the doc from.

--

As to 'add apps' .. I figure most apps will be pnd, and minimenu tries to cut to the chase, so it made sense; for other stuff, can run right from the dir browser. Note that in mmenu you can recategorize items, so you can make your own categories to get custom listings in

Also, libpnd supports unpacked pnds (ie: not in pnd format, just a directory with a PXML) so you could make a PXML file for a directory appt o run it (including ginge if you wanted.)

It can run preu executables already, from dir browser.

So what its lacking for that one is the ability to just hit a button for 'add app', and pick an icon, and specify a path to run, say.. ie: eitehr uses PXML auto categortization, or dir browser.. no manual made up.

We could add something to make up a PXML maybe, or anotehr subsystem entirely to handle add-app, but in general.. is there a need? Almost every pandora app will be a pnd-file, or if its not.. its an alpha or beta and will be pnded soon, and can be run from the dir browser in the mean time.

*shrug*

--

Sorry for the long ramble, just spewing out the info and running :)

jeff
 
Ok... you have clarified some points that I didn't know or wasn't sure about, so thanks.

It's not that I can't handle plain C... it's more that C++ makes more sense to my brain and is easier for me to read. It's what I'm more comfortable with.

It's not that I have a burning desire to personally add functionality... if you can quickly add it, it would make more sense for you to do it, since you already understand your codebase and so forth. I just want to be able to access my GP2X software a little easier and was trying to solve that problem... that and easier access to NotazSDL.

If MiniMenu just had a separate category that would be cool.

Likewise I'm not sure it's needed an "add App" option if MiniMenu could build the applist of other things other than PNDs

Also yes Ginge does run apps via commandline "ginge_prep GPE_FILE"

It's ok for the wall of text, it's exactly the type of discussion I was going for.
 
Normalyl ginge is in a pnd; maybe notaz would add a subapp to ginge's pnd, that is 'install ginge to nand' or something, that drops the actual ginge_prep (and data files?) somewhere. (Thats why gpe's get packaged probabyl, so theyr'e just pnd, wioth appdata and all that, going on.)

If you just want to run a gpe, do you want appdata type magic to happen?

How about .. if you make me a little sh-script that is "run_gpe.sh" or something, that does whatever you need (or has commandline args so it can do appdata, or not, depending on users mood), then I could build it into the directory browser part of minimenu. Then you could just config minimenu to ahve a tab appear for the directory you want, or for your SD root and browse to it, see all your gpe's, and when ou hit 'B' or Start to run, it'd invoke "gpe_run.sh -noappdata /path/to/goo.gpe" and run_gpe.sh would do all the heavy lifting (invoke ginge_prep).

To work around the ginge pnd oddity, could maybe require "ginge.pnd" or "*ginge*.pnd" to be in the same location as the .gpe file, and then gpe_run.sh could find it, use pnd_run.sh -m/etc to mount it, then run /mnt/utmp/ginge/ginge_prep -foo -bar/etc to run it, then pnd_run.sh -u to unmount.

That way ..

1) you give me gpe_run.sh (I've never used ginge much so no idea :)
2) user drops gpe and ginge*pnd into /some/sd
3) minuimenu shows gpe's in directory browser mode (if not more, but that'd be first stage) and good to go

That is, if you want me to code up somethign for you .. you coudl do the script, give it to me, and I'll do the minimenu/installer/test side, and we're gold.

--

for toggle notaz-sdl; could pretty easily add a global setting to minimenu's config section, so used coudl enter config, toggle the sdl choice, and go. But do you want it persistant per-app? Coudl add it to the 'ovr editor' menu that mmenu has (ie: just like you can rename an app, override its cpu speeds, etc .. coudl add an override for preferred sdl, say, that only minimenu understands.)

How do you manage to swap SDLs? a PRE_LOAD thing, or drop it into appdata for an app, or .. so many ways, what is most effective and standardizable?

jeff

edit; may need to mount twice .. once to mounge ginge*pnd, a second mount to get an appdata for that gpe, then run, and unmount and unmount; try second mount, to get appdata back into the right palce from the app, but sounds doable to me off the top of my head, without ever trying it :)
 
I'd never even thought about "appdata" style magic for GPEs but... if it's possible, why not? Keeps all your saves in one place, away from your program runtimes.


The way I tried to handle Ginge and NotazSDL was having a "libs" directory within the GMenu "PND"(Did not actually bundle it as a PND but you get the idea)
Then from Gmenu's working dir

Code:
./libs/ginge/ginge_prep /path/to/gpe/file.gpe

I think it would be better to check for the existance of the ginge PND and then offer the running of gpe files.
You would just have to pnd_run.sh ginge_prep from the PND.

Likewise to run a Pandora app with Notaz SDL:
Code:
export LD_LIBRARY_PATH=./libs/notaz_sdl 
export SDL_VIDEODRIVER=omapdss
pnd_run.sh -p /path/to/pnd ... etc

This ideally would be on a per app basis. But the way I did it in my tests on GMenu2x it eneded up with GMenu2x taking on using NotazSDL and so forth.
 
PokeParadox said:
You have a point to some extent although GMenu still trumps MiniMenu in certain regards
- The ability to add applications to the menu, MM relies completely on the PND system
- Explorer-style launcher and Selector for emulators etc built-in
- Documentation viewer built-in
I am not sure what you mean by "add applications to the menu". Do you mean create custom catagories? Something else? You can create custom catagories (tabs) and subcatagories. You can also re-name things and move apps to different catagories how you want too. I "fought" (ok worked with, but there was a bit of resistance) with Skeezix for weeks about it :p and he added that stuff and it works pretty well. You can add your own icon art as well and skin everything. It is configurable but many things may not be obvious.

One area where MM trumps Gmenu2x is the abiliy to have folders under tabs to further organize apps. Just set up some custom subcatagories and you have them. Before MM was limited to rigid pre defined catagories only, but I made Skeezix change that :p

There is a doc viewer kind of but it launches a browser and is SSSlLLLlllllOOooooooowwww. I tried to get Skeezix to ditch that and add a built-in doc viewer, but he ran out of time or something. I bet if you wrote a good doc viewer that could be integrated it would be appreciated.
 
Last edited by a moderator:
Poke --

Coudl maybe use one pnd_run to invoke ginge and the gpe, actually, now that I think about it. We added (sebt3 I mean :) an option to specify where appdata goes (so that we could make a mode for DaveC where appdata goes to where pnd is, and not in /pandora/appdata itself.) I've not had time to finish that part yet, but its in pnd_run.sh.

So could run pnd_run.sh with the executable set to './ginge_prep /foo/bar/boom.gpe' maybe, and if the spaces are honoured right in pnd_run.sh, that might just work; also specify the appdata to be a custom one per gpe, and poof, good to go.

Sounds pretty doable with fiddling.

--

A 'doc viewer' has a dependancy .. if we can get 'links' or 'lynx' or the like into the firmware (for HF6 say, we didnt' want to extend HF5 any more) then it'd be trivial to make a text doc viewer for minimenu. (ie: that can render text or html).

Could make mmenu render pure text docs now, but sort of waiting on the links side to get in, so can do it whole hog.

yeah, launching a full 'real browser' is annoying :)

jeff

Dave -- running out of time .. I've got a 'hard deadline' in real life; in about 3 months, Im "done" for half a year due to having twins, so Iv'e got a tick-tock over my head on what I can accomplish, with decreasing free time every day as we get closer to the deadline ;)
 
AFAIK there was simply one major problem why Gmenu 2X wasn't choosen for default Pandora Menu: no Multitasking possible, case closed. ;)
 
The OS multi-tasks, the menu does not have to ;)

(witness Minimenu .. works fine in a multitasking environment, can be used as a launcher for one, but something else can close background apps if you want to do that; by default it fosters a single app at a time setup, or you can boot into xfce/other to do full multitasking setups.)

jeff
 
PokeParadox said:
You have a point to some extent although GMenu still trumps MiniMenu in certain regards
- The ability to add applications to the menu, MM relies completely on the PND system
- Explorer-style launcher and Selector for emulators etc built-in
- Documentation viewer built-in
Doc viewer is the big one for me. Or at least the option to launch those documentation files with something other than Arora (such as the plain text reader).

Actually, skeezix, how hard would it be to add an option for that? (allowing the user to change the default program that launches to read those files... or can that already be done in the XFCE options? I don't care about html, I'd rather have them load quickly when I read them)
 
Last edited by a moderator:
Pfft, you should know me better than that ;)

/etc/pandora/conf/desktop

21 [info]

22 emit_info 1 # 0->no info .desktop; !0->yes to info .desktop

23 dotdesktoppath /usr/share/applications # path for pndnotifyd to spit .desktop files into

24 viewer ../../../usr/bin/arora # sh-script or prog to run. Use wrapper sh if needed.

25 viewer_args # args. <- plus filename will be passed. ie: "-a filename.html"

26 category Documentation # freedesktop standard category to use


Viewer can be changed (for both minimenu and xfce in the same conf item.)

I will add a text-ony viewer to minimenu when I get a moment (descxreasing number of moments available sadly)

jeff
 
Back
Top