JuK -> KDE CVS
wheeler at kde.org
Sat Mar 1 11:04:53 GMT 2003
On Friday 28 February 2003 19:31, Charles Samuels wrote:
> Wouldn't it make more sense to make it a noatun plugin?
Possibly. As I'm sure you recall I was the first one who pondered the
possibility of this in our conversation a few weeks back on IRC. We agreed
that Noatun's plugin API currently can't do what JuK needs and that you might
be willing to change this in the future. (more later in the email)
> Then you'd get effects, equalizer, visualization, and various plugins for
Well, in their current state these aren't useful in JuK. I need these to be
available as ordinary widgets that can be "plugged in" to the playlist GUI.
As far as I know this isn't currently possible.
And there is the issue that most people simply don't care, but well, that's
not terribly important.
> And we could implement plugin-profiles in noatun, create a [Kicker K-Menu]
> item just for JuK.
Nice idea. Again, I don't think this is currently possible.
> All of this while having the exact same UI.
Again, not currently possible. When it is, as I've said before, I'm open to
Now for some history:
First people have asked why JuK wasn't a Noatun plugin originally -- several
reasons -- JuK (then QTagger) and Noatun were started at about the same time.
Their first releases were about 2 months apart.
Then, when I started the port to KDE 3 (from pure Qt 2) there was constant
discussion on the lists and IRC about the plugin API in Noatun changing and
breaking the plugins, and you not fixing the plugins, but just disabling them
from compilation. (I remember discussions specifically with you, Rik and
Neil.) A year later I don't think all of the issues around those plugins have
been resolved and they're still not used. This was and is hardly encouraging
for a would be Notuan plugin developer. Surely you can understand this being
And onto the future:
As far as reuse, I've mentioned in the past that I'm more than willing to work
on things that will help Noatun. On IRC I've advocated both use of my
pending KFMI work and use of JuK's meta data caching and tag handling
structure in Noatun. Stefan specifically seemed interested in the latter and
both of you in the prior.
There are two ways that code sharing could be increased. The first would be
to create a libkdemultimedia where we can share components that could be
integrated into both apps. This would retain the unique applications and the
benefits of both, but make useful features possible in both without code
duplication. Currently there really isn't a significant amount of
duplication since most of JuK is analogous to a Noatun playlist and the
Player (and subclasses) in JuK are trivial (but structured differently as
JuK's was made intentionally abstract and small to make easy support for
other media backends).
The other option, as you suggest, would be to make JuK a Noatun playlist.
What I suggest here is a hybrid. I'm not convinced that this will work as a
solution to the jukbox problem, but I'm willing to entertain the possibility.
In the near-ish future, I would suggest having JuK build both a Noatun plugin
and a standalone app. This will provide a test case to see how well
completely moving in that direction would be possible. This is also
something that I've suggested to you and others in the past, so again,
nothing new here. And believe it or not, in some of my recent source code
restructuring, I've tried to decouple the components in JuK in such a way
that this could be easier.
I would suggest working on both of these since they're not mutually exclusive.
I'm still not sure that Noatun's plugin API can be mangled into something
useful for JuK in the short term (in a BC way), but that's your territory and
I'll leave that to you.
So, I don't see a clear "yes, this would make more sense" but rather some
steps that can be made starting soon that will make this an easier question
to answer, getting feedback all along the way.
The three chief virtues of a programmer are: laziness, impatience and hubris.
More information about the kde-core-devel