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

List:       kde-multimedia
Subject:    Re: Media Options for KDE 4
From:       Neil Stevens <neil () qualityassistant ! com>
Date:       2003-02-24 21:44:18
[Download RAW message or body]

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

On Monday February 24, 2003 01:05, Scott Wheeler wrote:
> On Monday 24 February 2003 21:30, Neil Stevens wrote:
> > > If you're talking about extending the system, well I don't think
> > > that's a fair requirement or one that's applied elsewhere in KDE. 
> > > i.e. We don't require X extensions to be comprehensible to average
> > > KDE developers, yet obviously this is accessible to some...
> >
> > Yes, I am talking about extending the system.  If it's not possible to
> > extend the system without glib, then this "wrapper" idea is probably
> > too limited to be sufficient.
>
> Ok, so let's run with this a bit:
>
> There *are* many parts of KDE where there is knowledge required
> significantly above basic C++, KDE, Qt programming.  Hell, aRts is dang
> hard and significantly beyond what most simple multimedia developer need
> to know. 

I agree, and I did hold the non-KDE-ness of aRts against it at the top of 
this thread, did I not?  I'm giving aRts no special favors for KDE 4.  
Actually, probably the only reason any of us even bring up aRts is becuase 
we're already significantly invested in it.

> I think it's fair to assume that whatever we choose as a
> backend will require some knowledge, for the backend implementors,
> beyond "normal" KDE development skills.

No, it's not fair to assume that.  If KDE can't work on the system KDE 
picks, then KDE is at the mercy of the developers.  We don't want another 
aRts situation, where we have 100 complainers and 10 developers.  Picking 
a system that requires no special knowledge for devleopment helps avoid 
that.

> First, many of us are competent C programmers.  While it would be nice
> to have something that was all nice, clean, intuitive, Qt based, C++,
> being pragmatic, it makes more sense in my opinion to concede that much
> is what is available is C based and such is not *that* bad.

Good for you and your C programming.  C is not the language KDE uses, 
though.  This is not the time to try to make KDE multi-lingual, though.

> Second, glib *is* becoming a standard toolkit for C programming on Free
> operating systems.  I'd personally consider knowing glib more useful and
> reusable than say, knowing aRts.  And there are several people on this
> list that do know glib (Tim, Stefan, Guillaume come to mind).  There are
> probably at least as many that know glib as know aRts.

Irrelevant.  KDE isn't even tied to free OSes.  Personally I don't think we 
should care about porting to proprietary OSes, but it's not the place of 
kde-multimedia to dictate that policy on all of KDE.

And this is treading very close to the Qt-bashing that's hounded KDE for 
KDE's whole life.

> And I don't mean this as a slam on aRts -- again -- I'm not sold on
> GStreamer or any other solution at the moment.  I just don't yet
> understand why a glib dependancy for *extending* the multimedia system
> is not acceptable, or in fact more than we demand now in terms of
> counter-intuitiveness.  Again, I think we require this type of specific
> knowledge in many areas.  More kde devels knowing glib might even open
> up the door for further code sharing between Gnome and KDE, which at
> least at a fairly low level like this, I think would be a good thing.

It's not acceptable becuase it's different from the entire rest of KDE.  
KDE multimedia systems are not a world to their own.  We're not to be less 
portable than the rest of KDE, less consistent than the rest of KDE, or 
anything of the sort.  Any KDE apps hould be able to use KDE multimedia 
resources.  Throwing up some out-of-the-blue C library requirement greatly 
hinders that.

Oh, while I'm thinking of it, does glib guarantee binary compatibility for 
the lengths of time that a major KDE version lasts?

> > Oh sure.. they were very cooperative with me when I asked about it
> > when considering video options for KDE 3.1.  It's from them that I
> > found that GStreamer is tightly bound to glib.
> >
> > Please don't make this out to be a personal thing.  It's purely
> > technical. Purely on merit.
>
> Oh, no.  I just meant this in the "they're motivated, active and
> helpful" category.

But be careful not to imply that I'm attacking them personally, when I say 
that their framework isn't necessarily right for KDE, please.

thanks,

- -- 
Neil Stevens - neil@qualityassistant.com
"Distinctions by race are so evil, so arbitrary and insidious that a
state bound to defend the equal protection of the laws must not allow
them in any public sphere." -- Thurgood Marshall
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+WpIyf7mnligQOmERAmNEAJ0X7z/2UIZQmHmxmKtt5pVMoChXFQCfdOxM
qEJ0ais1GSAU9wdqwE+hYvE=
=SAfS
-----END PGP SIGNATURE-----

_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]