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.