maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   OS2008 / Maemo 4 / Chinook - Diablo (https://talk.maemo.org/forumdisplay.php?f=29)
-   -   New audioplayer for n8x0 (https://talk.maemo.org/showthread.php?t=76917)

tso 2011-09-29 13:17

Re: New audioplayer for n8x0
 
What thread?

auouymous 2011-09-29 20:25

Re: New audioplayer for n8x0
 
Quote:

Originally Posted by Mitrandir (Post 1098813)
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.

The only advantage is that DBE buffer automatically resize to match window's dimensions.

Wouldn't DBE think the window was 800x480 when you have it in fake portrait mode?

What if the slider widget is placed in a floating layer that is separate from the layer containing the other elements. Only the lower layer would get drawn into the buffer. When the slider changes it could extract the buffered layer, render itself and then rotate to the window. When a buffered widget changes it triggers a change event for its region of the buffer that gets passed up through the layers and any layer that intersects the changed regions could be redrawn.

There would be no app logic at all since the toolkit would handle everything. This would also work for screen events since they could be passed down through the layers and stopping at the layer that has a widget in the tap location.

Mitrandir 2011-09-30 04:41

Re: New audioplayer for n8x0
 
tso,
haha, i forgot to paste a link, sorry :)
http://n8xx.com/topic2874-gstreamer.html

auouymous,
Yes, DBE will have 800x480 buffer. I just tried to test it in order to measure its memory consumption. But it seems that it will not give any advantage.

The trick that made rotated scrolling work fast is blitting window→window because in this case we don't need to rotate whole list contents each time.
Even if slider widget will lie at some floating layer there will be flickering because this blitting will override it and only after it slider will draw itself back. To make your suggestion work we need one more buffer that will store rotated content. While scrolling we will blit its content on itself, then draw the slider on this buffer and then blit it to window (with no rotation, this buffer already rotated). But this means one more fullscreen buffer that will increase X memory use...

Johnnie Price 2011-09-30 21:14

Re: New audioplayer for n8x0
 
I'm only somewhat of a power user, so I understand about 90% of what you guys are discussing.

But wouldn't it be easier and less resource intensive to let the user worry about rotation rather than having it built in to the app?

I mean most of the default apps work fine when rotated with xrandr, so why shouldn't this one?

tso 2011-09-30 21:47

Re: New audioplayer for n8x0
 
I guess the thinking is that not everyone has the rotation patch installed in some form or other.

auouymous 2011-09-30 21:52

Re: New audioplayer for n8x0
 
Quote:

Originally Posted by Johnnie Price (Post 1099911)
But wouldn't it be easier and less resource intensive to let the user worry about rotation rather than having it built in to the app? I mean most of the default apps work fine when rotated with xrandr, so why shouldn't this one?

The app is designed to let you artificially rotate it independently of the device's rotation. You can rotate between landscape and portrait in the app much faster than you could rotate the device. This is because device rotation causes every app to rotate, the more apps you have running, the longer it takes to rotate.

You can read your webpages in landscape while listening to music and if you don't like the song you can switch to the audio app which is now in portrait mode (without you rotating the screen) and select a new song.

Johnnie Price 2011-09-30 22:09

Re: New audioplayer for n8x0
 
Quote:

Originally Posted by tso (Post 1099934)
I guess the thinking is that not everyone has the rotation patch installed in some form or other.

I'm not trying to sound like a jerk, but I feel that if you own one of these and hnaven't enabled rotation you either a) just bought one off e-bay (I've only owned my n800 for just over a year and my n810 for less) or b) don't want rotation for whatever reason.

I already use the built in Media Player on a daily basis and it works fine for me in portrait mode. Unless SiMP brings something new to the table, I have no reason to switch other than to test it.

I'd rather see built in podcast support or the ability to create playlists on the fly (or both!) than built in rotation.

Of course I know nothing about code or the difficulties involved with any proposed features, so this is all just my opinion.

BTW, both my devices have CSSU, Diablo Turbo, ASUI and Diablo 5. My n810 also has the matchbox-swipe hack installed. But that's just how I'm comfortable with the devices.

Johnnie Price 2011-09-30 22:13

Re: New audioplayer for n8x0
 
auouymous - Thanks! The only app I use with independant rotation is FBReader, and it uses way more memory than any other app except Opera. I'm just worried about resource usage more than anything else.

Mitrandir 2011-10-01 08:22

Re: New audioplayer for n8x0
 
Okay, i think we should not spend too much time on the “fake” rotation.
There are many other intereresting things to implement :)

Can you guys formulate how playlist handling should look and behave? I personally don't have any idea of this because I use mediaplayers very rarely.

By the way, it turns out that gstreamer is thread-based and doesn't require GMailLoop to be running in the main thread. This makes it easier to integrate gstreamer to our mainloop.

auouymous 2011-10-01 09:47

Re: New audioplayer for n8x0
 
Quote:

Originally Posted by Mitrandir (Post 1100141)
Can you guys formulate how playlist handling should look and behave?

Each playlist is a file that contains references to directories or individual files. If a directory is added it should read in the list of songs but keep the directory reference in the file so you can refresh all later on and it will remove songs and read in new songs that have been added to the directories. The biggest problem would be creating new playlists because there is no OSK to type a name.

So in playlist mode you replace the next/prev/play buttons with management buttons, one of them being to add a new playlist. The scrolling view could show each playlist and maybe the number of songs in it. Maybe for now you could number the playlists and show a few directory names or songs to get around the OSK. Tapping the playlist would activate it and swiping horizontally could edit it, or put an edit button on each one.

Once in edit mode you change the create button to a delete button to remove the playlist. Show a directory tree in the list area with large checkboxes next to each. Check files to include them or check directories to pull in all files.

If you're listening to a song maybe a long press on the song could open a control to either remove it from the current playlist or add it to another. Assuming anyone wants this feature.

And just put a an option settings to refresh all of the playlists. Maybe even have a special master playlist either in the playlist window or in settings where you select all valid directories that may contain music or audio. This wouldn't be a playlist you can listen to but instead would serve as a template of what directories would appear when editing playlists. You would never see /tmp, /etc, /var, /bin, /usr and so on and it could come preset with /home/user/MyDocs/.sounds/, /media/mmc1 and /media/mmc2. The user could then refine the later two. And if you wanted to add game songs to a playlist you could open the master list and add /usr/share/whatever to it, then create a playlist and that directory would appear.


All times are GMT. The time now is 16:11.

vBulletin® Version 3.8.8