This is probably why Nokia never planned to implement it.

What's not impossible is the stuff I outlined above:

if apple can do it, so can we. well not me personally because im useless but the brilliant developers we have as part of the community.

edit: jaffas idea i mean

Done it .

Added detail in the comments of X-Term and Web in the 1st party applications for the portrait compatibility wiki.

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? Personally, I think the eventual end result on the N900 will end up being, for a lot of users, that we have system-wide portrait support anyway - and this, while it might be intended as a tool, basically does most of the task already - actually, I really feel that at this point, creating a user tweakable blacklist of "don't rotate" apps would be far better, in my opinion. But I suppose that's not really CSSU business as of yet.

*Shrug*

My opinion is though, your last two CSSU updates both made portrait functionality, whether that was the intent, and have presented a rather good view of how Hildon would feel if this Ctrl-Shift-R mess was deprecated and autorotation became the norm. It should be possible for apps to still have user configurable options to lock them to either portrait or landscape, but I don't see why the above can't be the 'norm'. Just make it still possible for the Ctrl+Shift+R combo to have a toggle effect, but beyond that, I don't see why it can't be made the norm.

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.

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

A, it puts the control back into the user, and B, it's more future proof. As I said, you're making strides in making Hildon functionally portrait capable, and just because some of the older apps still suck at portrait, doesn't mean the norm should be not-auto-rotate.

- Edit -

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

- Edit 2 -

Oh it's two slightly different pages; one specifically built-into-CSSU, the other still being the in-general one. NVM.

is there a portrait task manager in the works?

Some applications on iOS are landscape-only. Mostly games like Angry Birds.

I don't see why it'd be pulled out; and keeping it in transitions.ini fits with the other options in there.

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.

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.

We've already lost some developers. Who's going to go back and add "don't rotate" patches into something which might be languishing?

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.

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.

I'd like to thank all of you who have made the Community SSU possible.

Most of the bug fixes and features of CSSU are really nice. However, after uprading to CSSU from base PR1.3, my N900 seems to be somewhat more unstable than before. Most of you propably have experienced the I/O-wait / trashing episodes when you have used all the RAM, the N900 is swapping, and at the same time you write to your MMC flash? I use gPodder all the time, and typically that means downloading hundreds of megabytes of mp3 files. Often I have couple of web browser windows open etc. taking lots of RAM so this leads to swapping. Before the CSSU this meant that the N900 was totally unresponsive for long time, some times even 10 minutes, but if I just waited, it would come back to life after the slow flash memory controller got all the I/O done. However in the last week or two my N900 has crashed and rebooted many times under these circumtances (heavy load). It just dies, and since there is no syslog or anything, it's quite hard to tell what happened. The last time this happened today, the FAT filesystems corrupted and were mounted read only (doing the fsck thing in windows fixed that).

Am I the only one with this problem? I understand that the kernel or most other low-level software components have not been modified with CSSU so it might be just a coincidence and bad luck.

Anyway it would be GREAT if the CSSU folks could find out a way to optimize the kernel to avoid these horrible trashing episodes Frankly, Swappolube doesn't seem to help a lot if at all, just tweaking the swappiness value is not enough. Of course the root of the problem is the slow eMMC but maybe there is a way to avoid total lockdown and unresponsiveness.

Hmm, my eMMC has got a new interesting name after the latest 12.1 update:



Of course, I cannot be sure that it is the CSSU upgrade that did it. Anyone else seeing the same thing?

EDIT:
Solved it thanks to Switch_:

Go Settings > Bluetooth > change device name to whatever you like, should clear up the issue. Its the configuration of the Bluetooth chipset that causes the issue.

For some reason my device name set under Bluetooth settings had changed.