This past week I have gotten some time to close some long standing audiocd bugs such as 64-bit issue, usability issuie and a case were audiocd would lock your cd drive. More importantly as new issues are opened I will be able to much more quickly respond. I have backported what I could to 3.4.3, which I am sure will make users happy, if 3.4.3 is released. I have begun working on changes for KDE 3.5 and 4 for audiocd and KAudioCreator. Due to binary incompatible issues with libkcddb I wont be able to do everything, but I hope to get a lot into 3.5. One patch that has been sitting in my inbox for a few months is a change for KAudioCreator to use KCompactDisc which is a new library for KDE 3.5. KCompactDisc is the wrapper of libwm and the media ioslave that behaves and looks like a normal Qt class. Sense the original version of audiocd there has been some major hacks to get around libcdparinoia's issues (bugs). So on Friday after getting in a patch in that would let KCompactDisc behave asynchronously I quickly ripped out a lot of duplicate junk in audiocd and converted it to use KCompactDisc. A few hours later I discovered that during ripping audiocd would crash... Though different methods I discovered that if I just link to libkcompactdisc audiocd would crash. Some sort of namespace pollution was occurring. After dinner I wrote a script that dumps all the symbols for the two libraries then go through each symbol in one library and see if it is in the other library. A few seconds later I had the result: new_list existed in both libraries. A nice undescriptive function name. Looking in libwm I find that new_list makes a new playlist so I changed the function name to new_playlist, updated apps that use it, recompiled and tried out audiocd. Thankfully that was the solution as I had run out of time and had to leave for a movie.
Namespaces and audiocd
»
- icefox's blog
- Login or register to post comments
- 306 reads
Syndicate Blogs
GUI
Will the GUI be getting any TLC? I still find it rather awkward to use, and I suspect it's not as newbie-firendly as it could be.
John.
GUI
Yes, the GUI will also be getting a bunch of major work to it done. Of course a lot of the infrastructure is in audiocd so that is where the work is going to be first. Expect some cleanup for 3.5.
And?
Thinking about it a bit more, there's something to be said for merging KsCD and KAudioCreator?
merging
Yes in fact you could probably merge juk, kaudiocreator and kscd very nicley from the users per. That might happen, we will see.
Thanks!
Good news there on the GUI
While I can see Juk gaining CD Player and Ripper components, I think the CD Player needs to be left as lightweight as possible as it will possibly spend it's entire life loaded in the tray and we don't want to be accused of bloat
So just adding a ripper would be best from a usability point of view: user loads CD in tray, CD Player starts, user likes CD so just hits the Rip button, rather than stop Player, search in KDE menu for Ripper, etc, etc.
In fact, I've taken the liberty of whipping up a couple of quick (and incomplete) mock-ups of how I see it working
There's the Player in Minimal mode http://www.layt.net/john/CDPlayerMode.png and the Player with Ripper in Expanded mode http://www.layt.net/john/CDRipperMode.png .
Just some ideas off the top of my head, it's rather incomplete like where's the job queue gone?
Cheers!
John.
Ripper in KsCD
I don't see the need to embed the ripper into KsCD, given your suggestion.
All it takes is to add an easy way of launching KAudioCreator from KsCD.
Yeah...
Must admit, that thought occured to me halfway through doing the mock-up, but I was just enjoying myself too much to stop there
Easy way is to add a Rip button between CDDB and Extras which when pressed stops the CD playing and launches KAudioCreator.