Mercurial > audlegacy
view TODO @ 4574:744953f257fb
uncomment last dbus functions that need UI access
author | mf0102 <0102@gmx.at> |
---|---|
date | Wed, 21 May 2008 13:58:45 +0200 |
parents | 04da24c63467 |
children | fba10959a743 |
line wrap: on
line source
Long-term "TODO" ================ - URIs with "?" are stripped (the subtune support uses that), which is bad, because some (a lot) of real-world URLs use 'GET' arguments. this breaks probing, but current input probing is confusing (and possibly broken anyway) and should be refactored. - mime-types support: * there is already code for mime support, but I think it may not be sufficient as it is designed for input plugins only -- also playlist containers etc. need this (IMHO) * might be nicer to have the type registrations in plugin struct instead of a separate function, a'la vfs_extensions. - document the different APIs via Doxygen - unified debugging/message system, for core and plugins * something like glib logging system, with logging levels * hardcoded "debugging" levels and/or macro-wrappers that would disable superfluous debugging output compile-time. --- being planned by ccr - audacious VFS is not 64-bit offset safe, breakage will most likely occur, if files larger than 2^31 are used (rather unlikely, tho, but still...) * nenolod says: current vfs sucks, it needs a "rewrite": - buffering support - non-blocking I/O support - {core,plugins}/configure.ac need some cleanup loving. * make session management (SM) optional. * build system cleanups .. extra.mk.in? wtf? --- this is in progress, worked on by ccr - plugin rewrites: * madplug * modplug (in progress by ccr) * scrobbler - playlist.c: playlist_clear() is VERY slow, possible reasons? * GList sucks? (it does, but is it the reason here?) * playlist_entry_free()? * mowgli_heap_free()? possible solutions? * mempools for playlist data? not sure if possible, the tuple heaps should then somehow be collected into pools... * storing the playlist as a GtkTreeModel seems to be fairly fast (at least in mudkip-player it is) --nenolod - playlist.c: racecondition in scanner thread vs. playlist manipulation (playlist_clear(), free, etc.) * go through scanner thread code and revise it. * also all playlist manipulation should be double-checked. * .. actually, the whole playlist.c should be refactored completely.