Re: New audioplayer for n8x0
 

this toolkit will play nice with the maemo WM, yes?

Re: New audioplayer for n8x0
 

I was really close to having the perfect desktop if not for the stupid 1 pixel border.
http://talk.maemo.org/showthread.php?t=52562

Maybe I should give that a revisit some day.

Re: New audioplayer for n8x0
 

Sure. ASUI tells the WM not to draw window decorations and to always be on top. The toolkit wouldn't do either of these and would get a nice box below the statusbar. When it receives the fullscreen key it just tells the WM to go fullscreen (not sure how) and then the WM either increases its window size and sends a configure event or the library increases its own window size (not sure which one). That should be all that needs to happen for it to work like a GTK app. Telescope will even display the ASUI window or the ASUI popup clock window if something glitches and you're able to open Telescope. So nothing special needs to happen to work with it either.

The titlebar and close button are drawn by the WM and all XLib apps send their name to the WM.


Can you tap those statusbar applets? Do they hide when using fullscreen in apps that don't support fullscreen? Not sure how well that would work with apps that have important stuff behind the statusbar...

Re: New audioplayer for n8x0
 

Yeah, it was actually pretty nifty. :)

All apps launched automatically in full screen mode.

Pressing the full screen key would simply toggle the status bar on top of whatever app was running. Pressing it again would make it disappear.

The status bar worked just fine too by the way.

The only thing I didn't care for was not being able to use transparent icons in the status bar anymore for some weird reason.

Re: New audioplayer for n8x0
 

auouymous, I leaved a couple of comments in your googledoc in part about mainloops.

Actually, your document is great. You have covered all different parts of the UI.

By the way, i don't know how to make a custom text field that will work with native on-screen keyboard.

Re: New audioplayer for n8x0
 

And I have replied to your replies...

I haven't looked into it yet but I believe the keyboard is a separate window or part of the WM as it doesn't appear in Telescope and the overall window sizes decreases when attached to it. It should be injecting key events into the window so all we have to do is figure out how to open the keyboard and resize our window if the WM/keyboard doesn't already do that. (made a note of this in the doc)

Re: New audioplayer for n8x0
 

The hildon-input-method process should be what draws the virtual keyboard and its source is at http://maemo.gitorious.org/fremantle...d/trees/master , maybe someone could dive in and figure out how to interact with it.

Another option could be to embed the xkbd source into a keyboard widget so it can be 'slid' into the window when needed by text widgets or embedded with its keys sent to a callback.
Advantages:

• would use the same theme as the app
• multiple layouts, swipe up to see a list of them for quick selection, swipe left or right to slide through them or swipe down to close (unless embedded). Layouts: stylus keyboard with keypad (like current hildon keyboard), alpha only (slightly larger keys), numeric only, larger alpha only (like the fullscreen keyboard), larger numeric only and various other special key layouts.
• the hildon keyboard can gray out alpha keys when opening for a numeric entry widget, a custom xkbd keyboard could only show the keypad layout.
• don't know if hildon keyboard supports user-defined layouts but xkbd looks to have layout files that could be used to define custom layouts that would appear when swiped and apps could select specific layouts or include their own.
• the app would be aware of the keyboard's height and could alter its layout if needed.
• we could kill that 10meg hildon-input-method process after we replace all gtk apps, or use a button in ASUI to toggle it on and off as needed for gtk apps :)

Cons:

• more work
• no handwriting input unless we code it as well

Re: New audioplayer for n8x0
 

Here is the page with the commits for Qt that enabled it to support the Hildon Input Method. And, while it doesn't seem to work, Austin Che also looked into it a little bit: https://garage.maemo.org/plugins/scm...ch&view=markup

Re: New audioplayer for n8x0
 

Xkbd needs a little touch up.

The repeating keys value should probably be over 100.

In the original build I think it was set at 5.

I asked Ukki to recompile it with a setting of 45 I believe.

I still on occasion get unnecessary key presses.

Also, there's really bad coding if you touch one of the keys, especially if they are quite large.

It's suppose to give a shift value if you touch a key and slide your stylus on the screen.

Honestly, that code needs to be gutted out.

Lastly, Xkbd always produces an error on 2 keys that aren't supported.

This should be removed or surpressed as well since many scripts will stop once it hits that error message.

Re: New audioplayer for n8x0
 

By the way, I could do a proper, almost full screen keyboard like this, something I have yet to try.

https://www.metamedia.us/metamedia/i...ple_screen.png

To get the keys to lay out like an actual keyboard though, I would need to run 5 separate Xkbd processes.

Re: New audioplayer for n8x0
 

One more thing, Xkbd allows for three different button appearances.

Square, rounded, and none.

I would just go with none so it would look something like this.

http://trac.hackable1.org/trac/raw-a...eenshot-24.png

Of course the layout would look like an actual, physical keyboard though, hence the need to run Xkbd 5 different times.

Once the layout is set then I would replace all the keys with .png images. That would be over 100+ specially drawn images by the way.

I probably would need help on that since I have no graphic design background knowledge.

Anyway, I'm just saying that it can be done. :)

Re: New audioplayer for n8x0
 

If we forked xkbd into the library it would use the library's theme system to draw the keys as buttons. The keyboard would of course be a widget and thus the theme could apply a unique style to the keys to make them look different from other buttons in the theme.

Does xkbd only allow you to define one row of keys per instance? If we fork it, our version would allow an entire layout to be defined in one file, positioning the keys inside automatic layout boxes. Each layout could also have one definition that handles both landscape and portrait or separate definitions for each orientation.

Re: New audioplayer for n8x0
 

Nope. This keyboard here has just one Xkbd running.

http://img291.imageshack.us/img291/8...1014320mr9.png

The problem is that they're all huddled butts to elbows next to each other using the same columns.

In a physical keyboard, the keys don't line up this way, so really, the only solution I can think of is to have a separate Xkbd running for each row.

Re: New audioplayer for n8x0
 

I guess I could do it with just one Xkbd running but you would need to add coding to allow for a dead key.

Touching it wouldn't be highlighted and it also wouldn't send out a text signal.

Hope that makes sense. :)

Re: New audioplayer for n8x0
 

Hildon Input Method frameworks is based on Gtk-IM framework if I recall correctly. And it is very tightly coupled with GTK and that's why maemo's native onscreen keyboard works only in GTK apps. And I'm not even sure that it sends key events to the textfield directly because of word suggestion support.

Anyway, it seems that full-blown UI toolkit will need a couple of years of work :) And I don't see any reasons to consider UI toolkit as a goal.
Lets consider some practical things, like ASUI or Simp, as a goal.
If audioplayer will require text input — we will need to investigate how to implement it. If no — great, lets give up on text fields.

By the way, I have working demo with Seekbar & Player buttons from Kroll's screenshot, with cool seekbar handler transparency :)

You can grab the source code and track the development at github: https://github.com/IlyaSkriblovsky/lx

Re: New audioplayer for n8x0
 

We don't need to add eveything to the toolkit, only what is needed at the moment. The full list of widgets was just a roadmap and if the toolkit is properly designed it can easily be extended with more widgets later on. And the entire toolkit as described in the doc is pretty easy to do, couple weeks of good development time. Even the keyboard would be easy, a simple markup language to define key names, key codes and key positions would generate widgets inside a container widget. The callbacks on the buttons just hook into the Xlib key handling code and invoke whatever callbacks are attached to them.

The hard part is coming up with a good themable and modular structure for the library that supports user-defined widgets. The widget structure just needs a bunch of callbacks to render itself, handle taps and keys, return its minimum and maximum sizes so the parent container can allocate and assign it a position and size.

Anyway, I can code up the keyboard widget and text fields after I get the file manager started since it will need them to rename files and later on for its text editor.

And good job on simp, should be fully functional by next week. :)

Re: New audioplayer for n8x0
 

Good news: I've measured gstreamer memory consumption on n810:
* console app, playing local mp3 file (via dsp): ~2.8mb
* gtk app, playibg local mp3, with working seekbar (GtkScale): ~6.5mb

Since ps command on n810 is very limited, I've measured by VmRSS in /proc/<pid>/status


Btw, I was trying to replace maemo onscreen keyboard with my own back in 2009. I was owned N800 then, so onscreen keyboard was the most important part of the UI for me. But I was stuck trying to embed by keyboard in Hildon Input Method framework. So, the only workin code I had is keys layouting with hboxes and vboxes just like you described :)

Re: New audioplayer for n8x0
 

NICE!!! This could be a 5meg xlib app, smaller than xmms. Gtk is likely to bloat down more when you populate a playlist widget, but even if it was 10meg it would be better than media player and canola. However you want to make it is fine with me. Maybe it could be done in Gtk to get it released sooner and if I ever get time to do the file manager we could look into porting simp over to its toolkit.


Its always harder to integrate with something else than it is if you control everything in the stack.

Re: New audioplayer for n8x0
 

If you need testers for any of this, I'd like to help. I have both a N800 and a N810 in case anything ends up being specific to a particular device.

Re: New audioplayer for n8x0
 

the opera guys integrated the maemo OSK via a gtk input area overlay of some kind.

Re: New audioplayer for n8x0
 

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

Re: New audioplayer for n8x0
 

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

Re: New audioplayer for n8x0
 

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?

Re: New audioplayer for n8x0
 

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

Re: New audioplayer for n8x0
 

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.

Re: New audioplayer for n8x0
 

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.

Re: New audioplayer for n8x0
 

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.

Re: New audioplayer for n8x0
 

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.

Re: New audioplayer for n8x0
 

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.

Re: New audioplayer for n8x0
 

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.

Re: New audioplayer for n8x0
 

Mmm... That sounds too specific :( Currently the UI toolkit is very universal, but such trick will require specific hacking for the specific design :(

Re: New audioplayer for n8x0
 

The widgets are all happily drawing to their normal mode buffer and the rotation to different orientation is another layer on top of the toolkit right? The toolkit says it was updated so the upper layer rotates it to the screen. What if the list widget could have a callback that is invoked when the list scrolls. This callback could inform the upper layer about the new and old area boundaries so it can blit the old and rotate the new. Its not like a transparent slider widget over a list widget is all that universal to begin with. :)

Re: New audioplayer for n8x0
 

Yes, but this upper layer that will perform blitting already rotated image will need somehow know which parts of scrolled area are need to be copied from offscreen buffer because overlapping widgets.
Although... It seems that this parts can be easily calculated by intersecting window's child widgets with the scrolled area. Something like:
(scrollarea_before_scroll ∩ child_position) ∪ (scrollarea_after_scroll ∩ child_position)

Re: New audioplayer for n8x0
 

Hey all!
I'm very impressed of Mitrandir's work and all your investment in this project!
I was too busy past days but I am back. I had a little time today and I've started to write some kind of presentation. You are very welcome to edit is (cuz my english r bed enough to screw up this work) and to post there new ideas in a list in the end of the document.

Re: New audioplayer for n8x0
 

About memory consumption.
Now the UI demo eats ~2.4mb RAM. This is nearly ok.
BUT that doesn't include memory allocated by X process for pixmaps, window backing stores and other resources!
According to my measurements, X gets fatter by ~4.2mb. So the total is 6.5mb, that is not so ok...

UPD: I have measured memory size of minimal GTK program: 3.9 mb RSS + 0.6 mb X = 4.5 mb total. Yeah, it seems that i use too much pixmaps...
(but keep in mind that lxtest UI totally combined from pixmaps while gtk app needs no any)

auouymous, I have implemented your advise about scrolling. This really makes rotated scroll to be as fast as unrotated, thanks :) But there is an issue: If I blit already rotated window's content while scrolling, this breaks double-buffering... Copied window's content overrides overlapping transparent glow and then glow is redrawn on the top. So the glowing around seekbar's thumb starts flickering and this looks very ugly.
Of course, this can be easily solved by adding one more buffer in the current chain that will store rotated content. But one more 800x480x32bpp buffer will add ~1.5 mb to the X memory...

Re: New audioplayer for n8x0
 

If Simp could have AD2P support for bluetooth headphones (with hardware buttons support too) it would be fantastic.

BTW, THANKS for the effort.

Re: New audioplayer for n8x0
 

Why 32bit buffer if the screen is only 16bit?

I thought all of the widgets were drawing to the buffer and then you rotated that buffer onto the screen? So why is the slider being drawn twice? Wouldn't it get drawn into the buffer and rotated with the list?

Re: New audioplayer for n8x0
 

You are right, 16bpp
(But I use many 32bpp-pixmaps while drawing because 16bpp ones doesn't support alpha channel)

When i scroll window's rotated content by direct blit window->window, this overrides slider's thumb. Then i redraw overlapping widgets into the buffer and then do blit buffer->window. After the first blit intersecting part of slider disappears, after the second it appears again and this results in flickering.
It is possible to eliminate flickering if i would scroll only part of window's content that will not override other widgets.
This can be done easily in our case, but in common case this will require complex logic to compute this area with substraction of rectangles and this problem isn't solvable in all cases.

UPD: I found that tablet's X server supports DBE extension that can automatically provide double buffer for window. I wrote primitive program to measure X memory size for window with and without DBE double buffer and it seems that DBE uses same amount of X memory as hand-coded double buffer. The only advantage is that DBE buffer automatically resize to match window's dimensions.

Re: New audioplayer for n8x0
 

Hardware buttons are done via AVRCP, not A2DP. As for A2DP itself, unsure how easy it is to pull off using gstreamer. I think the effort to date regarding A2DP on Maemo4 have focused on mplayer.

Re: New audioplayer for n8x0
 

In this thread (in russian) hacker with nick svs57 successfully played mp3 to A2DP via gstreamer with self-compiled MAD decoder.
So, A2DP support is certainly possible :)