Release Zaxxon Hotfix 7 Alpha 2 - Merry Christmas :)


Was able to test a bit now. And the touchscreen is really smooth now. That is a huge improvement: Well done!


But in mypaint I cannot draw single lines anymore. they all are connected, even when I don't touch the screen in between lines.


Also I found, that cellwriter doesn't work anymore because of missing libesd.so.0. Was it removed?
 
In mini menu there is no network tab,how you suppose to set clock speeds in some of the browsers.
 
Last edited by a moderator:
I don't know if this is the best place to post this, but I'll put it here anyway.


I was going to post this under the Hotfix 6 thread in the Software forum, but I thought it might be better here now there's a new hotfix being tested.


I've been using Mousepad (the text file editor) quite a bit recently, and found that both the find function (CTRL-F) and the replace function (CTRL-H) on it does not work correctly.


The first time I do a find or replace it works fine, and the find next (F3) function works fine too, but on the second and subsequent times the find/replace function refuses to work. No matter what I type in the 'find what' box (and the 'replace with' box when using replace), the 'find'/'find and replace' button is greyed out and will not work.


I hope this can be fixed soon since I find it rather incovenient having to exit mousepad and reopen the text file every time I need to find/replace something different.
 
Last edited by a moderator:
Lots of changes to mmenu and some to libpnd, to do some preliminary speedups to bootup time and usage; more speedups to come at a later date.


But bound to be a few issues pop up .. I've not read this thread yet, just a heads up that post your bug reports .. I'll be working on mmenu and libpnd again early next week :)


jeff
 
Repeat? Linky?


(serious sleepdep due to the twins, so my memory is nil; I can barely remember stuff from a day or two ago :p )


If you mean.. seeing somethign like an fxe or gpe and special handling them, such as invoking a systemn-included ginge .. culd be pretty easy to put into the directory browser mode; or do you mean parsing Caanoo .ini's to try and map them into the pnd categories?


jeff
 
I installed, tested A LOT and very systematically, and wrote up A LOT OF BUGS.


But before submitting I first need to clarify one thing:


I flashed with this image file:


http://www.openpando...ndora.ubifs.img


Its MD5 checksum is:


91dfb51fb4a1f398331d8f81262b1c8b


Its date is 2011-12-24, and its boot screen says "Release 1, Hotfix 6, Alpha 2".


@ED: You ED, here promote an image from 2011-12-24 as "Release 1, Hotfix 7, Alpha 2".

  • Did I download another image? (can be determined from link/checksum)
  • Is the bootscreen wrong?
  • Or did you promote it as the wrong version here on the boards, and 1.7.a2 is instead correctly 1.6.a2 ?


UPDATE: I misread the boot screen: It indeed reads 1.7.a2. Additionally my checksum matched the published one. Puzzle solved.
 
Last edited by a moderator:
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 ...

  1. If an app is launched, then quitted, MiniMenu always restores the full previous state (last folder and last item focus).
  2. 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.
 
Last edited by a moderator:
Didn't read yet, but there are some known issues; I don'tr fall if I've fixed them or not (my mind is not what it used to be ;) -- but with this new mmenu using .desktop instead of pnd scanning (default behaviour, you can configure it to use old behaviour with textfile spelunking), its possible that mmenu is coming up before pndnotifyd is finished emitting the .desktop files, or the icons. So if mmenu comes up too quick, things will not show up right. ED found this out a couple weeks back, but I don't recall if I fixed it yet .. apparently not :)


Right now mmenu is set to try to load icons 'on demand, page at a time'; ie: when it shows a page, it stops and loads icons then shows the page so all thew icons are there; I think we've set it to not load icons ahead, and just wait for them to be needed. (ie: contrary to what I had expected, if I start loading icosn in background it tends to slow things down enough where you'd actualyl prefer just to have it load on demand, and super fast then. If its loading ahead page at a time, its slowing you down a tiny bit, and you might be changing categories or going the other direction or something, so the cache-ahead cost may not be worth it. Interesting stuff. But you can hit the conf files with a text editor and have it perform as you see fit, scanning ahead and so on..)


So some changes I expect to add soon are..


- signalling between pndnotifyd and the system such that apps can know when it is busy; might just be a lockfile, rather than dbus or somethign fancy.. we'll see. This way mmenu (or other libpnd users) could know to start consuming apps once pndnotifyd is done. (Beforfe, mmenu didn't depend on anything and did pnd scanning itself .. handy if you run without anythign else, but so far our base firmware always has pndnotifyd doing the work for xfce anyway, so why not leverage it for mmenu too?)


- less updating the .desktop files in /usr/share/applications and ~/Desktop; if they're due to be emitted, but identical to existing, just skip it.. this shoudl save on inotify spam, and speed up Panorama and such


- merge a few categories in the same way xfce is set to, so that xfce and mmenu present the same menu in different way; right now, theres a few cases (audio and video notibly) where mmenu may show s[plit categories and xfce merging them


- and more :p I'm sure lots of bugs from these rather significant mmenu changes, as noticed above by everyone; thanks for jumping into the alpha rounds to test :)


Now let me read up a bit..
 
Great report porg, thanks! A few things are things I noticed during building but thought I'd taken care of (the state restoring to the wrong or 'older' place, so will look into it.) .. Lots of work for me ;)


The .wh* type files are part of the aufs union-filesystem stuff; for some reason aufs leaves those 'turds' behind. I've never looked into it, but its a known thing. You can generaly remove them when you find them (after pnds exit anyway). I think pnd_run.sh does or used to attempt to clear them out on its own, but maybe theres some other cases where they get left behind.


jeff
 
PCSX reARMed r12 works fine for me on OS 1.6a2
@MilkShake: On my Pandora OS 1.6.a2, PCSX reARMed r12 launches fine from XFCE, but fails to start from MiniMenu! Can you please report the different launching behaviors on your Pandora? Thanks!
 
Last edited by a moderator:
@skeezix: Not to forget, now is the time for public praise! What everyone obviously must have noticed: Using MiniMenu got a lot more efficient and feels way faster! Caching/loading is faster, and returning to the same state saves you a lot of unnecessary navigation time! Now the Pandora is much more suited for situations where game time is limited and needs to be aborted abruptly (bus, station, etc). The time to quit and app, wait for MiniMenu to get responsive, to then trigger shutdown, changed from about 20 secs to 6 seconds! Great! The other MiniMenu bugs/features will be taken care off, I'm quite certain and positive!
 
There you go! Please report your experience from launching in MiniMenu. For PCSX, and the other example apps I listed, if you like. I quite certain, they will also fail launching on your system (as your run the same HW, OS and PND SW).
 
Everything works for me from Minimenu, Notaz psx emu being what I'm playing the most lately.
 
Repeat? Linky?


(serious sleepdep due to the twins, so my memory is nil; I can barely remember stuff from a day or two ago :p )


If you mean.. seeing somethign like an fxe or gpe and special handling them, such as invoking a systemn-included ginge .. culd be pretty easy to put into the directory browser mode; or do you mean parsing Caanoo .ini's to try and map them into the pnd categories?


jeff

LOL! well I don't have a linky, but basically a while back I was hacking around with GMenu2X source and trying to make a Pandora version, but also adding in support of NotazSDL (which is now included in this hotfix...) and also support running gpe files via ginge from the menu. You played with the idea of integrating this into minimenu... Also I reached a brickwall with gmenu.


Basic idea would be detecting if user has a ginge pnd installed and then providing a new category with supported gpes, etc.
 
Back
Top