Active Topics
-
TLS 1.2 for N9 is ready (29)
to MeeGo / Harmattan by smatkovi - 7 hrs, 5 mins ago -
Error after installing Leste on sdcard (12)
to Maemo 7 / Leste by teroyk - 7 hrs, 52 mins ago -
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 3 days, 16 hrs ago -
Maemo repository (3)
to Community by torsen - 4 days, 8 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 6 days, 13 hrs ago - more...
| The Following User Says Thank You to Copernicus For This Useful Post: | ||
 |
|
2012-10-29
, 02:22
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#912
|
Originally Posted by Copernicus
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.
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.
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
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 |
|
2012-10-30
, 10:21
|
|
Posts: 158 |
Thanked: 355 times |
Joined on Sep 2011
|
#913
|
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.
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: | ||
 |
|
2012-10-30
, 13:06
|
|
Posts: 1,986 |
Thanked: 7,698 times |
Joined on Dec 2010
@ Dayton, Ohio
|
#914
|
First CSSU update to include some orientation restrictions will be the last for me.
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:
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).
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: | ||
|
|
2012-10-30
, 13:44
|
|
Posts: 158 |
Thanked: 355 times |
Joined on Sep 2011
|
#915
|
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?
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: | ||
|
|
2012-10-30
, 14:21
|
|
Posts: 1,986 |
Thanked: 7,698 times |
Joined on Dec 2010
@ Dayton, Ohio
|
#916
|
Originally Posted by artpra
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"?
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
| The Following User Says Thank You to Copernicus For This Useful Post: | ||
|
|
2012-10-30
, 14:34
|
|
Moderator |
Posts: 6,215 |
Thanked: 6,400 times |
Joined on Nov 2011
|
#917
|
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...
- 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: | ||
|
|
2012-10-30
, 14:54
|
|
Posts: 1,986 |
Thanked: 7,698 times |
Joined on Dec 2010
@ Dayton, Ohio
|
#918
|
Originally Posted by thedead1440
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.
shouldn't app developers be using the X-CSSU in the .desktop file then if necessary?
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: | ||
|
|
2012-10-30
, 15:04
|
|
Moderator |
Posts: 6,215 |
Thanked: 6,400 times |
Joined on Nov 2011
|
#919
|
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.
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: | ||
|
|
2012-10-30
, 15:24
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#920
|
Originally Posted by Copernicus
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
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.
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.