Fwd: Hayes

[Carsten Pfeiffer]

-----BEGIN PGP SIGNED MESSAGE-----

On Wednesday 29 January 2003 04:39, Charles Samuels wrote:

> > 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?

I'm not sure what the semantics of that method should be (just play it or put 
it persistently into the list?), but both should be possible to implement 
with Hayes as well. You might copy the file into Hayes' directory, if 
possible or simply keep an extra directory with symlinks to those files.

Actually, I'm wondering if this is the reason why it was impossible play a 
file when noatun (w/ hayes) was already running and you click on an mp3 in 
konqueror. It never played the clicked file for me.

> > > What about using signals or QCustomEvents for extensions without
> > > breaking BC?
[...]
> class Playlist doesn't inherit from QObject (by design), so no go.

Why does this need to be in Playlist?

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

I tried to leave the technical level, looking for a solution for the general 
problem (hence the beginning of the sentence).

> > 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?

An independent judge has to weigh the pros and cons. I.e. whether the 
functionality provided by Hayes weighs up the missing properties 
implementation. And IMHO it does, for many users. Especially if there doesn't 
seem to be any plugin using those properties in CVS. And even more as Hayes 
itself is optional.

I don't want to reject the usefulness of those properties, I just think that 
they are IMHO not a sufficient reason to exclude Hayes from distribution.

And if I read you correctly (yes, I do read, but usually only properly capsed 
text), you reached agreement with Neil to implement properties support.

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

Well, you hit the point exactly! I and I think many other people don't care 
about shoutcast, but I care about a playlist that I don't have to update all 
the time when I get new songs. 

So for me, Hayes provides more value than another playlist that offers a 
feature that I never use. And I don't see why KDE shouldn't distribute that 
value.

But what are we arguing, if Hayes is going to support properties anyway?
Apparently this could have been discussed on a technical level on 
kde-multimedia, no?

Cheers
Carsten Pfeiffer
-----BEGIN PGP SIGNATURE-----

iQEVAwUBPjfgTaWgYMJuwmZtAQEHPAf+Jhaq6zb4gy6EC3B4CBe77t64il/ngSW4
b3EnETpVsG5zt2Ti9KLv7hDZdbD5zfbmgUc00AbPBBNKS91FfHqTgy4Wva6H73Ig
oHGfEofNg46+zPchKkfrhXp9S0cZfmjbYC8Da5p0yT0c+03e26hxOyRNtdudX+c9
ePwExTtXtlM8G5NuRtv9JQFKn/VlERXTfe6QPHCNaN60fkJSRv9AsVDHC1IDD7Tu
/vJuiFe84TdcKfMta7zjpPPXMTo2rIvyZ1FMQwPhGuSg6fiXfHuFoAHxnRl1j/su
9T1Ihzk/OCLiSMj9q/nlsmWEAZNlAECA7g98fNZPR41ujTDg6Tp0LA==
=o6Xd
-----END PGP SIGNATURE-----