JuK -> KDE CVS

[Scott Wheeler]

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 
> free.

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 
this possibility.

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 
somewhat discouraging.

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.

Cheers,

-Scott

-- 
The three chief virtues of a programmer are: laziness, impatience and hubris.
--Larry Wall