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

Copernicus | # 911 | 2012-10-29, 02:12 | Report

Originally Posted by Estel View Post

3rd party applet meant to ease modifying "hidden" control values, should apply some arbitrary decision of hiding one of such options?

Right, this is pretty much the problem here; it may have been designed as a debugging tool, but it has obviously become a desirable feature for end-users. And as such, there will be those who desire for apps to manage how the tool works...

Originally Posted by

Also, depreciating X-CSSU .desktop file field, sounds like terrible idea. No reason, why people depending on this functionality, should be forced to use something else (whitelist or blacklist in transitions.ini), just for the sake of complicating possibility for enabling forced rotation.

I would agree, if the X-CSSU field was the mechanism being used to break the rotation lock -- it makes sense used in that manner. But the X-CSSU field in question here is being used to circumvent the user's choice of rotation.

Why in the world should app designers need to interfere with the user's choices? Mainly, because CSSU users want the enhanced rotation, but they don't want the headaches that come with it. And the headaches only come with it because "forcerotation" gets applied to too many apps.

A whitelist-based approach removes this problem. And as such, it removes the need for the app writer to interfere with the user's choices as well; and so, the X-CSSU "undo forced rotation" field should become unnecessary.

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

Estel | # 912 | 2012-10-29, 02:22 | Report

Originally Posted by Copernicus View Post

I would agree, if the X-CSSU field was the mechanism being used to break the rotation lock -- it makes sense used in that manner. But the X-CSSU field in question here is being used to circumvent the user's choice of rotation.

Why in the world should app designers need to interfere with the user's choices? Mainly, because CSSU users want the enhanced rotation, but they don't want the headaches that come with it. And the headaches only come with it because "forcerotation" gets applied to too many apps.

A whitelist-based approach removes this problem. And as such, it removes the need for the app writer to interfere with the user's choices as well; and so, the X-CSSU "undo forced rotation" field should become unnecessary.

Hm, I see X-CSSU "undo forced rotation" as part of fine-tuning mechanism for breaking rotation lock (fine-tune blacklist variant). In practice, X-CSSU field in .desktop file is incorporated by end-user, on demand - I have never seen it pre-defined by application maintainers.

But, probably, you're right, that it was designed for program's developers. Well, it seems that real life tends to differ from plans

---

/Estel

artpra | # 913 | 2012-10-30, 10:21 | Report

I feel like I started unnecessary (from my point of view) discussion about forced rotation.
I`m 100% with Estel - leave my freedom of choice with screen orientation on my device as it is now. There is no need to change anything, because one (me) forgot to add "pierogi" into blacklist line. If you enable forced rotation on, it`s obvious that it will apply to all apps and some of them will have messed up UI (because there were not meant for portrait usage). Forced rotation option is hidden from "non-power" users anyway, so if You are "power-user" and You enable it by hand, You must maintain your blacklist/whitelist too. It`s a common sense rule here.

First CSSU update to include some orientation restrictions will be the last for me.

The Following 10 Users Say Thank You to artpra For This Useful Post:
don_falcone, Estel, freemangordon, g0r, kent_autistic, mr_pingu, nkirk, sixwheeledbeast, Sourav.dubey, StocChr

Copernicus | # 914 | 2012-10-30, 13:06 | Report

Originally Posted by

First CSSU update to include some orientation restrictions will be the last for me.

Please, let me say that, as has been made clear to me in the last few days, forced rotation is one of the (if not the) most popular features of CSSU. I am not going to argue for its removal or restriction.

But, when you asked that question in the Pierogi thread, and I started investigating the matter, the solutions handed to me were various and sundry methods for the app writer to block forced rotation. This, to my mind, is a step backwards -- it takes the rotation choice away from the user!

As you note:

Originally Posted by

If you enable forced rotation on, it`s obvious that it will apply to all apps and some of them will have messed up UI (because there were not meant for portrait usage).

Right! This option messes up some of your apps. It always messes up some of your apps; it wasn't designed to be used as a feature!

Switch to a whitelist-based forced rotation mechanism, and this problem disappears -- apps are only messed up on a case by case basis. And you can still force every app to rotate -- there's no need now for app writers to try and stop you...

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

artpra | # 915 | 2012-10-30, 13:44 | Report

You prefer whitelist approach, I prefer blacklist approach and for some it won`t matter at all (locked in landscape) - so what? Let them decide. And I don`t care if it was some "debugging_dev_only" option or not, because it is working for me and does what I want - right now I have pierogi locked in landscape (like it should have been and like You intended it to be) with bunch of other apps in portrait.

I`m really trying but I don`t see where is an argue here, because surely not about having a possibility of choice?

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

Copernicus | # 916 | 2012-10-30, 14:21 | Report

Originally Posted by artpra View Post

You prefer whitelist approach, I prefer blacklist approach and for some it won`t matter at all (locked in landscape) - so what? Let them decide. And I don`t care if it was some "debugging_dev_only" option or not, because it is working for me and does what I want

Sure, that's fine -- but it brings up another point. Just what userbase is the CSSU intended to serve? Certainly, devs and power users can enjoy it now; but this "debugging dev only" option seems likely to trip up novice users. You really need to do a lot of massaging of config files to get this "feature" working right. So, is this really meant to be the next "Seamless Software Update"?

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

thedead1440 | # 917 | 2012-10-30, 14:34 | Report

One point I was thinking of:

- When Nokia release a SSU, app developers have to at times change some components of their app to get it working with the new update

- Taking this logic, shouldn't app developers be using the X-CSSU in the .desktop file then if necessary? After all to make apps compatible an app developer too has to make changes at times?

No offence against anyone just my 2 cents...

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

Copernicus | # 918 | 2012-10-30, 14:54 | Report

Originally Posted by thedead1440 View Post

shouldn't app developers be using the X-CSSU in the .desktop file then if necessary?

Yeah, but if the user then wants to force the rotation of that app, they have to both turn the forcerotation on, and edit the .desktop file. Kind of a pain.

I guess that's my question -- is forced rotation still meant to be a debugging tool (so having lots of broken apps around when you turn it on is fine), or a feature (where you want all apps to work correctly)? It just doesn't seem designed efficiently for use as a feature...

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

thedead1440 | # 919 | 2012-10-30, 15:04 | Report

The popularity of it suggests its more of a feature than a debugging tool IMO...

If an user wants to force rotation of an app that isn't meant to be rotated then the additional step seems justified...

I get what you mean though; the app developer does one step extra which isn't required in the event of a whitelist and to reverse the developer's change the user again does one step extra in the current arrangement of using the X-CSSU line in the .desktop file...

Last edited by thedead1440; 2012-10-30 at 15:20.

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

marmistrz | # 920 | 2012-10-30, 15:24 | Report

Originally Posted by Copernicus View Post

Right, this is pretty much the problem here; it may have been designed as a debugging tool, but it has obviously become a desirable feature for end-users. And as such, there will be those who desire for apps to manage how the tool works...

I would agree, if the X-CSSU field was the mechanism being used to break the rotation lock -- it makes sense used in that manner. But the X-CSSU field in question here is being used to circumvent the user's choice of rotation.

Why in the world should app designers need to interfere with the user's choices? Mainly, because CSSU users want the enhanced rotation, but they don't want the headaches that come with it. And the headaches only come with it because "forcerotation" gets applied to too many apps.

A whitelist-based approach removes this problem. And as such, it removes the need for the app writer to interfere with the user's choices as well; and so, the X-CSSU "undo forced rotation" field should become unnecessary.

I think that X-CSSU field is very necessary. If you don't even think about portrait (you don't give a damn) you omit it. But if you know your app is unusable in portrait (e.g. Calendar, Qt Quick apps), you X-CSSU it! And if an user really wants it, he just edits .desktop