Fwd: Hayes

[Charles Samuels]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



I also reply to Carsten's email in full below Neil's email.  I'm pasting it 
from lists.kde.org (hint!)

This time I come off as /very/ hostile, and this time I'm not going to 
apologize for it.


On Tuesday 28 January 2003 6:35, Neil Stevens wrote:
> On Tuesday January 28, 2003 09:11, Carsten Pfeiffer wrote:
> > > 3. Hayes integrates with Konqueror (both allowing easy opening of a
> > > Konqueror window of a paricular music directory, and allowing easy
> > > playback in Hayes via a Konqueror service menu).  SPL does not.
> > > Charles suggests that there should be a way to disable the service
> > > menu when Hayes isn't on, and I agree, but that can only be fixed in
> > > Konqueror, not Hayes.
> >
> > This can be achieved easily by not using the ServiceMenu thing, but a
> > KonqPopupMenuPlugin. Simply check noatun's config-file to see if Hayes
> > is the playlist plugin or not.

Would be better to dcop-talk to noatun to check if it's loaded.

>
> Sounds good, bu I'm only going to bother to do something like this if Hayes
> is going to be in the release.  I've attempted to compromise with Charles
> before, only to be ignored in the end.

You're not motivating me by making blatantly false statements.  You too 
Carsten.

>
> > But please tell me that there is more to it than just the different
> > method name, otherwise one might think you'd be deliberately confusing
> > noatun users.
>
> There's a fundamental difference between Hayes, and the SPL that the Noatun
> Playlist API is designed for.  addFile takes a QString or a QStringList,

FUD. I'm getting fed up with this! Just how do I make it so that the Noatun 
API was designed for SPL?  Do you not understand the difference between an 
interface and an implementation?  Do you not understand that the API does not 
determine implementation?

That I *named* it addFile?  A rose by any ....
Or that I require properties?  YOU'RE FREE TO IMPLEMENT THAT ANY WAY AS LONG 
AS YOU DO.
Or maybe because I called it Playlist instead of PlayList?

> and adds the file to the playlist, and optionally plays it.  In Hayes, you
> can't just add a file.  Hayes obeys the filesystem, no more.
So then you should have suggested that I call it openFile, or playFile before 
we kept BC?

>
> So Hayes has its own, additional DCOP interface to provide access to
> Hayes-appropriate functionality.  Noatun's interface gives no way to play
> a file without adding it, so I gave Hayes a way.  This was added
> specifically to support the service menu.
>
> > > 5. Hayes has a better DCOP interface.  Charles hinted at this, that he
> > > can't be added to the other Noatun playlists without breaking binary
> > > compatibility.
> >
> > What about using signals or QCustomEvents for extensions without
> > breaking BC?
>
> That's up to Charles, again.  If he adds stuff, I'll add support for it if
> and only if Hayes is going to be in the release.  Other people have other
> wishes that are a higher priority for me, if Hayes won't be in the
> release.

class Playlist doesn't inherit from QObject (by design), so no go.


>
> > If some people really can't agree on a technical solution, then I think
> > someone else (i.e. neither the app nor the plugin maintainer) should be
> > the judge. That would be the CVS module maintainer or as last resort the
> > release dude.
>
> Well, I don't see how Hayes having an additional DCOP interface would meet
> the standard of making the app "stable or less functional," so the fact
> that Hayes adds its own DCOP interface shouldn't be a valid reason to
> exclude the plugin.
That has nothing to do with the fact that Hayes doesn't conform to the noatun 
API.

>
> > E.g. in this example, the missing properties-support is IMHO no reason
> > to disable Hayes (I personally don't listen to shoutcast and I don't
> > have those mentioned plugins that rely on properties -- they are not
> > even in CVS).
>
> Right.  I'll clarify something though:  Hayes *does* provide an interface
> for Noatun plugins to read KFMI information.  So other plugins can *read*
(space here for effect)

> the data, they just can't write their own new data.
<reverb>THAT'S EXACTLY THE POINT</reverb>


Hey, keep reading!


Carsten wrote:

> (I just joined the list after reading lists.kde.org, forgive me for breaking 
> the threading)

> > 3. Hayes integrates with Konqueror (both allowing easy opening of a 
> > Konqueror window of a paricular music directory, and allowing easy 
> > playback in Hayes via a Konqueror service menu).  SPL does not.  Charles 
> > suggests that there should be a way to disable the service menu when Hayes 
> > isn't on, and I agree, but that can only be fixed in Konqueror, not Hayes.

> This can be achieved easily by not using the ServiceMenu thing, but a 
> KonqPopupMenuPlugin. Simply check noatun's config-file to see if Hayes is 
> the playlist plugin or not.

See my reply to Neil

> But please tell me that there is more to it than just the different method 
> name, otherwise one might think you'd be deliberately confusing noatun
> users.

Ahem.

> > 5. Hayes has a better DCOP interface.  Charles hinted at this, that he  
> > can't be added to the other Noatun playlists without breaking binary 
> > compatibility.

> What about using signals or QCustomEvents for extensions without breaking
> BC?

See my reply to Neil

> If some people really can't agree on a technical solution, then I think 
> someone else (i.e. neither the app nor the plugin maintainer) should be the 
> judge. That would be the CVS module maintainer or as last resort the release 
> dude.

> E.g. in this example, the missing properties-support is IMHO no reason to 
> disable Hayes (I personally don't listen to shoutcast and I don't have those 
> mentioned plugins that rely on properties -- they are not even in CVS).

Here we go!  That's great, perfect entrance.  HOW ABOUT YOU READ MY MAILS? HOW 
ABOUT YOU KNOW WHAT YOU'RE TALKING ABOUT?

Neil claims that that the playlist api is designed specifically for SPL, yet 
he doesn't implement properties because he doesn't.  And he thinks they 
should be removed from the API!  That's because he (and you, Carsten) don't 
even listen to shoutcast, that would make Noatun /less/ versatile and /more/ 
suited specifically to Hayes.  What use is the Properties feature if the 
authors of plugins cannot expect for them to work, as they are documented to 
be?


Read this as many times as it takes Neil, Carsten.  I'm fed up with constantly 
having to repeat the same things to you.  It's no coincidence that the only 
people who think that Hayes belongs in CVS despite these flaws are the ones 
who use Hayes.  Those are the people who don't ever use shoutcast, or never 
use the Flood plugin, or the Smoove plugin, or any of the plugins that show 
exactly how versatile this api is.

- -Charles

- -- 
Charles Samuels <charles@kde.org>
"Pacifism implies quite a bit of wisdom" -- Maksim Orlovich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+N0zxWS4Pv66UcxkRAhddAKDZE4iMg/YLK9wFlW5tr9382HnKKACcCsky
pFmUam9n2+r/NX4+djuYRk8=
=agzG
-----END PGP SIGNATURE-----