please dont forget the Equalizer

for the boom boom

Can any one explain why transition in not smooth as when it rotate the is dark screen while rotating

it dose not look natural

can any one suggest if there is any setting or change to be done to the transition.ini file

thanks in advance

if i'm not mistaken, the elements need a while to rearrange. thats what causes the black screen between the rotation.

suggestion for rotation:

seems like there are 2 actions for rotation i.e. duration in and duration out. Hence, the blank out happens when it's switching from duration in to out... why not just make it into 1 action? must there be 2 actions for rotation?

Serious question here.... to all the current developers on the CSSU project, do you expect to finish in a complete way a complete OS in replacement for the mess Nokia have left us in OR is it going to be guesswork with the closed components Nokia have not released?.

IF we are going to enjoy a fully working OS with all components included is there a time you can say when this will be accomplished or do you still need Nokia to release the closed components to enable completion?.

Make one of the rotations take 0 time, and the other twice as long as you had it set to (or less, play with it), and set the rotation to the full 90-degrees. (Works for Z-Axis, not so much for X/Y-Axis rotation.) This won't get rid of the blanking, but it will put it right at the end or right at the beginning of the rotation, so the rotation itself doesn't look broken.

The reason it blanks is because the hildon-desktop, itself derived from GNOME as far as I recall, which is itself based to run on top of X, was never meant for portrait/landscape rotation at all. Now, when you have a program rotate, it has to create the portrait/landscape (whichever you're rotating it to) version of how it looks. Since the one you're rotating from is one set of graphics data, for one resolution, and the other is another set of data for a different resolution, that means there needs to be a moment when Hildon-Desktop internally buffers the way the rotated-to version of the app is going to look. This is what the break is there for.

Now, on typical smartphone OSs, this is accounted for from the ground up when making the OS, so making that transition smooth and the break invisible to the user is accounted for ahead of time (or there is no break, because the way the OS does the display stuff is somehow built to easily change resolutions without having to change the entire thing).

My layman's suggestion is: Instead of having hildon-desktop rotate to the halfway point then re-render to the beginning of the rotation from the halfway point in the other orientation, the moment the OS detects the need to rotate, it should try to load the other orienation into memory, and simultaneously animate the rotation using the current orientation. I'm sure that, unless you ram the rotation interval too low, the N900 should be able to handle both at once without noticeable slow-downs unless you're doing a lot of ram-heavy stuff in the background, but in that case, the rotation animation we have now would slow down as well.

Anyway, so you launch animation with the rotating-out orientation and start buffering the rotating-in orientation simultaneously. Let the rotation go all the way to the end using the rotating-out orientation graphics, and then finish the rotation as much as possible, and then fade/cut (very fast fade, a few frames at most, if needed to make it more perceptibly smooth... perhaps include the amount of frames to fade into the transitions.ini, with 0 being cut, 1+ being fade effect with the number being over how many frames to fade) to the pre-buffered rotating-in orienation, which should be ready to display in the final completely rotated position. The "second" rotation animation of the two can thus be completely gutted, at least for Z-Axis.

The problem is I would think this was thought of already, and if it hasn't been implemented, it's probably either because it's not as easy as it sounds to make hildon-desktop do this, or the CSSU devs don't feel like they can implement it, whether due to lack of relevant coding experience or time or whatever.

Im planning to install this cssu, it sounds very promising, but i have a question. Does it have problems with another programs, i think i red somewhere that it has problems with themecustomizer and some other program. The main question is, can something fail or does it have problems with some programs ? I wouldnt like to reflash my phone again :P thx

The latest Theme Customizer versions have been fixed to no longer conflict with it. Even when it did conflict, you had to be using a couple of specific features for it to break.

Anyway, you might have to uninstall Theme Customizer, install CSSU, and then reinstall Theme Customizer, to make sure the conflicting stuff isn't still installed when CSSU is installed. Prob'ly best to get an answer from d-iivil though.

No need to uninstall TC before installing CSSU. Just make sure you have latest devel-version of TC installed / upgraded before installing CSSU and you're good to go

Note that you'll lose ability to resize icons + bookmaks, ability to hide shortcut bgs when you install CSSU.