[Announce] CSSU Testing thread - Page 89 - maemo.org

conred | # 881 | 2012-09-30, 14:20 | Report

Bzip2 is part of busybox. Do you have installed Enhanced Busybox?

Originally Posted by conred View Post

After installing busybox 3:1.10.2.legal-1osso31+0cssu0 over busybox 3:1.10.2.legal-1osso30+0m5 the bzip2 program does not work properly. It shows:

Code:

# bzip2
bzip2: applet not found

This leads to problems with apt-get update for example. Shows the same error while trying to extract the package lists.
My first thought, reverting to ...0-0m5, doesn't change anything.

Edit: I've also installed busybox-power, could this be related to the error?

Edit 2: Ah, I wasn't aware (or forgot) that busybox-power replaces normal one. Problem solved by

Code:

 apt-get install --reinstall busybox-power

The Following 2 Users Say Thank You to conred For This Useful Post:
joerg_rw, Sourav.dubey

Copernicus | # 882 | 2012-10-26, 21:02 | Report

Hey, a question for the CSSU folks: I've recently been getting more and more comments about how poorly my app (Pierogi) handles portrait mode. Now, this makes sense, because my app doesn't handle portrait mode at all; Pierogi (an infrared remote app) needs to use the IR LED, and as such, doesn't work very well unless you've got that LED pointed away from you. So I feel justified in locking the app to landscape mode.

However, the "forced-rotation" option of CSSU has apparently become extremely popular amongst users. Just today, I received one note that I could improve my app by locking it into landscape mode (which, of course, I've been doing since I started writing it), and another note that I could try to manually catch the DBUS rotation signal and thereby create my own "landscape lock" functionality that avoids the standard code that the forced-rotation option breaks. (I feel like my app is being penalized for using the official Qt rotation handler!)

I understand that "forced-rotation" was originally supposed to be just a debugging feature, but it certainly appears to be more than that today. So let me ask: is forced-rotation really still necessary? How much of a hardship would it be to remove it from CSSU? Or is it now a necessary feature?

And, if it is now more of a feature than a debugging tool, can it be modified to use a "whitelist" mechanism rather than a "blacklist" mechanism? That seems more logical to me. Ultimately, if we're going to force CSSU end-users to do extra work (by adding names to a list), I'd prefer that they do it when they want to change the default behavior of an app, rather than do it to get an app back to working the way it was designed...

The Following 11 Users Say Thank You to Copernicus For This Useful Post:
don_falcone, Estel, fw190, hxka, kent_autistic, MartinK, mr_pingu, peterleinchen, shanttu, sixwheeledbeast, Xagoln

hxka | # 883 | 2012-10-26, 21:10 | Report

Well, whitelist is already implemented since PR 1.3.3.7-10.5, and I use it with FBReader, it works just fine.

mr_pingu | # 884 | 2012-10-26, 21:20 | Report

Originally Posted by hxka View Post

Well, whitelist is already implemented since PR 1.3.3.7-10.5, and I use it with FBReader, it works just fine.

In that case forced-rotation can be removed and only keep withelist

The Following User Says Thank You to mr_pingu For This Useful Post:
Copernicus

Copernicus | # 885 | 2012-10-26, 21:22 | Report

Originally Posted by hxka View Post

Well, whitelist is already implemented since PR 1.3.3.7-10.5, and I use it with FBReader, it works just fine.

Ah, my apologies; I haven't been keeping up with CSSU as well as I should. So, if there is an editable whitelist now, would it be possible to remove the "forcerotation" option from the transitions.ini file? Users who need to break the rotation locking mechanism could instead do it on an app-by-app basis, rather than breaking all of the apps at once.

Edit: mr_pingu beat me to the same question.

qwazix | # 886 | 2012-10-26, 21:32 | Report

Forced rotation is disabled by default. People who enable it and then complain shouldn't be, frankly it's their fault. To remove the option (which is hidden in transitions.ini by the way) because some people enable it without really needing to seems too appleish too me. Maybe including a new transitions.ini with a well tested whitelist with next cssu and urging users to not re-enable forced rotation would be a good compromise.

The Following 4 Users Say Thank You to qwazix For This Useful Post:
Copernicus, Estel, g0r, sixwheeledbeast

sixwheeledbeast | # 887 | 2012-10-26, 21:36 | Report

Originally Posted by qwazix View Post

Forced rotation is disabled by default. People who enable it and then complain shouldn't be, frankly it's their fault.

I agree.
If you use forced-rotation you should be expected to maintain your own transitions.ini file.

So Copernicus your back to square one then really, I wouldn't worry about it.

The Following 3 Users Say Thank You to sixwheeledbeast For This Useful Post:
Copernicus, Estel, mr_pingu

Copernicus | # 888 | 2012-10-26, 22:09 | Report

Originally Posted by qwazix View Post

Forced rotation is disabled by default. People who enable it and then complain shouldn't be, frankly it's their fault.

and

Originally Posted by sixwheeledbeast View Post

If you use forced-rotation you should be expected to maintain your own transitions.ini file.

Sure, I agree. But, I've gotta say, the question of CSSU forced rotation has come up more than once in the Pierogi thread now. I'm not sure why I'm the one who needs to be educating people about how to use their transitions.ini file.

If the CSSU is aiming to be the next SSU, I think it'd be better to err on the side of caution. The way that the forced-rotation option breaks rotation locks in every single app is, I think, perhaps more trouble than it is worth. (At least for those of us who don't want their locks broken.

)

Originally Posted by

Maybe including a new transitions.ini with a well tested whitelist with next cssu and urging users to not re-enable forced rotation would be a good compromise.

Er, but isn't that the situation we have today? It sounds like forced-rotation is already disabled by default, and that a whitelist already exists.

If there's an editable whitelist, wouldn't that be a better option for end-users? Better to break each app's lock individually, than globally remove all of them...

The Following User Says Thank You to Copernicus For This Useful Post:
sixwheeledbeast

sixwheeledbeast | # 889 | 2012-10-26, 22:19 | Report

Originally Posted by Copernicus View Post

If there's an editable whitelist, wouldn't that be a better option for end-users? Better to break each app's lock individually, than globally remove all of them...

Issue is it's not always that easy to find the correct words to enter in the whitelist or blacklist to make the rotation work.

Hence and thus not easy to make a whitelist GUI.

The Following 2 Users Say Thank You to sixwheeledbeast For This Useful Post:
Copernicus, Estel

qwazix | # 890 | 2012-10-26, 22:30 | Report

The reason that people do enable forced rotation it's that it's an easy way to force all stock apps to work in portrait (most work pretty well). If there is a whitelist pre-loaded with cssu which has all stock apps which are reported to work glitch free included, (and maybe some unmaintained apps from extras) people will not need to go and enable forced rotation again.

That's why I proposed a pre-defined whitelist.

The solution to the names problem could be a shortcut that copies the name of the active application to clipboard (in some way what xkill does but instead of killing, just copy the name to clipboard)

I think I have seen another X tool that does something similar with the window id, and other application info.

The Following 2 Users Say Thank You to qwazix For This Useful Post:
Copernicus, Estel