Guys, there is an option in .desktop file to prevent portrait mode even if forced-rotation is enabled.

X-CSSU-Force-Landscape=true

Ok, cool, that's then a third way (by my count) to undo the undo of the locks.

(Actually, this one sounds more reasonable; it doesn't require adding new code or creating new files, and hopefully "X-CSSU" entries in the .desktop file should be safely ignored by non-CSSU systems. I'll give it a try.)

next step is someone building a patch that overrides x-cssu-force landscape and then an app developer will want to force landscape and devise a new method of forcing landscape.

I think copernicus has a point here.

When I'm using camera-ui, the app sometimes rotates, even though it has the option in .desktop.

Well, there is a zillion way one can break own system, and if we would like to block every one of it, we would end with apple.

Fortunately, nothing is enabled by default, so I rather see whole of it as "user error" case.

/Estel

Well, sure. But in this case, we've got an option that removes a piece of system functionality for all apps, which the user then has to clean up after on an individual app-by-app basis. I just think it would be more logical to force users to break their own apps individually (using the whitelist system); I would think that users of, say, Pierogi would be more likely to understand why the app is failing them if they remember adding that name to a force-rotation list.

Right now, it seems like I'm getting users who have forcerotation set without really understanding the implications. If CSSU becomes the standard, that's only going to become more common...

but why would we want to force users into anything? currently, there is whitelist mechanism (less popular, as introduced later, but it is there), blacklist mechanism, and .desktop file lock. I.e 3 different (and sometimes, mixable) ways to tune forced rotation, if one decide to turn it "on", at all.

While I understand your reasoning, it seems like prime example of situation, where users got habit of handling debugging bits *wrong* way. I, for one, wouldn't be very happy, if someone would force me to switch from my current blacklist* approach to whitelist, just because someone don't know how to use it properly.

It's all about freedom of choice. Sure, it would be great if "someone" would do the hard job of providing portrait-compatible replacement for every closed source, stock GUI program on Maemo - this way, forced rotation would become obsolete - but, until that, it seems that 3 different, easy to understand options of handling it, is enough.

/Estel

*my blacklist approach - upon installing every program, I check IF it have build in portrait support. IF = false (very rare case, nowadays), I check IF it works OK with forced rotation. IF = true, I do nothing. In any case other than presented above, I add program to blacklist.

If I would be determined enough, I could even write a simple script for handling that "automagicaly" - but, in fact, it's easy, natural, and superfast process, most of the time, so it doesn't seem worth effort.

// Edit

the only situation, where forced rotation locks fail miserably, is handling programs written in python (or similarly, handled by one binary) - this way, no matter what, user can blacklist/whitelist all of them, or none (by blacklisting/whitelisting "python").

It's probably sole reason, why someone "invented" avoiding forcedrotation via watching for d-bus. Here I agree, that it's tragically suboptimal, and any better approach - if possible - would be appreciated.

Solution that I believe is a good compromise:

Create new transitions.ini with a proper whitelist and deploy with next cssu.
Inform users in cssu installation message and in comment above forced-rotation in transitions.ini that setting this option is obsolete, and guide them to use whitelist.
Deprecate X-CSSU-Rotation .desktop entry
Notify CSSU-Settings-Configuration maintainer to remove the forced rotation setting

This way all user's rotation setting will be turned off. Most them will not notice at all as whitelist should work just as well. Users with modified transitions, hopefully will read the information message before restoring their old file. Having a proper whitelist will be enough so that people won't go back to enable forced rotation again, and if they try to, they will find that it is missing from CSSU-settings applet, so they must really want to do it, open transitions.ini, where they are bound to see the comment explaining the situation.
The procedure allows freedom to enable this setting, keeps the people who forced in about the same situation as before, and doesn't introduce a new layer of forcing orientation besides the official maemo one.

Sorry for kind of repeating, but I wanted to consolidate my proposal to one post instead of having to skim through the the last few pages to see what I'm talking about.

Isn't the point of forced rotation to find the list for the whitelist.
Has this been done is this complete enough to have a full stable whitelist.

This part sounds like a no-go. While personally, I don't use CSSU-Settings applet (prefer to edit transitions.ini by hand), why the hell, 3rd party applet meant to ease modifying "hidden" control values, should apply some arbitrary decision of hiding one of such options? Just because it become too popular? No way.

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.
---

C'mon people, next day we're going to discuss how to complicate installing rootsh package, just because 80% of people with "help" threads on TMO, messed with their configs/filesystem, by using root access.

/Estel