01micko wrote:Still no luck for me with Seamonkey playing html5 sounds, but other than that it runs just fine.
That would be two of us. This time SM was compiled with all the codec libraries already available, so I'd expect to hear something (although it may be broken). Mav said the sound works for him. My guess at this time: since the CPU doesn't enough power to decode the video, SM decides to turn off sound to make the experience less annoying. Just a guess
The wifi.sh works ok for me.
Glad to hear that.
Also, my drive icon is partially off screen. This was in alpha 1 too. Res is 800x480, same as a eee-701.
FatdogArm using the new code used in Fatdog Next, where I have totally re-written the deskop icon placement. You're not the first one to report, kirk said the same thing as well but I can't reproduce it. Now that I know you have problems on 80x480, perhaps I can simulate that resolution in Qemu and get to the bottom of it.
I'm about to release an XO-build
![Laughing :lol:](./images/smilies/icon_lol.gif)
for development.
Wifi.sh fails to reconnect after suspend for me.
I need to figure out what the XO does after resuming. In PC architecture with acpid, events will be sent to acpid which will execute certain scripts after resuming. Obviously there isn't acpid in XO (or ARM in general), but I'm sure there is some kind of userspace hook that the XO will call after resume. There, we can insert "wifi.sh -a" to restart the connection of some sort (may still need to hack wifi.sh to get it to work correctly).
net-setup.sh also the although "laborious" works consistently.
net-setup.sh works; the reason why I haven't included it is because I have used it on my slackbone32 setup and it doesn't always work (not its problem, mainly because of borked wireless and/or routers); plus it is a bit old and unsupported. What do you think of the SNS? I have never looked at the code but I have used in early versions of Wary and it looked good too.
That being the case, if the conclusion is that net-setup.sh is still the best approach (aside from totally re-writing a new GUI from scratch ...) then I don't mind putting it in.
It also fails to work at all in XO-1.75 with "illegal instruction".
Could be the WPA supplicant. Encryption is something that can be greatly improved by NEON, so I won't be surprised if during the build wpa_supplicant automatically picked it. Will need to have rebuild wpa_supplicant to do run-time detection (or worse comes to worst, we will need to have two different versions)..
On another matter, Seamonley-2.20 feels very slow both in starting and rendering. Is there any major advantage or security improvement over 2.19?
Security improvement is always there --- (as in, they fix security-related bugs). Feature-wise, not so much.
Other than that, the only difference in build-time configuratio between 2.19 and 2.20 is that:
a) 2.19 is en_GB, and that will automatically disable spell checker (2.20 is en_US and that comes with spell checker)
b) 2.20 is built with --disable-elf-hack (this was the source of my 10+ failed builds). This parameter may make SM slower to launch, but it shouldn't affect run-time at all.
c) 2.20 comes with Calendar extension for the mail component (2.19's calendar didn't work so I didn't include it).
You can actually install SM 2.19 and SM 2.20 side-by-side; the only thing to watch out is that /usr/bin/seamonkey and /usr/lib/seamonkey will be overwritten (but you don't need /usr/lib/seamonkey and for /usr/bin/seamonkey you can always make a new symlink that points to the right location --- either /usr/lib/seamonkey-2.19/seamonkey or /usr/lib/seamonkey-2.20/seamonkey).
From my totally unscientific testing, SM 2.20 feels just about the same as SM 2.19.
No, because omni.ja can't be unzipped by busybox's unzip. I may have to install the full unzip to do so.
faster seamoney trick should also be used in the next fatdog64, wondered why it was still slow to start even when the whole filesystem was decompressed using the expand2ram trick.
Yes, will do that in next release.
Also Barry talks about switching from xz compression to gz as an option when copying sfs to hard drive from cd, wonder if same could be done with ArmAlpha2, say a script to check size of SD and auto expand sfs as gz or flat uncompressed.
FatdogArm SFS is already compressed with gzip. It is quite straight-forward too to expand the SFS and run it as semi-full-install, but then you'll lose the benefit of easy backup and easy "factory reset" ...
cheers!