Release Pandafe 0.2.2
- Thread starter nuhrin
- Start date
Well, my working vacation ended up being rather heavier on the work side of things than I'd hoped...
I'm back home and getting the family settled back into a routine. I'll try to respond to each of your issues, bug reports and requests as soon as I am able.
Thank you all for your feedback, I appreciate it!
I'm back home and getting the family settled back into a routine. I'll try to respond to each of your issues, bug reports and requests as soon as I am able.
Thank you all for your feedback, I appreciate it!
b_o_b
Advanced Member
- Joined
- Sep 7, 2010
- Messages
- 1,493
Everybody that wants to get the most out of Pandafe should try to fully understand this post http://boards.openpandora.org/index.php/topic/10960-pandafe-020/#entry204091
Good to see you back nuhrin! One request, faster starting of the program. Could it be the program slows down a bit after longer use?
Good to see you back nuhrin! One request, faster starting of the program. Could it be the program slows down a bit after longer use?
Last edited by a moderator:
Crap guys, sorry, I got completely swamped since my last post. Hard to believe as much time has passed as it has.
I made myself a todo list based on all your comments and I'm going to try and do some work on this tonight. I dunno how much I'll get through before my time gets overfilled again, but I'll do what I can.
Well wishes!
I made myself a todo list based on all your comments and I'm going to try and do some work on this tonight. I dunno how much I'll get through before my time gets overfilled again, but I'll do what I can.
Well wishes!
Good luck with the coding!
Null
Snug
No worries, rl likes to do that to all of us.
Last edited by a moderator:
Ok. I finally found enough time to get enough hacking in to put together an update I'm happy with. It was my birthday today, so I got to spend the day out at a coffee shop and sports bar, ironing out some last tricky bits and watching a good first game of the NBA playoffs. Its amazing what a difference it makes to code in the prime daylight hours on plenty of sleep...
Long overdue responses to your requests, reports, etc:
All of these are added in the latest release. Some were rather trickier than I'd imagined.
Its amazing what a difference it makes to code in the prime daylight hours on plenty of sleep...Long overdue responses to your requests, reports, etc:
All of these are added in the latest release. Some were rather trickier than I'd imagined.
- Commodore 64 (vicex64.pickle)
This seems to work ok, but I'm not much into C64 games and I'm not sure how well this covers your collection. Vice will try to autostart the selected game (x64 d64 t64 tap), but I'm not sure thats always the right thing. A much more complicated program definition might be in order (with selectable options configured for launching behavior, etc), but I don't really have the domain knowledge to tackle that. Hopefully it works for you - Colecovision (colem.skeezix)
There are other Colecovision apps, but this is the only one (I found) which accepts command line arguments. That's a shame, because colem.skeezix also fullscreen or suitable scaling. I went ahead and hacked in fullscreen using the xdotool program to ask xfwm4 to fullscreen it and hide the mouse cursor. If you'd rather have the normal behavior you can remove those bits from the custom command (in the program definition). - Playstation (pcsx_rearmed.notaz)
This already worked, but I realized that the platform definition was configured to only look for .bin files, which was fine for me but not so helpful to others. I've changed it to look for .cue and .iso files, which appears more correct. Hopefully this helps you and others who might have had problems without realizing the source. You'll have to rescan your playstation platform or game folder for this to be picked up (space for context menu). - NeoGeo (gngeopnd-pepone, fba.dave18)
GnGeo took me a while to sort out, both because its command line options are finicky and because its compatibility with my roms isn't so great. You may get an error dialog with some grumbling about not being about to load games. It did work for me with one game at least. FBA I initially added only as an "Arcade" program, until I realized it can run NeoGeo games as well -- better than GnGeo, imo, but I've left GnGeo as the default based on your request order. Also, it would be nice if pandafe could somehow extract the game name from the terse zip file names, but it can't (maybe one day) so we're stuck with the terse names unless somebody has a clever suggestion... - MSX (openMSX_PND)
As with Vice, openMSX is a little out of my comfort zone. Its possible to connect cartridges, cassettes, isos, and disks, but there is not as far as I can tell a way to have it automatically handle whatever you throw out it. I configured it to run with the "-cart" option ("Insert the ROM file (cartridge) specified in argument") which worked well for my very limited sample size. If this doesn't work well for you, and you can provide the dirt on what is needed, I can help you set up some program options to address it. - Arcade (fba.dave18, mame.cosam.106)
I moved the existing "MAME" platform to one called "Arcade", and added FBA along with the existing MAME program definition. I ought to have done this to begin with, but yeah. FBA was the nastiest to get working, due to its tight coupling with Capex. After many convoluted experiments I sorted out that simply renaming capex.sh before running fba (and restoring after of course) is enough to prevent Capex from starting afterwards. I just realized while typing this, however, that this probably will only work if you have an ext2 formatted SD card. If you are using fat then I expect you'll still get Capex. Might be possible to workaround differently for fat cards, perhaps by creating a subfolder (in the custom command) and running everything within that. - Atari 2600 (stella)
The easiest of the surprisingly complex lot. It seems to segfault on some games, but does so from the Stella launcher as well. - Intellivision (jzintv.WizardStan.1)
Unpleasantly complicated custom command, entirely due to the complexity of the original. Simple change though, no gotchas that I'm aware of.
- Delete the "platform_folders" file in your pandafe appdata folder. This will cause a "stock" one to be installed, with all the available platforms put somewhere (according to my own preferences/whims),
- Add the new platforms to a platform folder, either via the main menu (Select->Config->Platforms) or the context menu of an existing platform folder (Space->Edit)
- Switch to the "Platform List" view (L-Trigger). That lists all platforms available, even those not in platform folders. Note though that platforms not added to a platform folder do not show up in the "Choose Platform" menu (R-Trigger) or the All Games view. This is by design, so folks can hide platforms they'd rather not bother with.
Ouch. Sorry about that. I've probably taken my SD card out maybe three times since I first put it in there. This possibility never even occurred to me. Pretty painful though. I've changed the installed script to display a warning via zenity that the pandafe pnd wasn't found where it was expected, with some possible causes and solutions. The dialog also gives you the change to switch guis, in case you want/need that.
In order to get this new behavior you'll need to uninstall and reinstall the gui, and to do that you'll have to run pandafe from a different gui and (Select->Config->Uninstall Gui->Install Gui).
I finally remembered to install this and got around to trying it last night as a universal launcher for the various emulators out there and it's really good stuff, much better than dealing with different file selectors, etc., that all behave differently from one another. Combined with the fact that it's perfectly capable of launching stand-alone PND's as well I'm definitely considering just making it my default launcher. Great work!
Succinctly describes my entire motivation for making it. Cheers!
I looked into getting Handy to have a different default behavior, but unfortunately it seems to not be possible. Sorry.
The Mega CD issue seems to have been a bug. I had previously needed to workaround issues with passing quoted arguments into pnd_run.sh (for games with spaces, etc) by creating a symling in /tmp that had no spaces, etc. This caused PicoDrive to not see the other files. It was no longer necessary since I'm no longer using pnd_run.sh directly, so I removed that symlink step. Seems to have fixed the problem. I also added "cue" to the list of extensions for the platform, since it wasn't there previously. Thanks for the report!
The playstation issue should be solved in the latest version -- I changed the expected extensions to cue and iso, which should give better (complete?) coverage.
The nes issue I'm not sure about. The platform is currently configured to look for .nes and .zip. What other extensions are appropriate?
Interesting. Possible, certainly. I'm hesitant to add any persistent (always on) elements to the interface because I'd like to keep it as text-based and cleanly focused on rom selection as possible. I was shooting for the feel of those simple rom selection interfaces in many emulators, where the interface is simple enough to use intuitively or a little trial and error. Its a little more complicated than that of course with the menus, but that was the goal. Documentation about the "controls" is in the readme, fwiw.
What did you have in mind? If you can propose and help talk through a way to include a sort of legend, while still keeping the interface clean, then I'm happy to add something like that to my todo list.
Okay, this is the stuff that took all that time I had trouble finding. There were indeed some pretty substantial memory leaks, and these are addressed in the latest release.
For the interested, these were mostly due to some wrong assumptions about how Vala handles object signals, and lambda handlers connected to them especially. Basically, Vala using object reference counting to provide transparent memory management. When there are no more references to an object it is destroyed and its memory freed. I had managed to unwittingly introduce some object references inside signal handlers that could never be unreferenced, so some things were never destroyed. These things cascaded to some pretty big things left in memory -- entire sets of SDL surfaces, game lists, all sorts of big stuff. That's what I get for not checking memory use over time It's frankly astonishing that pandafe worked as well as it did given the above. I imagine we have the kernel to thank for good memory and process management.
In any case, I took the time to do some actual testing and make sure objects are actually getting freed when I expect them to go fully out of scope. There may still be some rather smaller leaks (of similar sort), but things are looking pretty good now. In my last tests I was unable to get the RES memory reported by top to exceed 65m, even after hitting every list, switching back and forth between the all games view and others, hitting every menu, rescanning every platform, and opening the custom command editor (gtk adds a chunk). Less extensive usage should keep that number smaller. I imagine I could get that number down with more refactoring, but that fact that I wasn't able to push memory usage any higher is certainly good enough to warrant a new release.
As long as I was bothering with all the above, I took a look at the startup time as well. I'll save you the long winded version this time; the short version is that the startup time should be much improved. For my tests with ~4,000 games the All Games list is parsed into memory in around 0.02s, vs 2.5s previously. If you still see gripe-worthy startup times, please let me know.
Alright, all done for now. Hope the new version is more pleasant. Enjoy!
Last edited by a moderator:
b_o_b
Advanced Member
- Joined
- Sep 7, 2010
- Messages
- 1,493
Happy birthday nuhrin and thanks for this nice present! Usually it is the other way around, but I don't see any reason to complain
Will give it a try and report back later (not much time this week)
porg
Active Member
Thanks for making this launcher!
It fulfills my long desire for the Pandora, that PNDs and ROMs get both first citizens, and that they are interlaced for browsing and launching. At least rudimentary in "All apps" and "Favorites", more sophisticated stuff possible, feedback in this post.
And for enabling favorites. So far not possible in MiniMenu. In XFCE I sort of achieved it by moving favored PNDs into <sdcard>/pandora/desktop others into <sdcard>/pandora/menu, thus all my favorites appear on the desktop (and menu), less used apps in the menu only.
This was my praise! Now my feedback follows.
A mix of feature and improvement suggestions.
Hope you like some of it, as you asked for it. ;-)
Support for new platform "Nintendo DS" and new emulator "Drastic"
Platform definitions: File suffixes
The following rom file suffixes are quite common for these platforms, should thus be added as known suffixes:
Playstation: mdf, img
N64: z64
Auto assign platform/roms to next known program if preferred one not installed
Had this SNES emulator installed on my Pandora: GPFCE.
Started with a fresh installation of Pandafe.
Within the predefined platform folders, I navigated to Nintendo > NES, which brought up the first-use file chooser for selecting the rom-root. Parsing worked, roms were added.
Launching a rom failed with something like "GPFCE not installed".
Pandafe should be intelligent enough in its initialisation to try to assign another known emulator, if the preferred one is not found on the system. (if not 1 then try 2, if not 2 then try 3, ...)
In my case GPFCE was not installed, but gpFCE-GP2X was, so gpFCE-GP2X should have gotten assigned.
I had to assign gpFCE-GP2X manually.
Idea for even more melted views (melting roms, pnds, platform, genres, folders)
In all game lists (All Games, Favorites, Most played, Most recent):
Sort by: Name, Genres, Year.
By "Genre" I mean this:
For a PND: FreeDesktop subcategory (such as: ActionGame, BlocksGame, ...) or your own defined subcategory (i.e. I use LogicActionGame to differ from LogicGame, and Shooter, ShooterFlight, ShooterScroller for my own differentiation) in the .OVR override file.
For a ROM: Its parent folder. Pandafe calls this "Subfolder".
For optimal melting, use the same genre naming convention among PNDs and ROMs.
Within your rom folders, sort your roms by genres:
PSX-roms/genre1/rom1…rom3 PSX-rom/Genre2/rom1…rom5 NES-roms/genre2/rom1…rom3 and so on…
Then you can play a "LogicGame", regardless wether it is a PND, NES-ROM, PSX-ROM, ..., SMD-ROM.
By "Year" I mean this:
For PNDs: Their creation date (at best identical with "added to repo" date), if not available (on FAT volumes possibly), then modification date.
For ROMs: If the ROM can be identified via checksum/hash, and there is a database with dates for roms, consider this. Else, does the ROM or parent folder contain a 4-digit number? If so, consider this as the year. Else, creation date. Else, modification date.
We need one key to change the sort order. See chapter: Controls.
How to display this information to have enough orientation but at the same time not too much visual noise, is a challenge.
I have my ideas, and already made some drafts. But first I wait wether, you even like the idea, and if so, maybe you have your own ideas for it.
Better ad-hoc filtering
Do it like Pickle launcher! Just type "str" and it matches "*str*". The more characters the narrower the results. Deleting the string to 0 characters length quits the filter mode. Simple! Good usability! (Think of the radio knobs which are volume control and on/off switch at the same time!).
No "press same key multiple times to iterate through all strings starting with that letter" (MiniMenu, DOS, etc).
Your current filter mode it too hard to start and leave. One key (,) to enter filter mode, then type filter string, then another key (backspace) if you need to delete characters, and yet another (ESC) to cancel the filter! Too complicated! Low usability! You can make it simple. There is no danger of destructive user action. It is just a filter. Not a renaming or deletion process!
Controls
The Pandora lacks defined I & UI guidelines, though some community members tried (porg, Krenn), nevertheless meanwhile some de-facto standards were established from popular apps, or apps where navigating/editing is important (launchers such as MiniMenu, or integrated package management programs such as PNDManager).
Your approach to use B to enter or drill down, and A to drill back (instead of X in PNDManager, MiniMenu, PCSX, several others) and Y/X to page up/down is actually better than the established control canon in the other mentioned apps, but then again: It's different, therefore maybe needs adaption. That what bugs me so much on the Pandora: No established interaction design standards, the worst being poor ports which leave the PC key assignments 1:1.
The most logical assignment for a launcher to launch an item would be START, but as you assigned already the two keys ENTER and B for launching, START is free. Therefore this would be possible:
START to show up main menu (consistent with many native Pandora games)
SELECT to change sort order (consistent with PNDManager)
It fulfills my long desire for the Pandora, that PNDs and ROMs get both first citizens, and that they are interlaced for browsing and launching. At least rudimentary in "All apps" and "Favorites", more sophisticated stuff possible, feedback in this post.
And for enabling favorites. So far not possible in MiniMenu. In XFCE I sort of achieved it by moving favored PNDs into <sdcard>/pandora/desktop others into <sdcard>/pandora/menu, thus all my favorites appear on the desktop (and menu), less used apps in the menu only.
This was my praise! Now my feedback follows.
A mix of feature and improvement suggestions.
Hope you like some of it, as you asked for it. ;-)
Support for new platform "Nintendo DS" and new emulator "Drastic"
Platform definitions: File suffixes
The following rom file suffixes are quite common for these platforms, should thus be added as known suffixes:
Playstation: mdf, img
N64: z64
Auto assign platform/roms to next known program if preferred one not installed
Had this SNES emulator installed on my Pandora: GPFCE.
Started with a fresh installation of Pandafe.
Within the predefined platform folders, I navigated to Nintendo > NES, which brought up the first-use file chooser for selecting the rom-root. Parsing worked, roms were added.
Launching a rom failed with something like "GPFCE not installed".
Pandafe should be intelligent enough in its initialisation to try to assign another known emulator, if the preferred one is not found on the system. (if not 1 then try 2, if not 2 then try 3, ...)
In my case GPFCE was not installed, but gpFCE-GP2X was, so gpFCE-GP2X should have gotten assigned.
I had to assign gpFCE-GP2X manually.
Idea for even more melted views (melting roms, pnds, platform, genres, folders)
In all game lists (All Games, Favorites, Most played, Most recent):
Sort by: Name, Genres, Year.
By "Genre" I mean this:
For a PND: FreeDesktop subcategory (such as: ActionGame, BlocksGame, ...) or your own defined subcategory (i.e. I use LogicActionGame to differ from LogicGame, and Shooter, ShooterFlight, ShooterScroller for my own differentiation) in the .OVR override file.
For a ROM: Its parent folder. Pandafe calls this "Subfolder".
For optimal melting, use the same genre naming convention among PNDs and ROMs.
Within your rom folders, sort your roms by genres:
PSX-roms/genre1/rom1…rom3 PSX-rom/Genre2/rom1…rom5 NES-roms/genre2/rom1…rom3 and so on…
Then you can play a "LogicGame", regardless wether it is a PND, NES-ROM, PSX-ROM, ..., SMD-ROM.
By "Year" I mean this:
For PNDs: Their creation date (at best identical with "added to repo" date), if not available (on FAT volumes possibly), then modification date.
For ROMs: If the ROM can be identified via checksum/hash, and there is a database with dates for roms, consider this. Else, does the ROM or parent folder contain a 4-digit number? If so, consider this as the year. Else, creation date. Else, modification date.
We need one key to change the sort order. See chapter: Controls.
How to display this information to have enough orientation but at the same time not too much visual noise, is a challenge.
I have my ideas, and already made some drafts. But first I wait wether, you even like the idea, and if so, maybe you have your own ideas for it.
Better ad-hoc filtering
Do it like Pickle launcher! Just type "str" and it matches "*str*". The more characters the narrower the results. Deleting the string to 0 characters length quits the filter mode. Simple! Good usability! (Think of the radio knobs which are volume control and on/off switch at the same time!).
No "press same key multiple times to iterate through all strings starting with that letter" (MiniMenu, DOS, etc).
Your current filter mode it too hard to start and leave. One key (,) to enter filter mode, then type filter string, then another key (backspace) if you need to delete characters, and yet another (ESC) to cancel the filter! Too complicated! Low usability! You can make it simple. There is no danger of destructive user action. It is just a filter. Not a renaming or deletion process!
Controls
The Pandora lacks defined I
& UI guidelines, though some community members tried (porg, Krenn), nevertheless meanwhile some de-facto standards were established from popular apps, or apps where navigating/editing is important (launchers such as MiniMenu, or integrated package management programs such as PNDManager).Your approach to use B to enter or drill down, and A to drill back (instead of X in PNDManager, MiniMenu, PCSX, several others) and Y/X to page up/down is actually better than the established control canon in the other mentioned apps, but then again: It's different, therefore maybe needs adaption. That what bugs me so much on the Pandora: No established interaction design standards, the worst being poor ports which leave the PC key assignments 1:1.
The most logical assignment for a launcher to launch an item would be START, but as you assigned already the two keys ENTER and B for launching, START is free. Therefore this would be possible:
START to show up main menu (consistent with many native Pandora games)
SELECT to change sort order (consistent with PNDManager)
porg
Active Member
Bug report:
Starting PCSX alone —> Controls work as expected
Starting PCSX via Pandafe —> Controls work only very partial, most assigned keys missing!
Update:
The circumstances very much look like this is a PCSX bug rather than a Pandafe bug.
Filed a report in the PCSX feedback thread. If interested, you can follow the discussion over there.
Starting PCSX alone —> Controls work as expected
Starting PCSX via Pandafe —> Controls work only very partial, most assigned keys missing!
Update:
The circumstances very much look like this is a PCSX bug rather than a Pandafe bug.
Filed a report in the PCSX feedback thread. If interested, you can follow the discussion over there.
Last edited by a moderator:
Thanks for the report, and double for digging in deeper. I have not seen this issue, but I've also not been playing much lately and its certainly possible I introduced a regression (or never noticed a bug).
I'll post responses to your excellent other (rather longer
) post as soon as I am able.
Last edited by a moderator:
Thanks FZERO, glad you like it. I happened to notice your comments in the hyperspin thread as well, so I thought I'd respond to those here:Nuhrin nice work!
I've just seen this in repo with screenshots and this looks just what I want for when I get my Pandora
Integrating thumbs/screenshots is definately something I'd like to happen, but yes its a good amount of work. I hacked on some stuff earlier this year, but its been hard to find time for bigger tasks.
I have a related wishlist item I really want to get done first -- the ability to take screenshots of a running game via an overlay menu (using process hackery and fbdev). I have a branch in my local git repo with a largely complete implementation of this, but there is a lingering issue that kept me from finishing before my time ran short.
Once that wish feature is fulfilled I'd planned on tackling the issue of integrating screenshots into the interface. As long as the subject is now broached, do you (or anyone else) have any thoughts on how you'd like to see this work? The easiest/cheapest solution is probably to just show an available screenshot in the context menu, over the gamelist on the left. Other ideas like having the screens integrated into the browser, or having a screenshot-based browser, sound lovely but would certainly be a challenge in terms of performance.
As far as Yoshi's cheat sheets -- seems like it's come up enough to be unavoidable.
I think perhaps data wise this could be the fairly simple matter of adding some key/value pairs to the Program definitions -- Logical Key Name = Pandora Key Name -- that sort of thing. The question is how to display them. A simple textual approach is certainly preferred in the short term, to avoid depending on deeper architecture or interface changes. Speaking of that...I thought about this sort of thing early on but put it aside to as I narrowed my scope down and decided on initial concrete goals. My compromise was to include a way to change the font and color scheme. I had at one point envisioned supporting different fonts/colors per platform, but dropped that to focus on other things. Perhaps that feature could be completed, then at some point expanded to include a single background image to be rendered over. From my perspective this is a lower priority than other features on the radar, but I'm open to bumping this is if everyone wants it more than anything else. Even then though I would still like to keep it optional to preserve the simple text interface.
Last edited by a moderator:
Heh, indeed, I appreciate it.
Haven't tried this yet, but sounds impressive. Assuming the Drastic binary can launch roms directly it should be straightforward enough. Have you tried adding it yourself yet?
Thanks for that, I will add them to the next release (added now in my local repo).
Ah, oops. I did some work along these lines in the past, but obviously didn't complete it and had forgotten. Each platform definition has a default program setting. I will change the behavior so that the first available platform program is treated as the default if the configured default is not available. You can in the meantime change that default in your platform definition to avoid having to change it for every game.
"Melting" eh? I pondered these sorts of things in my initial design work, but eventually just dropped the whole area of concern, apart from treating rom subfolders vaguely like categories, as you observed.
Its something of a can of worms, partially due to the display/interface questions, as you also observed. Having sort implies having multiple columns, which I quickly abandoned for simplicity of design and initial effort.
What if, instead of sort options, we have *filter* options? Filter menu pops up, you choose your filter from a tree, list is filtered, repeat. You don't get the context for all the different genres, etc, together in the list at a glance, but the filter menu itself could be written to only display what is appropriate for the game list, thus providing that context. So, its drill in and out, rather than page up and down. At a gut level, this feels more pleasant to me personally, and certainly it integrates better into the existing design and architecture.
Curious though, yes, to hear what you came up with for how this might work. And yes, we need a key to trigger this (sort or filter). Tab?
On Genre:
For a PND:
- I hate the redundant "Game" suffix on the categories in this context, especially if trying to match rom folder names to them to facilitate "melting." Any objection to stripping that suffix, at display time? While I'm at it, what about splitting up the PascalCase (LogicAction -> Logic Action)? Any other display transformations?
- Does Pandafe already respect and display your own category names from OVR files? I dunno if libpnd does this transparently as part of app discovery, I never got around to testing this.
- What you describe is also my preference for structuring my rom folders, and really the whole reason there is support for subfolders.
- A have in my local repo a partial implementation of rom file/folder management via the context menu. Will let you move roms into existing (or new) folders within the root folder for the platform, rename rom files and folders, and delete rom files. Also lets you open terminal/thunar in the context of the selected folder, for more complex management. Still needs work, but should help with an iterative "melting" process.
- Interesting, hadn't considered this. Not sure I would use it, but then that's true of most other metadata that some folks like -- publisher, region, etc.
- This will presumably require/call-for a new subsystem for keeping track of rom metadata. Performance/memory optimization can be a challenge, so simplicity is preferred.
- I kind of like the idea of extracting metadata from rom filenames. That solves the problem of how to store and associate it roms very nicely. It complicates any interface for managing metadata in program, but makes it possible to have the feature before such an interface is build (or skip the interface entirely).
- I'm not so sure about extracting it from folder name though, as that would complicate other aspects of the program (including this one).
- Also not so sure about doing md5 on roms on the Pandora. Seems to expensive. Could be cached, but rom scanning would get way more expensive.
After thinking/"talking" this through, I'm liking the idea of adding game attribute filters (vs sort) to game lists, and extracting rom metadata from filenames. What do you (all) think?
I agree 100%. This was my intent initially, but I implemented it the way it is now because it was easier at the time and I needed to focus on more critical aspects. Your description is complete enough that I will just use it as a reference when I get to implementing this. One reason that I initially stopped work on this was that my selector code was not performant enough to do live filtering. Things are more optimized now, but might still need tuning for this to be usable.
Start is free, but I left it free because to the best of my knowledge that's the only way to achieve ALT. Because Pandafe opens other windows its nice (maybe necessary) to be able to alt-tab between them and back. Not sure there's a good solution that will allow Start to be used for other things, nice (and obvious) as that would be. Any ideas?Controls
The Pandora lacks defined I
Your approach to use B to enter or drill down, and A to drill back (instead of X in PNDManager, MiniMenu, PCSX, several others) and Y/X to page up/down is actually better than the established control canon in the other mentioned apps, but then again: It's different, therefore maybe needs adaption. That what bugs me so much on the Pandora: No established interaction design standards, the worst being poor ports which leave the PC key assignments 1:1.
The most logical assignment for a launcher to launch an item would be START, but as you assigned already the two keys ENTER and B for launching, START is free. Therefore this would be possible:
START to show up main menu (consistent with many native Pandora games)
SELECT to change sort order (consistent with PNDManager)
As far as your other notes, I think the think to do here is to make the controls customizable. Then the default controls can reasonably be chosen by committee and everyone not liking the consensus (including probably me) can just do their own thing. I actually have a start on this due to some hacking on an experiment to add joystick input (for my media pc), so this should be obtainable ahead of most of the above. Probably ought to prevent folks from choosing "word character" keys, to avoid impacting the type-to-filter thing.
Whew! Lots more typing than I'd intended, up late again.
So, I have a request for all of you. Could you add your requests and bug reports to the github page when possible/convenient? I don't at all mind them discussing them here, I just could use the help keeping track of outstanding issues that need/want addressing, since my time has been so short lately. Even just a skeleton issue with a link back to a comment here would be warmly welcomed.
Thanks again to everyone for all the suggestions, reports, and cheers!
So, I have a request for all of you. Could you add your requests and bug reports to the github page when possible/convenient? I don't at all mind them discussing them here, I just could use the help keeping track of outstanding issues that need/want addressing, since my time has been so short lately. Even just a skeleton issue with a link back to a comment here would be warmly welcomed.
Thanks again to everyone for all the suggestions, reports, and cheers!
Fzero
Advanced Member
- Joined
- Mar 9, 2010
- Messages
- 4,702
Thanks nuhrin.
The proposed method of user taken screenshots into the context menu would be great IMO. I wish I could offer another consideration but this type of integration into the program is beyond my skill set I'm afraid. I wouldn't know what to suggest. It sounds like that idea you have already, and have been working on, is a good one.
Also the cheat-sheet idea you suggest sounds perfect to me, just a textual reference mapping the keys is all [me at least] needs.
Just to save having to open the cheat-sheet as a seperate PDF or refer to a hard copy printout, having within your application would be cool
The proposed method of user taken screenshots into the context menu would be great IMO. I wish I could offer another consideration but this type of integration into the program is beyond my skill set I'm afraid. I wouldn't know what to suggest. It sounds like that idea you have already, and have been working on, is a good one.
Also the cheat-sheet idea you suggest sounds perfect to me, just a textual reference mapping the keys is all [me at least] needs.
Just to save having to open the cheat-sheet as a seperate PDF or refer to a hard copy printout, having within your application would be cool
Similar threads
