| Line | Revision | Contents |
| 1 | 184 | **** |
| 2 | Current versions of packages which don't work on Win32 & why: | |
| 3 | ||
| 4 | gconf 2.24.0: requires dbus for something which I don't fully understand. | |
| 5 | 425 | -> switch to gsettings anyway soon. |
| 6 | 184 | |
| 7 | 322 | libsoup 2.26: invalid flag for gcc3 |
| 8 | 355 | ** |
| 9 | 260 | |
| 10 | 362 | * gconf gsoc project - use it |
| 11 | 269 | * last.fm client should wait maybe a second from params changing before it tries connecting, |
| 12 | trying on every letter when a new username is entered is silly. | |
| 13 | -> binding with a delay, gsoc project | |
| 14 | ||
| 15 | 191 | Creepy little bugs! |
| 16 | - a song plays back silently every so often for no apparent reason. | |
| 17 | 390 | -> this maybe affects songbird too - it seems to |
| 18 | 371 | -> win32 only? |
| 19 | 361 | - once it fucked up with 'invalid message on scrobbler message bus: #0' or some shit in an infinite |
| 20 | loop. | |
| 21 | 206 | - Here was a weird problem. 'test-data/test.db' started being really slow. It's hard to understand why |
| 22 | (some locking problem?). I wonder if this will happen again. | |
| 23 | 261 | |
| 24 | *** calliope just likes to lock up sometimes at the moment. :( | |
| 25 | ||
| 26 | 243 | * playback is shit with high CPU |
| 27 | 365 | -> songbird uses gst on win32 but seems to do much better than calliope. have a look at their code |
| 28 | and find out what the deal is there. | |
| 29 | 184 | |
| 30 | 271 | -> Preset 1 Dynamic test fails locating sometimes :( libraryview only? |
| 31 | ||
| 32 | 439 | --> improve wscript for latest waf (global bld, check function, build on dist etc.) |
| 33 | 299 | |
| 34 | 417 | -> make a libtestutils, and make the test build logic better .. |
| 35 | ||
| 36 | 283 | *** APRIL + |
| 37 | ||
| 38 | 353 | -> processes are slooow on win32 now .. probably because the threads must wait for gdk lock to |
| 39 | finalize? | |
| 40 | ||
| 41 | 390 | -> add unit test for "(artist[name]:album:release:track:recording)/recording[name]" |
| 42 | ||
| 43 | 397 | -> matching extensions is fucked |
| 44 | ||
| 45 | -> changing files: group change notifications together for speed (ie. hold them back so we don't | |
| 46 | emit row-changed on the same row 6 times in a row). | |
| 47 | 432 | |
| 48 | 445 | -> Sometimes the sort order is wrong, i think .. hard to reproduce |
| 49 | ||
| 50 | * Some bizarre threading issue, where the view is being freed and the import is still going .. | |
| 51 | - Seems like the weak reference that notify closures hold is not doing what it should. | |
| 52 | ||
| 53 | 441 | Tests that occasionally fail: |
| 54 | main-test/final/preset 1 failed on me once for no reason | |
| 55 | files/Empty (this may be gtk_init not being called correctly by gtk_test_init) | |
| 56 | process/cancelling/GUI (same??) | |
| 57 | 418 | |
| 58 | 445 | * Code terminology. You have about 3 different concepts called Node. Write a lexicon. |
| 59 | ||
| 60 | * Don't steal focus when you start! Esp. in the tests !!! | |
| 61 | ||
| 62 | 452 | => Problem #9020: I am confused about the removal queue and count_references. See library.c:2054. |
| 63 | ||
| 64 | 451 | * Replace 'process' system with GTask which is hopefully less crappy |
| 65 | -> GTask is conceptually totally different from Process. | |
| 66 | - A GTask is one work item, so to process 10k songs, we would need 10k GObjects * 3 or 4 task | |
| 67 | classes. | |
| 68 | - Whereas, Process's work items are much more lightweight. They are not ref counted or any | |
| 69 | such nonsense and I think are much closer to what we need. | |
| 70 | - GTask's examples are things like parsing a log file and RSS reading. With Process, these | |
| 71 | would cause extra overhead because of the queueue which would only be for one item. | |
| 72 | - Using GTask in calliope means | |
| 73 | -> How about implementing Process *on top* of GTask - like a GTaskQueue or GProcess. ... | |
| 74 | -> mailed chergert | |
| 75 | ||
| 76 | 418 | ---------------------------------------------------------- |
| 77 | 415 | |
| 78 | 453 | * Make genericview work for Library |
| 79 | => Problem #9021: it doesn't. | |
| 80 | ||
| 81 | ||
| 82 | 451 | * Make library work without caching. |
| 83 | => Problem #9017: query a track from library. Unref it. The recording and file entries hold | |
| 84 | circular refs and won't be freed, so now you have entries left over. How can you deal with | |
| 85 | this? | |
| 86 | -> Entries could track who references them. This is probably a nonstarter. | |
| 87 | -> You should call entry_destroy when you know the entry is no longer needed. This must only | |
| 88 | work when ref_count==1, thus it is pointless because with ref loops the ref count will be 2. | |
| 89 | -> You should call music_source_entry_destroy when you are done with the entry. | |
| 90 | ||
| 91 | I actually think entries could track who references them. It didn't work last time, but perhaps | |
| 92 | now I zero the foreign keys in the sources when removing entries it will ... ? | |
| 93 | ||
| 94 | * final tests fail randomly. | |
| 95 | ||
| 96 | * reimplement libraryview | |
| 97 | 415 | |
| 98 | 441 | * This will probably be important in libraryview, I ripped the code out for now ... |
| 99 | Reimplement the 'general' flag in a better way: | |
| 100 | ||
| 101 | /* FIXME: problem! | |
| 102 | * So that's the problem the 'general' flag fixes - if the node's tail type is general, the view | |
| 103 | * queries the node's children straight away and if there are none, it doesn't show the node after | |
| 104 | * all. At the moment this only applies to artist. FIXME: I think any type where more than one | |
| 105 | * foreign key points to it should be treated this way, but I'm not sure yet so I decided to use | |
| 106 | * an explicit flag instead. | |
| 107 | * | |
| 108 | * FIXME: we could be cleverer how we deal with this in the sources. For example, if the config | |
| 109 | * has artist > (album .)/(recording .) (ie. if every possible foreign key is represented) we | |
| 110 | * can once again assume no entry nodes - except for VA and Unknown Artist, who are special | |
| 111 | * cases really anyway. | |
| 112 | */ | |
| 113 | //extern const gboolean entry_general[ENTRY_TYPE_COUNT]; | |
| 114 | ||
| 115 | 307 | |
| 116 | * test insertion, changing & removal in the preset sources tests | |
| 117 | 208 | - removing entries with chaining |
| 118 | 260 | |
| 119 | 390 | |
| 120 | 425 | SEPTEMBER |
| 121 | 266 | -------- |
| 122 | ||
| 123 | ||
| 124 | Memory issues: | |
| 125 | - a memory monitor dialog !! | |
| 126 | 269 | -> http://www.reddit.com/r/programming/comments/86d72/ask_progreddit_getting_the_amount_of_memory_used/ |
| 127 | -> can glib do this? gslice? | |
| 128 | 266 | - concrete limits on memory use - test with a really low limit. This basically affects |
| 129 | how many pages to keep in memory before we go nuts and free a bunch of them. | |
| 130 | on this subject: | |
| 131 | - what pages are best to remove? you could track how long ago a page was accessed - but | |
| 132 | this is kind of nuts. Randomly? Every even no.? | |
| 133 | - track total allowable memory use. Estimate how full node is. Free some pages of | |
| 134 | root node, until size is okay again! | |
| 135 | - when could this be triggered? On every 10th page alloc or something? Is there an | |
| 136 | easy way to check our own memory use? | |
| 137 | - or, we could just count how many total nodes are in memory, * it by size of a node. | |
| 138 | total memory use of the view will never be more than double this value. every time | |
| 139 | it goes over memory allowed/(node size*2), free a bunch of nodes.. | |
| 140 | - you also need to manage sqlite's cache size. | |
| 141 | see http://bugzilla.songbirdnest.com/show_bug.cgi?id=14442 | |
| 142 | 361 | - on linux, look up 'mallinfo' and 'malloc_info' |
| 143 | 364 | Mem requirements during import to library still seem to be pretty much unbounded |
| 144 | -> you don't empty any caches | |
| 145 | - add in simplistic memory management, including cleaning library cache and libraryview pages | |
| 146 | 266 | |
| 147 | 282 | Here is an idea: batching file imports. This fixes a few issues: |
| 148 | - maintaining the recording cache in libraryview etc adds a lot of expense to imports. | |
| 149 | If files were added in batches of 50, say, all those inserts could be done in one go and so | |
| 150 | it would be almost 50x faster .. if a method is called, we can just do the batch update | |
| 151 | straight away. | |
| 152 | - how about doing it in increments of MUSIC_SOURCE_VIEW_PAGE_SIZE ... | |
| 153 | - long imports wouldn't be lost in a crash, just the last 50 or so songs. | |
| 154 | ||
| 155 | 278 | * Library & LibraryView: sqlite_prepare all queries. |
| 156 | ||
| 157 | 248 | * recreate library!! |
| 158 | 266 | ---- |
| 159 | 260 | |
| 160 | ||
| 161 | 336 | |
| 162 | ||
| 163 | TUESDAY 10th | |
| 164 | ----------- | |
| 165 | ||
| 166 | * use artist[sortname] not artist[name] everywhere! | |
| 167 | ||
| 168 | ||
| 169 | - in albumtree, two albums from same year have their tracks mixed together. | |
| 170 | it sees: sort by date, then sort by track number. | |
| 171 | ||
| 172 | ||
| 173 | make Calliope, basically, work. | |
| 174 | - ie, play through library on shuffle & sorted on all configs | |
| 175 | Put this into the unit tests!! | |
| 176 | ||
| 177 | ||
| 178 | TUESDAY 17th | |
| 179 | ----------- | |
| 180 | ||
| 181 | ||
| 182 | - store default sort property for each entry type, so they can be more implicit .. | |
| 183 | ||
| 184 | ||
| 185 | g_slice , including hashtables ! How can we do that !!! | |
| 186 | - where? | |
| 187 | ||
| 188 | ||
| 189 | ---------------- | |
| 190 | ||
| 191 | ||
| 192 | * execute in view config dialog crashes calliope, sometimes | |
| 193 | ||
| 194 | ||
| 195 | Little fuckers | |
| 196 | -------------- | |
| 197 | seeking has gone back up its own ass. | |
| 198 | - sometimes songs seem to play back silently for no reason. | |
| 199 | -doesn't install a desktop icon on ubuntu | |
| 200 | * skipping problem - seems to skip two when one is broken. | |
| 201 | - when you're playing lots of tracks that it doesn't know the time for, it shouldn't use the | |
| 202 | previous track's length each time! In fact maybe should not show a length at all. | |
| 203 | ||
| 204 | * unplug h4 while calliope is playing through it - a. why has it decided to play though asio now, | |
| 205 | and b. why does it fuck up when h4 is disconnected. | |
| 206 | * also, audio outputs so I can play along with the main guitar! | |
| 207 | ||
| 208 | test bjork (weird character encodings) code on linux & unit tests for that sort of thing! | |
| 209 | ||
| 210 | start calliope-unstable, with tag reading on. start a local calliope. turn tag reading off, & back on. | |
| 211 | Both crash! | |
| 212 | ||
| 213 | change song on shuffle, then change to a different one, and the next played song is the one you | |
| 214 | selected before ... | |
| 215 | ||
| 216 | ||
| 217 | * fix last.fm thread lockups on quit. These are caused by libsoup waiting on a port and the thread | |
| 218 | not quiting until the function has returned. However, we can't use libsoup asynchrously without | |
| 219 | having a glib main loop in scrobblerthread. Which actually is a possibility !!! Or, pthread | |
| 220 | may have a way to cancel threads? Or we have to find a new lib to do non-blocking network io, | |
| 221 | or find a way to make libsoup abort when we want it to .. | |
| 222 | ||
| 223 | ||
| 224 | -> unit AND SPPEED tests for new get_id_at_path, and get_value .. | |
| 225 | ||
| 226 | - make skipping faster! it's still pretty sluggish. | |
| 227 | ||
| 228 | get_id_at_iter speed! resizing the columns is really slow for example! | |
| 229 | ||
| 230 | * info should update when id is found, not when path is found. | |
| 231 | ||
| 232 | -cancelling a long load with filesource takes a long time (basically a hang) | |
| 233 | -> i think this may be fixed now | |
| 234 | ||
| 235 | - try using finer-grained locking (an individual mutex for each source .. involving transactions too?) | |
| 236 | rather than using gdklock for source. | |
| 237 | ||
| 238 | * How to change what sources we are playing from. At the moment player has a crazy combo box | |
| 239 | which does nothing. | |
| 240 | fix statusus | |
| 241 | ||
| 242 | ||
| 243 | * Needs a better icon | |
| 244 | ||
| 245 | ||
| 246 | * Default extensions list - things we need. | |
| 247 | Allow choosing of what files to search for! | |
| 248 | -> if music is added that is in A but gst can't play, come up with an explanatory dialog ... | |
| 249 | or, when it's played. | |
| 250 | -> unit tests for these too ! | |
| 251 | ||
| 252 | * make sure transient parents are given for dialogs everywhere, or they could appear in weird places | |
| 253 | ||
| 254 | - columns should be reorderable .. | |
| 255 | ||
| 256 | ||
| 257 | ||
| 258 | MYSTERY TIME | |
| 259 | ||
| 260 | 209 | |
| 261 | 224 | -- test the parser more thoroughly for errors etc. |
| 262 | - test music_source_view_get_first | |
| 263 | - catch many_to_one flag being written in config in wrong place. | |
| 264 | test intermediate ids more thoroughly .. | |
| 265 | flat/branching should be a flag. | |
| 266 | ||
| 267 | - it would simplify things if an empty config meant view->Config still existed, but with NULL head. | |
| 268 | ||
| 269 | 260 | has-child erroneously says orphans have children, you should emit has_child_toggled when adding leaf |
| 270 | 224 | nodes with depth < n_levels. |
| 271 | 260 | /* iter_has_child needs to be able to execute without taking the iter out of freefall. If the iter |
| 272 | 224 | * is in freefall (ie. it points to an as yet unqueried region of the node) has_child has to guess, |
| 273 | * which it does by returning TRUE unless depth==n_levels. For this reason, when reading bits of | |
| 274 | * partially queried pages, leaf nodes of depth < n_levels need to have has_child_toggled emitted so | |
| 275 | * they display correctly. | |
| 276 | */ | |
| 277 | ||
| 278 | 209 | |
| 279 | 204 | - do a bigass new unit test for process, with lots of chained processes. |
| 280 | Catch more of the race conditions. Process should run its tests LOTS of | |
| 281 | times too. | |
| 282 | 260 | |
| 283 | 224 | -removing a track should add its file as an orphan to the view, that doesn't happen. |
| 284 | 260 | |
| 285 | 184 | |
| 286 | 206 | ---- |
| 287 | 260 | |
| 288 | 206 | |
| 289 | 207 | |
| 290 | ||
| 291 | THINGS TO ADD: | |
| 292 | ||
| 293 | 104 | - we don't emit has-child toggled at the moment - it's not strictly necessary as GtkTreeView |
| 294 | 260 | is the only user and it can manage without, but we still should do. |
| 295 | ||
| 296 | 184 | |
| 297 | 425 | CHRISTMAS |
| 298 | 421 | ---------- |
| 299 | ||
| 300 | 89 | Can't access SMB shares on win32 in gtk+ file chooser |
| 301 | - can you access them under loonix? | |
| 302 | ||
| 303 | 165 | sort out path handling in calliope. Don't hardcode paths in random places! |
| 304 | ||
| 305 | 104 | * skip count and play count |
| 306 | 146 | -> How does this relate to last.fm's play count? |
| 307 | The two cannot be linked too closely b/c plays may come from anywhere, not just calliope. | |
| 308 | I guess both measures must be taken into account when deciding popularity etc. but not | |
| 309 | related in any other ways! | |
| 310 | - Or you could not keep a play count! | |
| 311 | ||
| 312 | 112 | - limit on size of 'now playing' label, and source choose combo box |
| 313 | -> in fact, what about that combo box? | |
| 314 | 260 | |
| 315 | 43 | GtkVolumeButton |
| 316 | or if not, at least make our button a gtkscale. | |
| 317 | 67 | - on win32 there is a weird bug which makes our popup window get really stuck .. i think its |
| 318 | 43 | to do with gtkpopup and then alt-tab somehow .. |
| 319 | 165 | - and the icons are clipped. |
| 320 | 260 | |
| 321 | 184 | - non-debug builds should disable all the asserts etc. for speed. |
| 322 | http://svn.gnome.org/viewvc/glib/trunk/docs/macros.txt?view=markup | |
| 323 | - perhaps normal builds shouldn't, but make a seperate 'fast' build which does? | |
| 324 | ||
| 325 | 43 | |
| 326 | 32 | * View config dialog (text, sorting, layout, semantics) |
| 327 | & tree view columns - these should do something like you would expect them to !! | |
| 328 | 42 | Right-click on columns should show a show/hide menu |
| 329 | 32 | |
| 330 | 184 | * custom collation function to give natural sort order from db. well and from genericsource. |
| 331 | 195 | |
| 332 | 260 | installer should detect old calliopes and update! |
| 333 | 184 | Make killing gconf and calliopes in installer a lot more user friendly! |
| 334 | - Only kill them if they are from our install dir. | |
| 335 | - Present a dialog informing the user! | |
| 336 | http://nsis.sourceforge.net/KillProcDLL_plug-in | |
| 337 | - Make sure they are killed! | |
| 338 | ||
| 339 | 197 | * Also, add a 'run program' once calliope is installed. |
| 340 | - http://nsis.sourceforge.net/Run_an_application_shortcut_after_an_install | |
| 341 | -> Can either add a checkbox to 'installing files' page (this looks like I have to make a new .rc | |
| 342 | file with a replacement dialog somehowe) | |
| 343 | -> Or pop up a messagebox with "Run now?" (this is the worst way) | |
| 344 | -> Or add an extra page with "Install complete" and a "run now" checkbox. | |
| 345 | - nsDialogs: http://nsis.sourceforge.net/Docs/nsDialogs/Readme.html | |
| 346 | 260 | Remember also that an elevated installer should run the program not elevated. |
| 347 | 197 | - http://discuss.joelonsoftware.com/default.asp?biz.5.466846.9 |
| 348 | 260 | |
| 349 | 197 | * Add 'version key' |
| 350 | 260 | -> http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.3.1 |
| 351 | 184 | |
| 352 | 32 | when no song is playing but there is a selection, play should change to the selected song, |
| 353 | not a random one | |
| 354 | ||
| 355 | 184 | replaygain working |
| 356 | ||
| 357 | 32 | * Use normal last.fm client optionally |
| 358 | ||
| 359 | Still to do: | |
| 360 | 184 | - reload metadata dialog |
| 361 | 32 | - rganlysis thread priority too high |
| 362 | ||
| 363 | 70 | |
| 364 | 32 | Things for before 0.1 release! |
| 365 | ------------------------------ | |
| 366 | ||
| 367 | 184 | dir watches |
| 368 | 32 | track my music collection on disk, so new added files are added to db automagically |
| 369 | -- watch library dir & automatically a'dd new songs & highlight them - works nicely with bittorrent. Or: add files in a dir automatically, don't move them but highlight/tag so they can be moved at a later date | |
| 370 | 184 | |
| 371 | 32 | add helptext to add music dialog, looks kind of confusing. (also work out why its crashing glade) |
| 372 | 184 | |
| 373 | 235 | needs to add to library on drag .. |
| 374 | 32 | |
| 375 | import should have lower priority, leak less memory | |
| 376 | 207 | |
| 377 | 32 | * gconf - crash when some values change |
| 378 | 110 | -> torture test |
| 379 | 184 | |
| 380 | 248 | |
| 381 | ||
| 382 | ||
| 383 | ||
| 384 | ||
| 385 | 184 | FINAL THINGS BEFORE RELEASE. |
| 386 | ||
| 387 | - go through all the dialogs and make sure it's all good. | |
| 388 | - merge all the existing updates and go back to db ver 1 | |
| 389 | 248 | - tidy up this file & docs etc. |
| 390 | 184 | |
| 391 | 201 | --------------------------------- 0.1 release I guess ! |
| 392 | ||
| 393 | ||
| 394 | 226 | -> discuss, on like gnome-devel lists and desktop-devel lists and places like that ... |
| 395 | 209 | -> fix more things in 0.1 and release 0.2, and add new features into 0.3 ... |
| 396 | 226 | -> make loonix work on pc again |
| 397 | 201 | |
| 398 | ||
| 399 | ||
| 400 | ||
| 401 | ||
| 402 | ||
| 403 | ||
| 404 | ||
| 405 | ||
| 406 | ||
| 407 | ||
| 408 | ||
| 409 | ||
| 410 | ||
| 411 | ||
| 412 | ||
| 413 | ||
| 414 | ||
| 415 | ||
| 416 | ||
| 417 | ||
| 418 | ||
| 419 | ||
| 420 | ||
| 421 | 260 | |
| 422 | ||
| 423 | ||
| 424 | ||
| 425 | 250 | .. this is the stuff to do before a 1.0 release. There is a lot! Some of it can probably move down |
| 426 | to after a 1.0 release, because there isn't that much down there! | |
| 427 | 260 | |
| 428 | 250 | |
| 429 | ||
| 430 | Fix: | |
| 431 | 337 | * player widget is really ugly under the dark ubuntu theme (toolbar is shaded but playbar isn't) |
| 432 | ||
| 433 | 425 | * i18n :( |
| 434 | 274 | |
| 435 | 250 | * accessing drive H under Windows on my laptop (H is an ext3 drive which unreadable by ext2ifs, |
| 436 | so unreadable under Windows) causes gtk file chooser to basically lock up. | |
| 437 | 260 | |
| 438 | 250 | * see jaunty bug https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781 which relates to |
| 439 | 260 | loss of data on ext4 when not fsync()'d or fdatasync()'d properly. |
| 440 | 250 | - This can't affect our database because sqlite3 syncs properly already. |
| 441 | -> The scrobbler disk cache needs to fsync after write so it stays consistent. | |
| 442 | -> Whenever we write tags to a file (which we can't do anyway yet, but still) we need to make sure | |
| 443 | gstreamer syncs property. | |
| 444 | 261 | -> what about using g_file_set_contents(): http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00082.html |
| 445 | 260 | |
| 446 | 250 | * insert some space around the textual time indicator because it is changing the size of the bar a lot and that's weird (might have been done i forget) |
| 447 | 260 | |
| 448 | 345 | * When tracks are removed an album might not be VA any more. |
| 449 | ||
| 450 | 250 | * THE MERGING PROBLEM: |
| 451 | 32 | The merging problem is the cause of the recording.initial-file-path and |
| 452 | album.inital-release-date properties. The issue is that two entries (for | |
| 453 | example, two albums) may differ only by a property in a parent, such as the | |
| 454 | 260 | album's release.date. The thing is, an album does need it's 'initial' |
| 455 | 32 | release highlighted, and a recording needs its highest quality file, for |
| 456 | things like the flat musiclist view and for the player. We can't just use | |
| 457 | a pointer to the entry though, as this is very difficult to add to the db: | |
| 458 | 260 | each entry needs the other's id before it can be added. |
| 459 | 32 | What to do? I don't know. At the moment it works with the kludges in place. |
| 460 | The backpointer entries should be doable if hard. The easiest solution is | |
| 461 | to mark it as a FIXME for later on !! | |
| 462 | 250 | |
| 463 | * On shuffle: when a song is jumped to, should we replace the current song in the | |
| 464 | order with it, or jump to its position in the order? Should be an option I think. | |
| 465 | ||
| 466 | * We use time_t for dates & times which i don't like because of 2038 and all that | |
| 467 | * perhaps this means use time64_t | |
| 468 | 260 | Also I dislike how there is date and datetime, should be possible to encode which part of the |
| 469 | 250 | info is important in the date/time and have just one entry type, ... |
| 470 | ||
| 471 | 267 | * Follow fdo dir spec: http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html |
| 472 | This really only affects the scrobbler disk queue. | |
| 473 | ||
| 474 | 358 | * music source entry notifications should make sure watch-only callbacks don't check out anything |
| 475 | or at least don't check out the entry being notified on | |
| 476 | ||
| 477 | 390 | * How should Calliope behave on a suspend? |
| 478 | -> http://bugzilla.gnome.org/show_bug.cgi?id=402863 | |
| 479 | ||
| 480 | 260 | |
| 481 | 250 | |
| 482 | Features: | |
| 483 | * replace gnomevfs with gio/gvfs, and then make cd playing work again. play cds direct !!! | |
| 484 | Make sure scratched CD's don't cause unresponsiveness like they used to. | |
| 485 | ||
| 486 | 309 | * Improve formats - eg. 44.10Hz isn't great. "Friendly" date output would be nice (code from gtk file manager or something?) |
| 487 | Enums like file type and channels. | |
| 488 | ||
| 489 | * Add more smart columns, and improve existing | |
| 490 | ||
| 491 | 250 | * Use windows file chooser? Or, make gtk+ file chooser faster |
| 492 | ||
| 493 | * any files which gst can't play we need some sort of info box explaining why. In particular we | |
| 494 | 260 | should have special ones for eg. mp3's on ubuntu/debian, where the user needs to know why |
| 495 | 250 | certain codecs aren't installed. |
| 496 | ||
| 497 | * Choosing audio output: | |
| 498 | http://blog.drinsama.de/erich/en/linux/2008122801-gstreamer-enumeration.html | |
| 499 | ||
| 500 | * Album categories - live album, ep, bootleg etc. | |
| 501 | Should these be tags? for the problem of eg. Vic Ruggiero - Alive at the Ladybug House, which | |
| 502 | is predominately new material but still a live album. Allow sorting by these. | |
| 503 | 260 | |
| 504 | 250 | * gapless playback - playbin2 |
| 505 | 260 | |
| 506 | 250 | * unique names for each source - so two with libraries you don't get "copy to music library" and |
| 507 | "copy to music library" | |
| 508 | ||
| 509 | 260 | * What about artists who change their name?? eg black dyke mills band -> black dyke band. |
| 510 | My thought is ARTIST RELATIONS the same way musicbrainz has, which can also be used to link band members to their | |
| 511 | 250 | band and stuff like that ! |
| 512 | 260 | |
| 513 | * Make the process code a whole lot cooler. different ways of displaying progress other than | |
| 514 | 250 | dialog. Note 'mathusalem' project - http://live.gnome.org/Mathusalem |
| 515 | ||
| 516 | 260 | |
| 517 | 250 | * And make notifications non-interrupting like firefox's. |
| 518 | ||
| 519 | * Prevent user from using any of these extensions for db when on Windows: | |
| 520 | http://msdn.microsoft.com/en-us/library/aa378870.aspx | |
| 521 | (all the system restore ones) | |
| 522 | This is: | |
| 523 | 260 | MSDN - MSDN Library - Win32 and COM Development - Administration and Management - |
| 524 | 250 | System Configuration and Servicing - System Restore - System Restore Reference - Monitored File Extensions |
| 525 | at the moment (msdn gets reorganised all the time so I don't want to use a URL) | |
| 526 | 260 | |
| 527 | 250 | * A Calliope auto updater, for Windows! Should be an NSIS feature somehow maybe. |
| 528 | ||
| 529 | * Might be nice to have a "tidy database" option where songs with no recording, etc. are deleted. | |
| 530 | Although there shouldn't be any. I guess this should be a "check database consistency" tool. | |
| 531 | 260 | |
| 532 | 250 | * Allow non-gnome build on LInux?? The only real problem is gconf .... who is also a problem |
| 533 | on Windows. Well make it so KDE'ers and whoever need the minimum of deps to build Calliope. | |
| 534 | ||
| 535 | * HELP for file name filter | |
| 536 | 260 | |
| 537 | 250 | * Use gtkrecent - at least in file-open database dialogs etc |
| 538 | 260 | |
| 539 | 361 | * This would be good for people who want ipod support: |
| 540 | http://www.floola.com/modules/wiwimod/ | |
| 541 | ||
| 542 | 250 | |
| 543 | 446 | |
| 544 | 371 | Instrumentation |
| 545 | * The debug window in Pidgin looks useful. Maybe it could be adapted to be a more generic log tracer ... | |
| 546 | ||
| 547 | Document | |
| 548 | * all of the internals :) A big "how calliope works" document, referenced in comments as relevant, | |
| 549 | instead of having docs scattered around. How about using gtk-doc for the actual functions, and leaving | |
| 550 | major things to hand-written doc files .. | |
| 551 | ||
| 552 | ||
| 553 | 250 | Session Management: |
| 554 | (this is such a crazy problem that I gave it its own header). | |
| 555 | Session management. Here are the things I have in mind. | |
| 556 | * Remembering window geometry (we do this anyway in a dumb way.) | |
| 557 | 267 | : At the moment this is supposed to be the window manager's job. However, Windows |
| 558 | doesn't, Metacity doesn't want to (http://blogs.gnome.org/metacity/2008/03/08/session-management/) | |
| 559 | and it wouldn't affect the app closing and reopening within the same session anyway. | |
| 560 | I definitely think we should manage our window position ourself, which won't be perfect | |
| 561 | on UNIX but perhaps one day will be, if GNOME decide to let the app manage its position, | |
| 562 | and 100% accuracy isn't vital anyway. If a WM does want to save window position itself, we | |
| 563 | should let it however!! | |
| 564 | 250 | * Remembering open sources and playing song (although don't carry on playing, that's too much.) |
| 565 | * Remembering running processes and continuing them. | |
| 566 | -> this behaviour is unexpected so maybe should ask first time. | |
| 567 | * Allowing more than one Calliope (mainly because, why not, and because I want to listen to music | |
| 568 | 260 | in a different Calliope to the one I'm hacking on, but on the same PC). However, the second |
| 569 | 250 | instance shouldn't recall state, it should start afresh. Each saves state so that the one closed |
| 570 | last is the one whose state persists. | |
| 571 | 260 | * Persistance of settings!! At the moment gconf manages this but is that the right approach? |
| 572 | 250 | Should gconf only be for global settings? !!!??? Where does session management end and default |
| 573 | 260 | settings begin? |
| 574 | 250 | That's not very complex. How should this be done? Using gnome-session or equivalent and porting that |
| 575 | to Windows? Different approaches between *nix and Win32? It's all a very complex business. Dbus is | |
| 576 | ropey on Windows so far. | |
| 577 | References: | |
| 578 | 267 | http://bugzilla.gnome.org/show_bug.cgi?id=552387 |
| 579 | 250 | http://live.gnome.org/SessionManagement |
| 580 | http://live.gnome.org/SessionManagement/NewGnomeSession | |
| 581 | http://live.gnome.org/SessionManagement/GnomeSession | |
| 582 | http://live.gnome.org/SessionManagement/SavingState | |
| 583 | http://bugzilla.gnome.org/show_bug.cgi?id=79285 | |
| 584 | http://www.freedesktop.org/wiki/Software/dbus | |
| 585 | http://library.gnome.org/devel/libgnomeui/unstable/GnomeClient.html | |
| 586 | What does Calliope really need from a session manager then? | |
| 587 | * X WM's to remember its position (on Windows we can do this ourselves accurately). | |
| 588 | 260 | Or, in the blue sky there is talk of GTK serialising its state for us. That would be nice. It's |
| 589 | 250 | really a superset of the window geometry functionality, and actually largely unnecessary I |
| 590 | reckon (but still worth doing if it's easy). It's actually a pretty hard thing to do because | |
| 591 | Calliope needs to have its data structures matching GTK+'s state, or the sourceviews etc will do | |
| 592 | 260 | nothing and break. What we can do is use hooks into this imaginary GTK serialisation code to |
| 593 | 250 | save Calliope's own state in the same place though. |
| 594 | 260 | * allow more than one calliope, but don't open default libraries in second one (if they're already |
| 595 | 250 | open?) |
| 596 | http://live.gnome.org/SingleInstanceApps | |
| 597 | ||
| 598 | 267 | Implications of session management: |
| 599 | - no more default library stuff. | |
| 600 | ||
| 601 | 250 | |
| 602 | 259 | STORING DEFAULTS |
| 603 | ---------------- | |
| 604 | ||
| 605 | Things that need storing: | |
| 606 | - view type - a default for each source type | |
| 607 | - playorder - just use last value might be okay?> | |
| 608 | - visible columns - do we want these different for each source type ? | |
| 609 | - sorting - again, different? | |
| 610 | ||
| 611 | This is a problem for the future though I think! | |
| 612 | 260 | *** So, the solution. Save our state into gconf, and wait. Implement GtkUnique (and port that to |
| 613 | 259 | Windows). |
| 614 | - http://live.gnome.org/LibUnique | |
| 615 | There was some discussion over why can't you just use dbus to do what libunique does? The fact | |
| 616 | is I guess libunique is a) easier than implementing dbus? b) a useful bridge for if dbus doesn't | |
| 617 | work on windows (even though we may need it to for gconf 2.24+) | |
| 618 | I can write a nice Windows backend for libunique and everything is cool you see. | |
| 619 | ||
| 620 | 260 | |
| 621 | 250 | Major Things: |
| 622 | 260 | * Jumping to songs & filtering views. This all needs designing and implementing. I want to be |
| 623 | 250 | able to at minimum jump to any song by typing words. |
| 624 | 260 | |
| 625 | 250 | * Editing metadata. Writing it to file tags & rearranging filesystem - either as backup of data |
| 626 | in library, or as only output in Filesource. | |
| 627 | 260 | |
| 628 | 250 | * Queuing/editing playorder - perhaps a playlist above the library, muine-style |
| 629 | 260 | |
| 630 | 250 | * Automatically grab metadata from Musicbrainz (3.0) .. and amazon (album art) .. |
| 631 | and last.fm, one day they will share their metadata I hope. And anywhere else we can go. | |
| 632 | How do we store the album art ? | |
| 633 | 260 | |
| 634 | -> Here is a good idea: any songs where there are errors or confusion etc, should | |
| 635 | 250 | be tagged & highlighted for user to see. This means like VA albums with track |
| 636 | number clashes (which I guess we could probably sort out by looking at filenames | |
| 637 | but that's not the point). And songs which can't be played and whatever else. | |
| 638 | 260 | |
| 639 | 250 | * Tagging (web2.0 sense now) albums, and syncing with some of your last.fm tags, and some of |
| 640 | the global tags ... | |
| 641 | 260 | |
| 642 | 250 | * More playorders: shuffle within album, shuffle albums, etc |
| 643 | 260 | |
| 644 | 250 | * Get it translated! (I doubt internationalisation works at all at the moment. I never remember |
| 645 | to mark strings.) | |
| 646 | ||
| 647 | * make an intro wizard, to set up library, set up last.fm, import music etc. | |
| 648 | 260 | |
| 649 | 250 | * Sharing: |
| 650 | http://snorp.net/log/tangerine [c# though] | |
| 651 | libdaap ?? | |
| 652 | 420 | |
| 653 | * You could rewrite most of entry.c using GVariant when it hits GLib I imagine. | |
| 654 | 250 | |
| 655 | 260 | |
| 656 | ||
| 657 | ||
| 658 | 250 | Major Possibilites: |
| 659 | * Don't do file parsing, tag reading, musicbrainz connection etc. in C. Let some Guile or JS | |
| 660 | code handle the job. I saw a post on Guile being able to read Javascript recently. I'd love to | |
| 661 | be able to use Scheme or Javascript to do whatever I feel like with the tags, and let people | |
| 662 | create metadata plugins for other services which Calliope can use without a recompile. | |
| 663 | 260 | |
| 664 | 250 | A tiny bit related to this is the GSoC 2009 idea to improve GST's tag reading. It should be |
| 665 | easily usable from GUILE etc - we could create a binding inside Calliope, but it would be nice | |
| 666 | to not have to. | |
| 667 | 260 | |
| 668 | 250 | Also, since I want Calliope data to be written back out to tags and to the FS, maybe the GUILE |
| 669 | backend can do that. Actually, I think that would introduce too much of a security risk because | |
| 670 | 260 | suddenly arbitrary scripts can access your FS. So that can still be done in C. |
| 671 | ||
| 672 | 250 | * Rating songs/albums/etc somehow by putting them in order of preference |
| 673 | 260 | |
| 674 | 250 | * EQ on a per-album/per-song basis, plus globally ... really? Don't implement this. |
| 675 | 260 | |
| 676 | 250 | * CD burning - I consider this a problem of integration rather than implementation because it's |
| 677 | silly for Calliope to reimplement the wheel. On Windows we can integrate with Infra Recorder, | |
| 678 | or I guess possibly bundle its core or something? (Which I think is cdrtools anyway). | |
| 679 | On Linux we can integrate with everyone, including cdrtools perhaps. | |
| 680 | 267 | GNOME has Brasero now which exposes an API. |
| 681 | 351 | |
| 682 | 446 | * CD ripping: https://thomas.apestaart.org/morituri/trac/ |
| 683 | best option on linux. it can probably be made to run on win32 too to replace the closed-source | |
| 684 | EAC. | |
| 685 | ||
| 686 | 350 | * A 'dislike' button, which won't do anything drastic like delete the file, but kind of |
| 687 | plays it less and less, and you can sometimes clean out your most disliked artists. | |
| 688 | 250 | |
| 689 | ||
| 690 | ||
| 691 | Infrastructure: | |
| 692 | * find out about distributing Windows binaries with faad and mad (patent issues etc) | |
| 693 | 260 | |
| 694 | 250 | * wscript should run conftool. |
| 695 | 260 | |
| 696 | 418 | * I really like git commit --amend. Could this be a bazaar plugin ?? |
| 697 | ||
| 698 | * On that subject, bazaar plugins annoy me, I wish they were merged into core. The ones I | |
| 699 | like to use are: | |
| 700 | -> lessdiff (& colordiff) | |
| 701 | -> lesslog | |
| 702 | -> textchecker | |
| 703 | ||
| 704 | 250 | * bring waf up to date, make wscript nice and neat. |
| 705 | 260 | |
| 706 | 250 | * 'jhbuild shell' doesn't work! And it seems to give some insight into MSYS's ctrl+c problem |
| 707 | when using cmd.exe as terminal. | |
| 708 | ||
| 709 | * Spin off conftool as its own program .. or, see how easy it would be to replace it with autogen. | |
| 710 | ||
| 711 | 260 | * gconf on Win32 has some weird failures depending on unset environment variables. See: |
| 712 | 250 | SYSTEMROOT, PATH (of course) and TMP and TEMP somehow .. and possibly more .. |
| 713 | ||
| 714 | * the typeahead find in gtk open dialogs is really irratiting. | |
| 715 | 260 | |
| 716 | * Just reduce the huge number of DLL's and the size of them that we have to load on startup. | |
| 717 | 250 | I guess we could build -lite versions of some of the bigger libs that we don't really use? |
| 718 | I dunno there must be some way to trim the fat. | |
| 719 | 260 | |
| 720 | 250 | * Use shared gtk+ on Windows. Maybe a shared gstreamer too. |
| 721 | ||
| 722 | 266 | * looks like you can generate marshals automagically! |
| 723 | http://www.barisione.org/blog.html/p=136 | |
| 724 | http://cgwalters.livejournal.com/23514.html | |
| 725 | ||
| 726 | 269 | * trunk jhbuild seems to have some win32 modulesets .. I don't know how they work. |
| 727 | ||
| 728 | 297 | * waf on win32 needs some love. Most of the unit tests fail. Lots of things don't work and lots |
| 729 | of stuff in my wscript is hacks. | |
| 730 | ||
| 731 | 350 | * http://code.google.com/p/omaha |
| 732 | Use this to autoupdate calliope on win32 | |
| 733 | 250 | |
| 734 | 402 | * autogenenerate changelog from bzr log when building a tarball |
| 735 | ||
| 736 | 250 | Promote: |
| 737 | * Register Calliope's URL with last.fm people. | |
| 738 | 260 | |
| 739 | 250 | * http://en.wikipedia.org/wiki/List_of_GNOME_applications |
| 740 | 260 | |
| 741 | 250 | * http://www.ogmaciel.com/?p=666 |
| 742 | ||
| 743 | ||
| 744 | Optimise: | |
| 745 | * Speed calliope startup further. speed test it! | |
| 746 | - http://www.gnome.org/~federico/hacks/index.html#performance-scripts | |
| 747 | - optimise all the gconf interaction; there's loads of wasted energy there. | |
| 748 | - make sure sources and views output the minimum of signals possible .. | |
| 749 | ||
| 750 | * Give libraryview indices: create index on each column used in a where clause | |
| 751 | This should be done through library somehow so that it can drop and recreate the indices | |
| 752 | 260 | on updates .. |
| 753 | 351 | |
| 754 | 349 | * Optimise signal emissions. Edit the queue. Make sure changed only gets emitted if the entry |
| 755 | actually changed. | |
| 756 | 250 | |
| 757 | * Make library drop and recreate indices on big updates. | |
| 758 | 260 | |
| 759 | 274 | * Make sure the library cache is as much use as it could be. |
| 760 | ||
| 761 | 250 | * Just make calliope really fast! Profile it! |
| 762 | 260 | |
| 763 | 250 | * http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuning and http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuningWindows |
| 764 | 260 | |
| 765 | 261 | * The unit tests have got to being pretty slow. Speed them up as best you can by optimising the code |
| 766 | they test, but I think some also need scaling down at least when not run with --thorough. | |
| 767 | 269 | libraryview-test in particular! Why is it so slow!!! |
| 768 | 261 | |
| 769 | * add music dialog does searches sequentially. This is actually silly in the case that two searches | |
| 770 | are on different drives, because the two would run faster concurrently. | |
| 771 | 250 | |
| 772 | 269 | * trace everything the source does during an import some time. It's a crazy amount of stuff! Surely |
| 773 | you could reduce that some how! | |
| 774 | ||
| 775 | 303 | * This is quite a petty optimisation, but it's good to minimise gobject casts. Perhaps it's best |
| 776 | to write a tool to do this automatically. | |
| 777 | ||
| 778 | 432 | * In "artist[name]:recording[name]:file[path]" for example, every time a recording is added, we |
| 779 | get a changed notify on its artist. This is correct, because that recording could have moved in | |
| 780 | the list, so we might have to emit rows-reordered for the artist-node ... but, at the moment we | |
| 781 | look to see if any of the recordings under artist have moved, one by one (because of the | |
| 782 | recursive propagate_forwards). We should really just check the recording that actually changed, | |
| 783 | and if that hasn't moved none of the others possibly could have .. | |
| 784 | ||
| 785 | 250 | |
| 786 | Potential Optimisations: | |
| 787 | * Lazy views (ie. libraryview) could maybe on idle query the pages either side of current | |
| 788 | page, and the next few pages in playorder. We don't want to go crazy and fill RAM up with | |
| 789 | stuff we might discard straight away again if memory is tight though. In fact this is probably | |
| 790 | best not happening where small memory footprint is more important than performance. I guess | |
| 791 | that should be configurable ??? Or not. | |
| 792 | 260 | |
| 793 | 250 | * Make page list in musicsourceview a tree. GSequence is a Btree ... |
| 794 | First, think carefully about how the page list is used - this probably isn't actually a very | |
| 795 | good optimisation. | |
| 796 | ||
| 797 | ||
| 798 | Refactor: | |
| 799 | 374 | * It seems you could make ViewNode more of an object (don't actually make it an object) but for |
| 800 | example each node could handle emit notifications in its children and the code might be more | |
| 801 | logical in genericview then .. | |
| 802 | ||
| 803 | 307 | * Make the guts of calliope a bit cleaner - every file has to include 'misc.h', surely this |
| 804 | should be 'calliope.h' or something? | |
| 805 | ||
| 806 | 260 | * Should have MusicSourceView implementing a new 'PagedTreeModel' interface, and then a |
| 807 | 250 | GtkTreeModelProxy wrapper between it and the GtkTreeView. |
| 808 | 260 | |
| 809 | 250 | * Use NOT NULL everywhere in Library. |
| 810 | http://fishbowl.pastiche.org/2009/01/30/why_null_is_special/ | |
| 811 | 260 | |
| 812 | 250 | * Use sqlite's own foreign key constraints etc. |
| 813 | ||
| 814 | 260 | * Remove music_source_get_loaded - but bear in mind the generic music_source_is_empty needs a |
| 815 | way of knowing if source is loaded so it doesn't return TRUE when there are 0 entries but | |
| 816 | 250 | the source hasn't loaded yet. Although I guess we need to emit a signal when is-empty toggles |
| 817 | anyway, so whoever calls is_empty could be expected to just watch for that signal. In fact, | |
| 818 | you should probably replace is_empty with a property and anyone who needs to know it should | |
| 819 | connect to notify::is_empty. | |
| 820 | 260 | |
| 821 | 250 | * Remove the 'Music' prefix from a bunch of the classes? I mean what else are they going to hold |
| 822 | 260 | |
| 823 | 250 | * Make unit tests code as nice as possible - a set of tidy macros .. |
| 824 | 260 | |
| 825 | 250 | * Sort out headers, we include all sorts of unnecessary things. You could make a tool to do that |
| 826 | perhaps. | |
| 827 | HERE is a useful idea: a tool which can point out which pieces of code are gonna be affected by changing other parts !! | |
| 828 | 390 | |
| 829 | 438 | * entry_set_property etc. could use varargs instead of void * pointers, it would be neater. |
| 830 | ||
| 831 | 250 | prune all of the dead code |
| 832 | - hey you could make a tool to do that to ! | |
| 833 | - tidy all source files | |
| 834 | * Doesn't follow the GNOME coding standards, although I probably don't want to follow them to the letter | |
| 835 | 260 | |
| 836 | 250 | * Use signal detail (::) in more places. |
| 837 | 260 | |
| 838 | * Use g_signal_connect_object everywhere that you should. | |
| 839 | ||
| 840 | 390 | * s/entry/entity/ ??? |
| 841 | ||
| 842 | 261 | * Be consistent about what functions you prefix with _'s. It seems like only private but shared |
| 843 | functions need a _ prefix, static internal functions don't need one, but you like to give them | |
| 844 | one anyway :( | |
| 845 | 260 | |
| 846 | 264 | * musicsource probably has a bunch of unnecessary interface. |
| 847 | 351 | |
| 848 | 350 | * We can never really pass around const Entry *'s, because that prevents functions reffing and |
| 849 | 351 | unreffing the entries. It would be nice if there was some way of distinguishing between |
| 850 | 350 | entries that can be modified (ie. result of a checkout), and entries that can only be reffed |
| 851 | (and entries that can be reffed but must be unreffed again before call returns if possible as | |
| 852 | well - ie. an entry that can't be 'owned' .. although this is awkward. The problem I have | |
| 853 | in mind is that in viewconfig.c for example, part of the tree passed to view_config_walk may | |
| 854 | be reffed to be returned in an accumulator, because accumulator entries are expected to have | |
| 855 | one ref. It would be cool if instead, the accumulator itself was smarter and new what needed | |
| 856 | unreffing and what wasn't. This would in fact mean that entries that could not be modified or | |
| 857 | preserved (reffed and unreffed) could be const, because we could say you can't ref these | |
| 858 | either.). | |
| 859 | 264 | |
| 860 | 250 | |
| 861 | Test: | |
| 862 | * flesh out main-test/final | |
| 863 | 344 | |
| 864 | 311 | * Make sure we only have the unit tests we need. |
| 865 | ||
| 866 | 286 | * make a nice easy way to define entry trees, for unit tests mainly |
| 867 | ||
| 868 | 261 | * unit tests for last.fm - special chars etc. |
| 869 | ||
| 870 | 250 | - and, on unix, processes with and without GDK_SINGLE_THREAD |
| 871 | - I reckon should be waf option to enable all of those things! | |
| 872 | ||
| 873 | * Fix up wscript to stop regressions in the execution speed. | |
| 874 | -> store results somehow - sqlite? xml? in a year, fulltime working, you waf check say 20 | |
| 875 | times a day, 5 days a week, 48 weeks a year. 4800 data. Or, is there some format that allows | |
| 876 | easy graph plotting? What do things like GNU graph plotting program or whatever like for input? | |
| 877 | with: unique machine id (uuid I guess, plus spec) | |
| 878 | what you need is, a table of measures and tests, automatically updated | |
| 879 | 260 | and a table of results with measure id, current time, |
| 880 | 250 | -> spin off as a waf plugin, with a tool /script to plot graphs of the reusls |
| 881 | -> actually, this should really be part of gtester .. | |
| 882 | 260 | |
| 883 | 250 | * make it so reverse treemodels work - file:recording:track:release:album .. although that's a |
| 884 | pretty useless thing to do, it would test the orphan code to perfection. Actually it wouldn't, | |
| 885 | because most of these joins are non-nullable (m+:1) joins. Still, you need to check those work. | |
| 886 | ||
| 887 | * add speed test for when there are like 1-1000 files per rec. | |
| 888 | ||
| 889 | * run main-test with custom gconf. | |
| 890 | http://blogs.gnome.org/tthurman/2008/12/13/i-may-have-posted-about-this-already/#comments | |
| 891 | try this on linux first! | |
| 892 | 260 | |
| 893 | 250 | * test filesource-test with lots of album tagging/naming styles? This probably requires the |
| 894 | module to be opened up slightly to allow the tests to give mock taglists. | |
| 895 | 260 | |
| 896 | 250 | * valgrind memfault - causes every nth malloc to fail |
| 897 | 260 | |
| 898 | 250 | * And use valgrind's memcheck to sort out all of our memory leaks ! |
| 899 | also, g_slice allocator can do useful stuff like say when things haven't been | |
| 900 | freed on shutdown, I believe. | |
| 901 | ||
| 902 | * strace calliope & make sure we don't do too much shit when we should be idle ! Minimise power | |
| 903 | use !! | |
| 904 | 260 | |
| 905 | 250 | * test dialogs and changesets and all that nonsense. |
| 906 | 286 | |
| 907 | * semantic checks on schema. | |
| 908 | 285 | -> an entry must have some unique (non-trivial & non-shadow) properties, so merging |
| 909 | works | |
| 910 | -> no circular links? things like that. | |
| 911 | 250 | |
| 912 | 421 | * g_test_timer is redundant, just make g_test_trap_fork work on win32 .. :) |
| 913 | 260 | |
| 914 | 445 | * What happens if you remove an album, do its recordings get deleted? |
| 915 | ||
| 916 | ||
| 917 | ||
| 918 | 250 | |
| 919 | Design: | |
| 920 | * Make the settings as concise, pretty, intuitive and powerful as possible! | |
| 921 | 260 | |
| 922 | 250 | * What should the selection do when the song changes? I think if the selection is the prev song, |
| 923 | move selection, otherwise do nothing | |
| 924 | 260 | |
| 925 | 250 | * Make the menus logical. Don't have anything in right-click that you can't do in main menu. |
| 926 | 260 | |
| 927 | 250 | * I'd prefer if we could have one close button for tabs like firefox rather than like, |
| 928 | one for each. However, see gnome bug 116650 | |
| 929 | ||
| 930 | * Just make calliope less ugly!! Check against GNOME HIG! | |
| 931 | 260 | |
| 932 | * some programs, like for example anjuta, have really cool docking interfaces. would be nice if | |
| 933 | all of the interface junk in calliope could be rearranged as well. i also like the inform 7 | |
| 934 | 250 | approach of it all being two paned like a book |
| 935 | 260 | |
| 936 | * come up with some cool theme to make the whole thing look better and less like every gtk2 app. | |
| 937 | 250 | make it skinnable using gtk3's CSS theme engine :) |
| 938 | ||
| 939 | 432 | Integrate & standardise: |
| 940 | * Calliope's schema should really be an RDF ontology. Maybe there is one we can already | |
| 941 | use.. Nepomuk has an 'id3 ontology': | |
| 942 | http://www.semanticdesktop.org/ontologies/2007/05/10/nid3/ | |
| 943 | but this is useless (it has all the same issues as id3, such as one audo file only | |
| 944 | being on one album). | |
| 945 | ||
| 946 | * Then we can integrate with tracker and beagle | |
| 947 | ||
| 948 | * What else is cool? Zeitgeist, Gnome Shell .. | |
| 949 | 250 | |
| 950 | 453 | * On clever audio platforms (PulseAudio, windows Vista, smarty mac audio thing), surely the |
| 951 | volume controller in Calliope should connect to the application's output volume in the system | |
| 952 | mixer? No point using gst 'volume' element when the OS can already our output volume to whatever | |
| 953 | level we want. Maybe other pulse/etc. features should be controlled from calliope, like what | |
| 954 | speakers the output goes to ... hmm. | |
| 955 | ||
| 956 | 250 | |
| 957 | ||
| 958 | ----------------------------------------------- | |
| 959 | 1.0 release?? .. ---------------------------- | |
| 960 | ----------------------------------------------- | |
| 961 | 209 | |
| 962 | 32 | Optimisation |
| 963 | 364 | * entry-notify signal is emitted a lot, way too much |
| 964 | 32 | * the g_signal_has_handler_pending() function can save emitting signals with complex |
| 965 | arguments which noone is listening for anyway. | |
| 966 | 55 | * http://www.gnome.org/~federico/news-2006-03.html#timeline-tools |
| 967 | 111 | * Power usage - don't wake up so much when main window is not visible, for example. No |
| 968 | 364 | need to update playback progress if its invisible. |
| 969 | 128 | * Use G_GNUC_PURE (no side effects) and G_GNUC_CONST (no side effects and a function only |
| 970 | of parameters), and the other available constants. | |
| 971 | 130 | * Make a list of all the hotspots for optimisation, and optimise them all .. |
| 972 | 260 | |
| 973 | 136 | * Speed up _locate_entry and friends. |
| 974 | - Speed up compare-entries somehow | |
| 975 | 260 | - Interpolate? This could take up more cycles than it saves. I think it would only |
| 976 | 136 | spare a few iterations so isn't worth doing. |
| 977 | 260 | |
| 978 | 168 | * Precalculate (sqlite3_prepare_v2) as many queries in Library as possible. |
| 979 | 260 | |
| 980 | 390 | * Why is calliope.dll > 2MB ?? |
| 981 | ||
| 982 | 260 | |
| 983 | 32 | General |
| 984 | * Tighten all the code so you are sure it all works all the time! | |
| 985 | * Add unit tests for everything | |
| 986 | * Why not make an amalgamation version, like SQLite's ? Would be lots faster? | |
| 987 | could be a generic utility really that does an amalgamated compile .. | |
| 988 | 91 | could be a waf plugin ... |
| 989 | 32 | * Make info pane a lot more pretty etc. |
| 990 | * Make the commandline interface completely usable, for backwards people. More usefully it | |
| 991 | will make sure all the ui code is seperated off cleanly enough (even though the core does | |
| 992 | depend on gtk due to musicsourceview being a gtktreemodel). I would say for this to work, | |
| 993 | 260 | switches alone are not enough - calliope needs a set of commands such as import, play, |
| 994 | 32 | etc. |
| 995 | * It's a dull job, but be consistent with #includes - either each header should include | |
| 996 | everything it needs, or nothing that it needs. | |
| 997 | * How I can I play my iTunes music which has drm ? http://www.el-tunes.com/ !!! | |
| 998 | More generally, when Calliope can't play something it should do as much as it can to | |
| 999 | help the user download the plugins they need. Should this be a calliope feature, an OS | |
| 1000 | feature, a gstreamer feature .. ? Does totem, rhythmbox, songbird do this already? | |
| 1001 | One idea is a central registry online for 'what can play what' .. that way the info | |
| 1002 | calliope ships with has less danger of becoming stagnant in a really old install. | |
| 1003 | 48 | Points of reference for this: |
| 1004 | - Totem uses PackageKit: http://packagekit.org/ | |
| 1005 | 260 | Talking of that: |
| 1006 | 32 | * An autoupdate mechanism on platforms that need it. ie, windows and linux built from source. |
| 1007 | I guess you should really just make it disablable for distros with packages etc. | |
| 1008 | 44 | * A script that keeps FIXME's sync'ed with a bug tracker ... |
| 1009 | 61 | * i18n :( |
| 1010 | 86 | * All of our caches: |
| 1011 | http://bugzilla.gnome.org/show_bug.cgi?id=168417 | |
| 1012 | 98 | * Fix any functions which are more than a couple of pages in length. |
| 1013 | -> It would be nice to have a tool which could highlight these functions .. | |
| 1014 | 187 | * Fix all of the fixmes .... |
| 1015 | 260 | |
| 1016 | 250 | * Plugin architecture? |
| 1017 | - http://taschenorakel.de/mathias/2009/01/12/gtkbuilder-based-plugin-system/ | |
| 1018 | 260 | |
| 1019 | 250 | * Fill calliope up with interviews, .. and videos ..... ??? |
| 1020 | ||
| 1021 | 402 | * Use xesam [http://xesam.org/main] to our advantage |
| 1022 | ||
| 1023 | 250 | |
| 1024 | 260 | |
| 1025 | 213 | Schema: |
| 1026 | 260 | * It would be nice to be able sort classical music by opus, and then list the performances |
| 1027 | 213 | available. |
| 1028 | 260 | |
| 1029 | 52 | Refactoring: |
| 1030 | 260 | * why not use gvalue's in entry ??? |
| 1031 | ||
| 1032 | 45 | Radical: |
| 1033 | 260 | * allow zooming in and out of the view. At the smallest zoom all the tracks are there |
| 1034 | 45 | with lots of details on each one. At the highest zoom its just lists of artists, or |
| 1035 | album cover thumbnails, or whatever is appropriate. | |
| 1036 | 402 | * fullscreen mode. Also, surely the maximise button should be fullscreen not just maximise. |
| 1037 | 56 | |
| 1038 | MusicSource: | |
| 1039 | * adding entries is traumatic. The problem is with adding an entry, and then using that | |
| 1040 | Entry * object even though its now invalid. Perhaps entries should be able to be marked | |
| 1041 | 76 | as invalid to prevent this. |
| 1042 | 260 | |
| 1043 | ||
| 1044 | 32 | MusicSourceView: |
| 1045 | * storing the default view configs should be much more granular - at least, one for each | |
| 1046 | class of musicsource, not just one big everchanging default. Maybe make it configurable | |
| 1047 | too rather than using the last closed source. | |
| 1048 | 34 | * I have used 'relation' to mean 'foreign key' in a bunch of places. |
| 1049 | 42 | * although the default musicsourceview implementation is meant only for small in-memory |
| 1050 | collections (eg. one or two directories/albums), it could be optimised a fair bit and | |
| 1051 | made to not block for hours or use 2gb of virtual memory when it's asked to do too much. | |
| 1052 | 260 | |
| 1053 | 42 | * it could do with more advanced testing. I am picturing a standard source with two albums, |
| 1054 | some orphan tracks, etc. Then a textual description of how it should be displayed: | |
| 1055 | "Album 1" | |
| 1056 | "> Artist 1" | |
| 1057 | "> > Track 1" | |
| 1058 | "Orphan recording 1" | |
| 1059 | or some such. This would be much more intuitive than the result=gtk_tree_model_* stuff | |
| 1060 | we do at the moment. And we could give more informative error message. It's quite a big | |
| 1061 | job to implement though. | |
| 1062 | 57 | * we are pretty sloppy about setting the n_ values, since they don't matter to anyone right |
| 1063 | now. Still kind of bad though. Really libraryview only this problem. | |
| 1064 | 260 | |
| 1065 | 67 | * a fill_node_idle - this should be smart and load the pages either side of current, and the |
| 1066 | next few pages pointed to by the playorder. | |
| 1067 | 260 | |
| 1068 | 50 | LibraryView: |
| 1069 | 51 | * LIMITs. One day it would make sense when the queries are returning 10 million rows to |
| 1070 | LIMIT them each time. At the moment 10M rows is like 640MB. Well if we just stored them | |
| 1071 | 260 | as two ints instead of directly from sqlite, that would be down to like 80MB. LIMITs |
| 1072 | 51 | will slow things down a lot I believe so I want to hold off on them as long as possible. |
| 1073 | 32 | |
| 1074 | UI: | |
| 1075 | * Presets in the view config dialog could be lots better. Should be able to edit them without | |
| 1076 | having to delete them and readd them and stuff. | |
| 1077 | 52 | Also, you can't tab onto them. |
| 1078 | 184 | * Calliope should be able to be really thin if you want it to! |
| 1079 | 260 | |
| 1080 | 32 | Processes: |
| 1081 | * see Nautilus source code b/c it does a similar thing with file ops | |
| 1082 | * Estimated completion time | |
| 1083 | * mathusalem | |
| 1084 | 260 | |
| 1085 | 32 | Windows: |
| 1086 | 54 | * as of 2.14, we need to either build our own gtk+ with only the gdi pixbuf loaders, or |
| 1087 | have jhbuild get jpeg62.dll and libtiff3.dll :( | |
| 1088 | ||
| 1089 | 32 | * minimise our dependencies !!!! (well in general as well I guess) |
| 1090 | 260 | |
| 1091 | 445.1.1 | GNOME: |
| 1092 | * with NetworkManager we can do things when network is up etc. | |
| 1093 | ||
| 1094 | 32 | * g_spawn_* has the following checks |
| 1095 | if (!standard_input && !standard_output && !standard_error && | |
| 1096 | (flags & G_SPAWN_CHILD_INHERITS_STDIN) && | |
| 1097 | !(flags & G_SPAWN_STDOUT_TO_DEV_NULL) && | |
| 1098 | !(flags & G_SPAWN_STDERR_TO_DEV_NULL) && | |
| 1099 | (working_directory == NULL || !*working_directory) && | |
| 1100 | (flags & G_SPAWN_LEAVE_DESCRIPTORS_OPEN)) | |
| 1101 | if it's all passed then the cumbersome spawn helper program isn't need. Hack up gconf to | |
| 1102 | 42 | spawn its client this way to increase load time ! Then we can not include g_spawn_helper |
| 1103 | as well! Perhaps. | |
| 1104 | 260 | |
| 1105 | 32 | * improve jhbuild infrastructure - list of things to at: |
| 1106 | http://calliope.sourceforge.net/jhbuild-win32.html | |
| 1107 | 167 | In particular, it would be nice to have new versions of packages handled. Say when a newer |
| 1108 | version is found than listed, it gave a choice (or uses the default value): | |
| 1109 | - ignore | |
| 1110 | - use the newest (and change the moduleset accordingly) | |
| 1111 | 260 | - run specified unit tests, check that they pass, build with the newest, |
| 1112 | 167 | run specified unit tests again, and if they now fail flag up the problem present more options: |
| 1113 | - go back to old version | |
| 1114 | - leave new version, but optionally go back at a later date. | |
| 1115 | This is a complex thing to implement I realise! | |
| 1116 | 260 | |
| 1117 | 52 | * patch under mingw fucks up with unix line endings in a patch? or something? there must |
| 1118 | be some reason my patch from svn diff mostly failed. | |
| 1119 | 260 | |
| 1120 | 70 | * be nice if we could use gtester on windows. |
| 1121 | 260 | |
| 1122 | 248 | * gcc 4 on windows |
| 1123 | 260 | |
| 1124 | 91 | * should we use wasapisink on Vista now ? well gstreamer should choose the best |
| 1125 | output automatically of course. | |
| 1126 | 260 | |
| 1127 | 32 | Replay gain: |
| 1128 | * is calcing rg for the song you are playing the best way? Why not just go all through collection or | |
| 1129 | something? Also process should be pausable to not cane the old cpu ?? | |
| 1130 | * support for audiophile/album analysis. This entails finding a single gain for an entire album. The difficultly | |
| 1131 | is finding out which tracks are from the same rip of the same pressing of the same mix of an album, because | |
| 1132 | otherwise we're going to get useless results. Options are I guess | |
| 1133 | - let the user decide | |
| 1134 | 260 | - go on |
| 1135 | 32 | - do all albums with the second heuristic and let the user point out when it's wrong |
| 1136 | - all three (configurable) | |
| 1137 | So I guess the difficultly really is just implementing doing all of that. Also there would need to be a way | |
| 1138 | to select which mode to playback in (although this could be guessed as well, shuffle should play in radio mode | |
| 1139 | and album shuffle or sorted should play in album mode). | |
| 1140 | 260 | |
| 1141 | 32 | Conftool: |
| 1142 | * none of the conftool dialogs need to be modal any more but they still are. | |
| 1143 | 267 | * we could do away with conftool's dialog building altogether, and reimplement it as |
| 1144 | a GLADE plugin using this gtk-builder code. Don't forget the original problems conftool was | |
| 1145 | partly to solve - such as how difficult it is to make pretty dialogs in gtk-builder. | |
| 1146 | * And, could we rewrite the rest using autogen ??? | |
| 1147 | 260 | |
| 1148 | ||
| 1149 | 172 | Testing: |
| 1150 | * it's kind of weird we write tests in seperate files to where they're defined and in a | |
| 1151 | different place. Especially for simple tests like AddMusicDialog's. Just put it in the | |
| 1152 | same file and link it with some #define magic or something .. more complex tests could | |
| 1153 | 260 | go in seperate files but still in the same directory. |
| 1154 | 32 | |
| 1155 | Other features: | |
| 1156 | * spectrogram | |
| 1157 | 260 | |
| 1158 | 67 | Bugs which are probably due to other things: |
| 1159 | * songs which are like 17777 minutes long when they're really not. | |
| 1160 | 260 | |
| 1161 | 250 | To read: |
| 1162 | 260 | * http://library.gnome.org/devel/accessibility-devel-guide/ |
| 1163 | 344 | |
| 1164 | 332 | Lib code: |
| 1165 | * process.c could become GProcess and GtkProcess (those aren't great names because 'process' is | |
| 1166 | already an important term in the same area). GAsyncLoop? That's not very catchy. | |
| 1167 | 344 | |
| 1168 | 332 | * misc.c could have some stuff moved into glib |
| 1169 | 344 | |
| 1170 | 332 | * format.c could go in glib, it's useful code and needs good i18n. |
| 1171 | 260 | |
| 1172 | 34 | Learn from the competition: |
| 1173 | * Banshee - http://banshee-project.org/ | |
| 1174 | * foobar2000 - http://www.foobar2000.org/ | |
| 1175 | * iTunes - http://www.apple.com/itunes/ | |
| 1176 | * Muine - http://muine-player.org/ | |
| 1177 | * Songbird - http://www.songbirdnest.com/ | |
| 1178 | * Rhythmbox - http://www.gnome.org/projects/rhythmbox/ | |
| 1179 | 91 | del.icio.us tag 'calliope' |
| 1180 | 260 | |
| 1181 | 34 | Why write Calliope with all these other players which are much more complete? |
| 1182 | The main reason is the internal database structure. Absolutely none of these projects | |
| 1183 | 260 | show any inclination to do away with the standard metadata of basically artist, title, |
| 1184 | 34 | album, track. Believe me, I check worriedly for another project implementing a new |
| 1185 | 260 | type of internal storage all the time because I don't want to be wasting time doing |
| 1186 | something which is being done elsewhere. Seems to me there is no danger of this at | |
| 1187 | all right now. | |
| 1188 | ||
| 1189 | 32 | Long term thoughts |
| 1190 | ------------------ | |
| 1191 | 260 | - i would love to have an IDE which could dynamically resize the code, basically wrapping it to a |
| 1192 | 229 | set line width using a clever algorithm. bw. |
| 1193 | ||
| 1194 | 188 | - How could you make Calliope exposable to some sort of DJ-ing app like Traktor? What you want is to |
| 1195 | give the DJ program access to Calliope's library somehow, but to take the filename instead of | |
| 1196 | letting Calliope play it. | |
| 1197 | 32 | |
| 1198 | 260 | - Turn your crazy database idea into a reality and make it so calliope (even in its present form) can |
| 1199 | 250 | connect & interact to it |
| 1200 | ||
| 1201 | 98 | - I kind of like the look of Vala. And, because it compiles down to C code a gradual rewrite would |
| 1202 | be entirely practical I think. Does a tool exist to do a best guess conversion of C code to Vala | |
| 1203 | code? because this seems possible .. | |
| 1204 | ||
| 1205 | 32 | - Calliope has at its core a very flexible heirachical database. The view configurations are |
| 1206 | essentially queries on this database, in a form useful for displaying. For starters, this | |
| 1207 | means musicsourceview::fill-node's queries should really be handled entirely in the music | |
| 1208 | source, with library generating SQL queries on the fly (or somehow using precalculated ones) | |
| 1209 | and importing doing some of what the sourceview does at the moment. | |
| 1210 | 260 | |
| 1211 | 32 | - In the bigger picture, Calliope's database routines are suitable for managing anything with |
| 1212 | metadata that forms a heirachy (or doesn't). Photos, movies, writing, bookmarks, anything | |
| 1213 | and everything. Slice them off and make a generic library, which calliope can use as a base. | |
| 1214 | Only do this once you've thought of other uses for the library of course. | |
| 1215 | 260 | |
| 1216 | 32 | - If you do end up using GUILE for something, you could also reimplement view configs using kind of |
| 1217 | 260 | a LISP syntax. |
| 1218 | ((artist :sort-by name :show-orphans) > | |
| 1219 | 32 | (album) : (release :sort-by date :sort-direction desc) |
| 1220 | .... | |
| 1221 | ||
| 1222 | 250 | - Could rowid vars ever overflow ? sqlite uses long longs for them. |
| 1223 | ||
| 1224 | 32 | - http://cgwalters.livejournal.com/18523.html |
| 1225 | This is about making RhythmBox a 'transient' application - which exists largely as a notify | |
| 1226 | icon, and pops up just for you to change the song. I don't really see if that's appropriate | |
| 1227 | for calliope since it wants to do more than that sometimes. .. | |
| 1228 | 260 | |
| 1229 | 85 | - http://mpd.wikia.com/ |
| 1230 | Could calliope just become an mpd client? | |
| 1231 | Personally I am unconvinced of the value of mpd, it's only real use case seems to be if you | |
| 1232 | have a crashy x, you can play music anyway. Since ui is seperate from core we could fairly | |
| 1233 | easily make calliope a daemon or a commandline interface. It seems like several players, such | |
| 1234 | as rhythmbox, kind of operate as a daemon with a dbus interface anyway, maybe we could just | |
| 1235 | 260 | go the whole hog and set up calliope in this manner? Although I haven't looked, I imagine |
| 1236 | 85 | mpd would not support everything calliope wants to do without some major work. |
Loggerhead is a web-based interface for Bazaar branches