So, “release early, release often”!

I have uploaded ‘simp-test’ package into Extras-Devel.
It will not create any menu items (yet), so after installation please open X-Terminal and run ‘lxtest’ command.

This is just a simple UI demo for now with player buttons, seekbar and scrollable list (no kinetic scrolling yet).

The main question is the list scrolling performance. I can't say that I utilize all possible optimizations. But approach that I have implemented is pretty flexible and allows semi-transparent UI elements to be drawn above each other. If we want scrolling to be faster or smoother, it seems that we will need to drop transparency effects (but I'm not sure that it will make it faster significantly).

The other interesting thing is in-window UI rotation with rightmost toolbar button. Please notice that scrolling performance decreases noticeably when UI is rotated. That's simply because I need to rotate offscreen buffer before blitting it to the window.
Actually, I don't see any way to increase performance of rotated UI. For basic drawing operations (rectangles, lines) rotation can be done quickly with just coordinates transformation. But not for texts. Any ideas are welcomed.

But as you can notice this demo starts up pretty fast

So, what do you think about this demo and its performance?

Current source can be cloned from BitBucket: https://bitbucket.org/IlyaSkriblovsky/simp
Source of this package: http://repository.maemo.org/extras-d...source/s/simp/
Package for desktop linux: http://repository.maemo.org/extras-d...t_0.1_i386.deb

Very nice!

Scrolling performance is perfect, don't remove the transparency. How much of the image are you rotating? Rotating the entire image is probably faster than changing line orientation and rotating each text separately, even though there would be fewer pixels being rotated. Maybe you could determine the area that shifts and blit its already rotated form. Then draw the newly exposed area and only rotate the new area onto the screen. Unless that is already what you do.

I know this just a test and the final will change a lot but the rotation icon should open a menu with As to quickly select an orientation.

Can't wait for it to be finished.

The scrolling seems a little jerky to me, but that would probably be a good thing once we're dealing with a populated playlist. I like the responsiveness of the seekbar.

On rotation, I would also prefer to have it configurable. One thing FBReader does well is allow fine control of rotation; you can choose to rotate to any one orientation or through all four in the settings. I'd like something similar here if possible, or at least for it to open at the last used orientation.

Are the forward and back buttons going to be for fast forward/reverse or next/previous selection? Or both?

auouymous, now it is implemented as follows:
* offscreen buffer always contains UI in 'normal' orientation
* when widget wants to be repainted it paints itself into buffer in 'normal' orientation
* then part of buffer which was updated goes to window with rotating to corresponding orientation

So, UI orientation doesn't affect widget drawing code at all, and this is good. But with this approach scrolling actually cause most of the buffer to be rotated at every frame. And I think this is most expensive part.

But if we don't want to rotate buffer every time, the buffer will need to contain widgets in rotated form and all widget drawing operations need to be rotated individually while painting into the buffer. I think this might be slower...

To be able to scroll in already rotated buffer we will need either draw all widgets with rotation of every operation or introduce new buffer in the chain which will store existing one in rotated form. And we will need a smart code that will do scrolling in both buffers individually... I think this is too complex and one more blitting can slow down drawing...

Nice and light (as if we'd expect anything less from you!) :-)

Scrolling speed isn't bad without rotation, or with RANDR rotation.

A minor annoyance: the seekbar is grabbing taps meant for the last item in the scoll list.

Continue drawing to the normal mode buffer, but when the list is scrolled blit the already rotated window contents (area A) to the new position, update the normal mode buffer with the changes, extract the exposed area (area B), rotate it and copy into the window.

When the list is scrolled up the exposed area is at the bottom so area A is the bottom of the list minus the top portion that gets moved off screen and area B is the new contents at bottom of list.

That should improve scrolling speed since you are only drawing and rotating the newly exposed area. The rest is blitted from its already rotated form.

Thanks for feedback!

I personally think that 0° and 90° CCW orientations are enough You are free to not agree with me.
Anyway rotate buttion shouldn't toggle all four orientations. Every user will have his two favorite orientations and the button should toggle between them. Which two to use might be customized in settings.

I think forward/backward buttons should switch tracks on short tap and do fast forward/reverse on long tap.

lma, yes, seekbar's hot area now has the same height as round glowing and overlaps bottom part of the list and upper part of the toolbar. I'm not sure how to solve this. May be make non-rectangular hot area — wide around current position indicator and narrow elsewhere.

auouymous, you are right, but this will make it impossible to do transparent drawing on the top of the scrolled area. That's exactly what I meant here:
If we will blit already rendered window contents, this will 'scroll' transparent elements too. But if we introduce the limitation that no transparent elements can be drawn over scrolling areas, then yes, it is possibly can be improved as you described.
In the current Kroll's design this will affect round corners around the playlist and seekbar's glowing.

Settings to select two orientations would work.

The next/prev buttons should work exactly how you described them.

The entire slider hotspot should be the height of the brightest glowing part of the knob (about 5-10 pixels less on each side than what it currently is), any smaller and it will be harder to hit with your finger. That 5-10 pixel haze beyond the brightest area is harder to see and shouldn't be included in the hotspot.

The blit area would begin at the top of the haze, so all content in the slider's transparent area would be redrawn with the new content in that same area. When scrolling down you would need to rotate the new area on top and also rotate a little slice on the bottom where the slider overlaps.