View Single Post
Jaffa's Avatar
Posts: 2,535 | Thanked: 6,681 times | Joined on Mar 2008 @ UK
#1018
Originally Posted by Mentalist Traceur View Post
Anyway, back to this: if forcedrotation is only meant to be a tool, you'll still leave it in as a usable option, right? Or will it eventually be pulled out?
I don't see why it'd be pulled out; and keeping it in transitions.ini fits with the other options in there.

The fact that apps that were built before portrait auto-rotation was common and thus don't support it, in my mind, isn't a good reason to throw out the newer and better model, or to hold back portrait support when at the end of the day, there's no reason most of those apps didn't have portrait support to begin with other than the fact that portrait mode wasn't an option at first.
Well, as an app author I wanted to follow the style of Clock and Hildon Application Manager. Doing that whilst supporting auto-rotation is harder work. So I didn't. Forced rotation breaks it.

I guess the point of this sleep deprived rant is that it sounds like the future plan is something of a reversion to a default-rotation-off-unless-pre-programmed-that-way-with-an-auto-rotate-on-flag-in-the-code approach.
That's not a reversion! Forced rotation is a hack. An interesting one, but a hack nonetheless. There's no way a blacklist can cover all the options, all the apps in Ovi, all the apps a user might have internally. A whitelist is the only safe option.

And I just don't see a good reason for that. It is far more effective, I think, to make non-auto-rotation a conscious choice for developers if they wish to hard-code non-auto-rotation into the program...
We've already lost some developers. Who's going to go back and add "don't rotate" patches into something which might be languishing?

and barring that, let things auto rotate, and give users some built-in 'lock' system built in to Hildon Desktop itself to force specific apps into one orientation or the other only if they so chose.
An orientation lock is planned, but for the purpose of when you're lying in bed it doesn't rotate superfluously whilst browing the web (say). Not sure that's what you're referring to.

Seems that my changes were in the wiki page originally made, not the one Jaffa placed under development. Personally, I think it should've been outside there, but linked to from CSSU development, actually, because whether or not an app works well in portrait seems to me to be a more general thing, than just the CSSU specifically. (Though they obviously are significantly linked.)
I've moved "Portrait mode" under Community SSU/Features. "In-built applications", for tracking the source and status, of Nokia's apps is under Community SSU/Development.

Perhaps "Portrait mode" should be moved back out from under Features, but if you do so, please bear in mind:
  • Our wiki uses sentence capitalisation for page names.
  • "Portrait mode" isn't very descriptive.

If it's called "Portrait mode", it should have an introduction to the various methods (rotatedaemon, CSSU's forcerotation & Ctrl-Shift-R) and then have against each app whether it supports rotation out-of-the-box (Phone & Browser) or whether or not it needs to be forced.

I'd also suggest "Fully usable" is reserved for those which have no bugs. This can then form the basis for the out-of-the-box whitelisting and force rotation.
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
 

The Following 6 Users Say Thank You to Jaffa For This Useful Post: