[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: Engines [was: Re: extragear/multimedia/amarok/src]
From:       Mark Kretschmann <markey () web ! de>
Date:       2006-03-02 20:58:19
Message-ID: 200603022343.58083.markey () web ! de
[Download RAW message or body]

Paul, I think Gabor wasn't referring to the Helix engine, but to the wrapper 
hack which SUSE deployed for making it work on 64bit. That one was crappy 
indeed.

On Thursday 02 March 2006 21:45, paulc2@optonline.net wrote:
> Hey!  Gabor, take it easy.  It's one thing to put down Real, but I wrote
> "Crappy-Helix-Wrapper", and it's not so crappy, and hardly a wrapper.
>
> Quoting Gábor Lehel <illissius@gmail.com>:
> > On 3/2/06, Mark Kretschmann <markey@web.de> wrote:
> >> On Thursday 02 March 2006 18:37, Gábor Lehel wrote:
> >> > On 3/2/06, Mark Kretschmann <markey@web.de> wrote:
> >> > > On Thursday 02 March 2006 17:20, Gábor Lehel wrote:
> >> > > > On 3/2/06, Mark Kretschmann <markey@web.de> wrote:
> >> > > > > SVN commit 515075 by markey:
> >> > > > >
> >> > > > > * Speed up starting remote streams by skipping the mimetype
> >>
> >> detection
> >>
> >> > > > > and playRemote() for engines that handle streaming internally
> >> > > > > (all except aRts and gst-0.8). * This also fixes a possible
> >>
> >> freezing issue
> >>
> >> > > > > when a server doesn't respond before starting a new remote
> >> > > > > stream.
> >> > > > >
> >> > > > > TODO: I would like to get rid of playRemote() and the
> >> > > > > StreamProvider altogether. This would imply removal of all
> >> > > > > engines relying on this feature, namely aRts and gst-0.8.
> >> > > >
> >> > > > Um, that seems rather drastic. Just disable streaming for them,
> >> > > > no? (if anything)
> >> > >
> >> > > And by the way, I'm not sure if you missed the discussion, but we
> >> > > were also considering to disable all unmaintained/incomplete engines
> >> > > for 1.4. This would currently leave us with xine, Helix and NMM.
> >> >
> >> > Hmm. What does "disable" mean? Ideally, I think, only the maintained
> >> > and stable engines should be shipped by default (I'm hoping gst 0.10
> >> > can also reach this state by 1.4 final), but if someone wants to
> >> > install one of the others manually, we shouldn't stop them. (Much as
> >> > it boggles me, I've heard of multiple cases where the only engine
> >> > which worked for someone was arts.)
> >>
> >> Don't you realize that the engine system in its current incarnation is a
> >> usability and especially support nightmare? You're correct that distros
> >> can choose to only ship mature engines; but selecting these engines is
> >> already hard for the packager. In the past distros have already made bad
> >> choices here
> >> (remember the SUSE/aKode debacle).
> >>
> >> Now, for the end user who compiles amaroK from source (many users build
> >> from source), there's no way to figure out which engine is really usable
> >> and which
> >> isn't, apart from the bit of information that we provide in the README.
> >> At this point we have 9 engines; some of them haven't been maintained
> >> for years,
> >> others are incomplete or plain broken. About every second support
> >> question on
> >> IRC has to be answered with: "Choose another engine! Use xine or helix
> >> engine."
> >>
> >> This can't be good. That's why I'm thinking it would be good to disable
> >> (set the plugin rank to 0) these unmaintained engines. Another technical
> >> solution could be to show a warning dialog when such an engine is being
> >> loaded, warning the user about the experimental nature. Alas, this isn't
> >> yet implemented; we currently just have a "EXPERIMENTAL" plugin flag,
> >> but no GUI for this.
> >>
> >> I guess my point is that we need to make amaroK safer and easier to use
> >> for the end user. Bad engines are just another possible point of
> >> failure, and it's just not nice (and not necessary) to see a user
> >> getting frustrated with the app, just because he/she is not an expert in
> >> multimedia libraries and happens to choose the wrong backend.
> >
> > Sure I realize. I agree with the ends, just not the means.
> > Goals:
> > - let the user have sensible engine(s) installed by default
> > - let the user install any of the other engines if (s)he so chooses
> >
> > Now I don't know how we currently try to convince packagers to acheive
> > this, but options I can see are:
> > - telling them so in a PACKAGERS file or similar (basically: make sure
> > amaroK is installed with only good engines by default, and at least
> > one of them)
> > - disabling compilation of additional engines even if configure
> > detects the necessary libs are available; so you have to manually
> > --enable-engine to compile it.
> > - removing the extra engines from extragear/multimedia/amarok and
> > putting them in a seperate extragear/multimedia/amarok-extra-engines
> > module (or even in playground).
> >
> > Now if a distro is hellbent on buggering amaroK with a bad engine
> > (like SuSE/aKode, or SuSE/KDEM2M-KDE3-backport, or
> > SuSE/Crappy-Helix-Wrapper, or if we were Kaffeine -- Kubuntu/GStreamer
> > (thankfully our gst engine doesn't suck)), as opposed to buggering it
> > unintentionally out of ignorance or laziness, I'm not sure even
> > setting the plugin rank to 0 would be capable of deterring them.
> > They'll just edit the plugin file and change it back.
> >
> > --
> > Work is punishment for failing to procrastinate effectively.
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.

-- 
Mark

[prev in list] [next in list] [prev in thread] [next in thread]