Active Topics

 


Reply
Thread Tools
tso's Avatar
Posts: 4,783 | Thanked: 1,253 times | Joined on Aug 2007 @ norway
#121
What thread?
__________________
Be warned, posts are often line of thoughts at highway speeds...
 

The Following User Says Thank You to tso For This Useful Post:
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#122
Originally Posted by Mitrandir View Post
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.
 

The Following 2 Users Say Thank You to auouymous For This Useful Post:
Posts: 355 | Thanked: 598 times | Joined on Sep 2009 @ Nizhny Novgorod, Russia
#123
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...
 
Posts: 86 | Thanked: 29 times | Joined on Sep 2011
#124
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's Avatar
Posts: 4,783 | Thanked: 1,253 times | Joined on Aug 2007 @ norway
#125
I guess the thinking is that not everyone has the rotation patch installed in some form or other.
__________________
Be warned, posts are often line of thoughts at highway speeds...
 
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#126
Originally Posted by Johnnie Price View Post
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.
 

The Following 2 Users Say Thank You to auouymous For This Useful Post:
Posts: 86 | Thanked: 29 times | Joined on Sep 2011
#127
Originally Posted by tso View Post
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.
 
Posts: 86 | Thanked: 29 times | Joined on Sep 2011
#128
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.
 
Posts: 355 | Thanked: 598 times | Joined on Sep 2009 @ Nizhny Novgorod, Russia
#129
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.
 

The Following User Says Thank You to Mitrandir For This Useful Post:
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#130
Originally Posted by Mitrandir View Post
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.
 
Reply


 
Forum Jump


All times are GMT. The time now is 22:53.