-
Notifications
You must be signed in to change notification settings - Fork 2
SoC:TurboX2
TurboX2 is one of the more advanced XMMS2 clients around. It has a lot of nice features and an interesting, interface with which to work. TurboX2 has suffered a bit of neglect, and could really use some love to get it up to release quality. The goal of this Summer of Code project more abstractly is to make a stable release that can be used without much issue on a number of web browsers and with an ease of installation that a moderately competent user could install and use it.
- For Checkpoint of 7/8 June - Integrate MochiKit PropDict and ressurect and use /mediainfo controller
- For Midterm Evaluation of 27 June - Implement move handler for playlist changes, look into and possibly start to implement a lazy loading widget for the playlist and various medialib areas, and start to implement views. N.B. Wiki needs to be updated for the evaluation!
-
- Views and LazyLoader implemented - Views is integrated; Will integrate Lazy Loader for playlist tonight (27 Jun 2006), also have a few victims for a test group, will work to find more. Opera 9 support is an added bonus.
Playlist is now updated atomically thanks to xmms2 async signals, and a javascript based playlist. This makes it possible to get a reasonably well performing playlist that doesn't require reloads. I have a lazy loading widget written, but still need to work on it a bit more and find the best way to integrate it into turbox2. One problem is that grabbing and generating an entire playlist even if it's just "loading id..." may be expensive, so it might be best to make the div scrollable with regards to the size of playlist_length and then fetch the ids and resolve them as the scroll happens. At the same time, all those loadJSONDoc() calls to get the playlist in parts may be too expensive as well, so some experimentation will be needed.
Status: Implemented atomic changes, works great, see Performance status for more details. Lazy loading widget implemented, but some research is needed to determine how to best integrate it. Example of the widget is available in the resources section. I commited the widget to the tree today (23 Jun 2006).
Searching of the media library is a goal for the summer. The idea would be to have output that looks something like Apple's Spotlight in the Media Library area:
--Artists--
Apanap Korvarasson
Foobar Players
--Albums--
Sausages and Korv
Songs for Code and Consumption (of the TB kind)
--Songs--
My God, I can't make things up well tonight
These are just random titles
When an entry is clicked it will, in the case of albums and artists, list a general view for that selection, or in the case of songs, add that song to the playlist.
Status: This is planned for after midterm evaluation.
TurboX2 is lacking a nice graphical set that fits the interface, and some of the nice eye-candy features have been disabled at various points for faster development. I have recently attempted to re-enable things and add some icons and the likes. FireFox also can not deal with file:// urls for art, so there needs to be a way to fetch the art and put it into /static in the case that it's a file:// url.
Status: I've added some icons for playback control and re-enabled the splitpane. Still need to work some on re-enabling usage of overlib, and fix the album art usage.
An issue I always fear about raising with TurboX2 is two fold: scalability and performance. Javascript operations can be expensive, and so can http request operations. In consideration of this there is always a blancing act between what should be done server side and what should be done client side. What I think it comes down to is that the client is best at interface and general looks, with that in mind I think automatically generated templating is not a great idea. The reason the client is better for this is an issue of flexiblity. The browser/client knows what the browser/client can do, information about the actual structure of the page is avaliable to the browser in a way it's not on the server side. So sizing and such can be done a lot better on the client side. The server is better at manipulating a lot of data, so it could be silly to have the client doing much manipulation. The server should push out complete data to the client. So that's why my tendency has been to move rendering and drawing operations into javascript. Still I'm afraid of the performance issues that have recently been reported to me, but I can't seem to reproduce them. I will continue to try different browsers to see if I can get a spike in CPU usage.
Status: Performance, for me at least, has gotten a lot better with the new playlist which does atomic changes, there is still a lot of room for improvement with regards to large lists (both playlist and medialib), but this is much better than it was in the past.
PropDict is more or less complete. I need to MochiKitify a lot of the code, because I'm going to pretend to myself that they do things more efficently then I do. (Though I looked and they iterate over Arrays to find indices just like I do). Otherwise PropDict is working nicely, with support for wildcard sources, has_key and get_value. Only major thing I might do is to throw an exception in the case of a get_value that doesn't return a result for consistency with how Python's PropDict works.
Update: So I decided to pull out those statistics I learned in High School supposidly and run a t-Test on the benchmark linked in resources. It seems that there is no statistically significant difference between the two data sets. Doesn't really matter which I use I guess.
Further Updates: PropDict is now integrated into the Status area and into the Medialib view. They both now also use the /mediainfo controller which means that they do resolving. As in, we put a temp text entry at an ID and then once we have mediainfo we swap out the temp text for real mediainfo data. The advantage of this is that it's half the work necessary to do lazy loading, it also means that you get an indication that things are working before they finish working, and part of the joy of AJAX is constant updates!
Status: Considered done turbox2_propdict.js is working great and being used through out TurboX2 along with the /mediainfo controller.
The framework itself is in place and a basic view that is identical to the old hardcoded view has been put into place and made the default Medialib view. I would like to implement one or two more views during SoC. Specifically one that shows all albums with their art if available, and another that pages the artist list (or maybe even pages a song list).
Status: Initial implementation is in place and working, more Views and testing to come.
Opera 9 support is in tree. It's not 100%, and probably won't ever be. Opera is missing some CSS3 declerations that firefox has like overflow-x, so the playlist will always like a little off in Opera, or at least until opera implements this. Opera also caches XMLHTTPRequests so I had to put a back in place to make the url of the status controller different each time to get around it. (Ever incrementing number as an argument). The LazyLoader I was able to get to work on Opera but only if I disable unresolve. I also had to put a `resolved` element class into place, but I was thinking that would be a good idea anyway. Basically the reason Opera can't unresolve is that Opera jumps to the position of an update in the DOM tree, which means that when an entry unresolves it jumps to it and then resolves it. but then the position in the DOM tree you were at before the jump becomes unresolved and you go into this crazy jumping loop. I've been wanting to make unresolving optional anyway, so this is no big deal.
Status: Opera 9 and Firefox 1.5 are supported, others to come if I have access and the time. Opera 9 support is mostly ok, but has a few bugs.
- Finish JavaScript implementation of PropDict and use it through out TurboX2
- Make TurboX2 at least work on Safari and hopefully on Opera and IE 6
- Playlist Optimisation - general optimistation for large lists of data
- Do not update the playlist unless its contents have changed
- Find or write a lazy loading widget for the playlist and any other large list
- Ressurect the /mediainfo controller used to do resolving of mediainfo by ID
- General cleanup and refactoring - object orientation for the javascript and python is a plus
- Also look into making the Python backend async by somehow tying it into CherryPy's mainloop if possible
- Get a working implementation of Views with at least a View that mimics the current artist-album view
- Get things working with python's distutils so that TurboX2 can be redistriubted
- FreeBSD port!
- Benchmark of PropDict implementations - The first five are PropDict using MochiKit's findValue() to find indicies of values in an array, the second is using my own method.
- TurboX2's Mantis page TurboX2's Mantis page to be used during the testing phase of the Summer of Code.
- Lazy Loading widget example - This is an example of my lazy loading widget in action.
Content is available under GNU Free Documentation License 1.2 unless otherwise noted.
- Community
- Development