What's new
KIO Zen did always scan the upload archive the first time "::upload" was selected after startup. With large archives this took
quite some time. With no changes made to the archive this is very annoying. KIO Zen uses a cache file, now. However changes to the
archive from any software other than KIO Zen are not detected. You have to reload explicitly.
The playback on device feature is still waiting for libnjb to supply a stable API.
September 28th, 2005 Oliver Eichler
Old
Nothing really new with the latest release. It is just because libnjb moved to version 2.2. As the API changes, I had to make
a new release.
June 30th, 2005 Oliver Eichler
Old
The major change of release 1.1.1a is the toggle switch for the artist filter when using the album view. As discussed there are
two ways to organize albums with several artists involved. The one is to name the artists field various and add the artist name to the
track name. The other one make use of the artists field. For the first kind the album view will produce correct output with artist
filter. For the later one the artist filter has to be switched off. Users prefering the second method most likely prefere the album
view as the artists view would split up the album into several artists. Thus I had to add the album view to the upload section.
KIO Zen switches from libnjb 2.0 to libnjb 2.1. This enables to read out the battery status.
I changed to UI flow with upload, download and delete dialogs. The old behaviour redirected you to the main page at the end of
a job. The new behaviour will bring you back to the page the job was initiated from.
June 27th, 2005 Oliver Eichler
Old
KIO Zen reached finally version 1.0.0. There has been no real bug since the alpha 2 release. However KIO Zen is now aware of
playlists in the respect of removeing tracks from a playlist when they are deleted
Future Plans
I will intergrate the battery status feature provided by libnjb-2.1. I would like to add a simple player control for playback.
First experiments revealed that libnjb does not really handle the current tracks playlist. I will only add this feature if I find
a clean solution. There are also two ways to sort the album list. The one is taking the artist into account. This will display
albums with equal names (current). The other one will not compare artists. This will fail with equal album names, but it will
group albums with several artists correctly. I will make this an option.
June 7th, 2005 Oliver Eichler
Old
I added the item '::other' to the upload menu. This allows a quick upload from a temporary location like a memory stick or similar.
Now all transactions start with an intermediate step, listing all selected tracks. You can cancel or go on.
If some tracks were missing in you upload view, this was due to a bad track length calculation. I had a look at the Gnomad2 project
and use their track length calculation, now.
I and probably you, too, experienced random device stalls during access. I crosschecked the code with the Gnomad2 project. There was
only one difference: The Gnomad2 project commented out the NJB_Ping() function, saying that it caused problems. I did so, too. Sofar
I had no problems anymore. However I garnished the code with a lot of kdDebug() messages on id 7142. Thus if you can reproduce stalls
would you please send me the log?
May 10th, 2005 Oliver Eichler
Old
I moved the track lists into iframes. This will help with long lists as the menu is static and the list will scroll to the active
entry.
There was a dead lock when starting any transfer action without device. This is because of the message box questioning for a device.
As the box is called within a thread by these actions, it will block due to missing thread safeness of the QT library. I bypassed this
by implementing a HTML message box mechanism. However this does not work without threads. Thus depending on the action a KMessageBox will
be displayed or a HTML dialog. Still a bad design.
When downloading tracks from the device I use the settings by kcmaudiocdrc. As far as you do not use 'year' and 'genre'.
May 3rd, 2005 Oliver Eichler
Old
The new version fixes all caveats from version 0.1.0 by introducing the knjbd daemon. The daemon is a unique KDE application without a
GUI. It is started by the KIO slave if needed. It will live in memory until the KDE session shuts down. Multiple slaves can connect via
DCOP. This solves all caveats of the earlier versions.
Additionally I introduced an optional track cache to speed up page loading.
April 22th, 2005 Oliver Eichler
Old
Basically KIO Zen is a KDE IO Slave. However it does not follow the intended design scheme of the KDE team to handle simple
input and output primitives and let the host application (Konqueror) do the rest. It is not just a slave, it's an application
itself. It handles complex jobs like ripping a CD via audiocd protocol and uploading the files to the device.
If it wouldn't be for the great simplicity of the KIO API, I would have been better off with a standalone application
and a http server extension. However KDE offers everything I need: An own protocol specifier making a target address / port
unnecessary. KDE will start the application upon request and shut it down after some idle time. No messing around with sockets and stuff
like that.
No light without shadow. As what I am doing is not intended by the KDE developers, there are some caveats. I will discuss them here
in request for some ideas on how to solve them in futur versions of KIO Zen.
About slave mastering slave
KIO Zen makes use of the audiocd slave to rip a CD and convert the tracks into MP3. Thus it has to be an application and has to
enter the application's event queue each time it uses another slave. This will be a blocking call until the job's finish signal will
make it quit the eventloop, again. For short tasks, like getting a file list, this is ok. Ripping a CD would block for several minutes.
This would stall the HTML interface. I decided to place these calls into a thread, entering the eventloop within the thread. From
my understanding of the underlying QT API this should be ok, as long as no other thread does the same. A better solution would be
to couple the slave's internal loop with the application's loop. As far as I am concerned this would need a change in KDE's KIO API.
About using dialogs
As a KIO slave is not intended to have a GUI, using dialogs seems a bad idea. The slave is able to display simple message dialogs
via the SlaveBase API. Everything else is up the application using the slave. KIO Zen does need several dialogs for configuration.
Of course one could use forms to create these dialogs. I don't like this, as it ends up in loads of javascript stuff just to get a
select-a-directory dialog. As I have to use a KApplication instead of KInstance anyway, I decided to enable the GUI flag. With that
my slave can display dialogs. The disadvantage: The dialog is not always placed on top of Konqueror.
About using unique applications
Placing the lengthy tasks into threads, makes it necessary to poll for the tasks status. No problem on the first sight. However kdeinit
will spawn several instances of the slave. But just one will report the correct status of the started task. I solved this by making KIO
Zen a unique application. This will result into failing requests if several competing requests are occuring. Not that I recommend to go
berserk with your mouse while uploading files... but receiving error messages is not what a user anticipates.
About the future
Nice you made it up to this point :)! To solve a good load of the problems, it is necessary to transfer the intelligence into
a standalone daemon running constantly in the background. The daemon can be addressed via unix domain socket, DCOP(?) or similar. With
that the KIO slave is just used as a relay between the browser and the daemon. This makes all event loop and runtime access lamentation
superfluous. As I never messed around with the KDE API before, I would be grateful if someone could give me the pointers on how to
integrate this nicely into KDE.
April 7th, 2005 Oliver Eichler
