MiniMenu: Initial view misses app icons (few exceptions though)
In the initial view after launching MiniMenu (after booting or GUI-switch), allmost all apps only show a generic icon, sometimes a few apps within that view do show their correct icon. As soon as you scroll up/down (if you have enough content in that folder) or move to another folder, all apps show with their correct icons. If you navigate back to your initial view (the initial folder and scrolling position), the situation is still unchanged.
1) The situation is resolved:
- after you run and quit an arbitrary app
- or manually trigger MiniMenu's "Rescan for applications"
Then, all icons are shown correctly again.
2) I tried to figure out a pattern for which icons are drawn, and which not. It seems to me that icons of some <sdcard>/pandora/apps and some system shipped apps were drawn, and those from <sdcard>/pandora/menu were not drawn, but I am not sure, as I cannot test for every possible situation within reasonable time. The knowing developer can surely track the bug more easily.
MiniMenu: Custom sub categories not shown anymore, affected apps instead show in category "Other"
My apps with custom assigned sub-categories are not shown anymore within their appropriate parent categories, but rather in a top category called "Other".
Example: an app which was originally delivered as cat "Game" sub-cat "ActionGame", to which I assigned the sub-cat "Platformer", an assignment which is kept in an .OVR file, is suddenly shown within the cat "Other". Previously it was correctly shown as cat "Game" sub-cat "Platformer".
Bug was also observed by
@ocean.
MiniMenu: Many apps fails to start in MiniMenu, but work in XFCE (Pandora OS 1.7.a2)
This bug was also mentioned in other words by
@ocean.
After the OS update from 1.6 to 1.7.a2 some apps don't start anymore and don't even create a pndrun log file, when called from MiniMenu, but started ok in XFCE:
- Comix
- Crimson Field
- Deathtrap Remix
- No Gravity
- PCSX ReARMed
- And likely many more!
I stopped testing, as it's exhausting, and as this sample of failing apps is hopefully large enough for the dev, to figure out the bug!
Maybe it has to do something with the new SDL integration...?
MiniMenu: Hidden app settings not kept after OS update
The settings for hidden apps are not kept after an OS update, either because the reside in the NAND and are thus deleted in the process, or as the new version of MiniMenu disregards its elder version's settings.
MiniMenu: After hiding an app, focus should be on nearest sibling
After applying the command "Hide application", the focus should be on the nearest sibling (before or after the hidden item) rather than the first item in the folder (status quo).
MiniMenu: Return state not last focused item, but last launched item, or something inbetween ...
- If an app is launched, then quitted, MiniMenu always restores the full previous state (last folder and last item focus).
- If MiniMenu returns after a reboot or GUI-switch, something inconsitent happens:
- MM returns to the previously focused item, ONLY if that item was also the most recently launched item.
- MM does not consider the recently focused item!!! Instead it jumps to the first item of that folder (the ".." entry), or even the parent folder. Or the last launched item or its folder. Cannot really trace the pattern here. The dev will know it.
An even more variation of this bug is the next one, but I only experienced it once.
MiniMenu: Return to last state selects app in category instead ob sub-category (occurs rarely)
Rare bug - After quitting an app, MiniMenu did not completely return to the previous state (recent sub-category-folder and app focused), but rather focused the app in the category-folder and one could not navigate to any other sub-category-folder anymore, one was stuck within that category-folder.
Was in cat "All", shut down, restarted, suddenly was in sub-cat "AdventureGame".
WLAN enabling still slow (about 25 secs)
WLAN enabling on smartphones takes at most 5 seconds, on the Pandora it still needs about 25 seconds!
* Activate hardware module (From what the GUI elements in the task bar show me, this task consumes the most time, the remaining tasks happen quite fast)
* Find known SSID
* Login to SSID)
Strange ".wh..wh.orph" folders on SD card after OS update
I had a backup of my FAT32 formatted SD card with the state of Pandora OS 1.6, then updated to OS 1.7.a2, then did a dry rsync run off the new SD card state (1.7.a2) against the old backup state (1.6), which shows file/folder differences, and I discovered this:
Within various app's appdata folder an invisible folder by the name of "
.wh..wh.orph/" was created. Some of the affected apps did not even have an appdata folder before, and have also not been launched since after the OS update. Therefore the reason for these folders must be an process which scans within the appdata directories. MiniMenu or libpnd maybe involved?
Excerpt:
Code:
appdata/animatedclock/.wh..wh.orph/
appdata/berusky/.wh..wh.orph/
appdata/crystalstacker/.wh..wh.orph/
This problem of the mysterious "
.wh..wh.orph" folders was already described in an
other thread.
