GStreamer on freedesktop
George
jirka at 5z.com
Wed Dec 10 04:58:46 EET 2003
On Wed, Dec 10, 2003 at 02:54:20AM +0100, Scott Wheeler wrote:
> Sure -- KDE and GObject use different event loops, you have to build something
> to mitigate between them. The object model is native to GNOME; it's not to
> KDE. There's a learning curve there and it's one that KDE people don't get
> terribly excited about. For the GNOME folks again, it's native.
>
> So -- again, it's clear that something like GStreamer is a "tighter" fit with
> GNOME. They're made of the same building blocks in a sense. Now on to the
> KDE bit...
You will always have any implementation either a tighter fit with project A
or with project B. Such is life. On the other hand, it seems that it's not
terribly hard to make nice C++ bindings (meaning native C++ objects) for
GObject. Much better then for many other OO frameworks in C. Also if we
want interoperability (which would most definately be good for something such
as the media framework, then it'd be just much easier to use a common
implementation. Plugins will only need to be written once, etc... all that
other interoperability goodness. So perhaps it would be good to have a KDE
person then try to figure out how to make GStreamer fit "tighter" with KDE.
Surely the interface can be done to be completely nicely KDE/C++/Qt like,
such that the developper using it wouldn't know the difference. I mean it's
the interface that counts, not the implementation. If I call 'stat', it's
really just a wrapper around the system call which is a wrapper around things
in the kernel that go through the vfs stuff to the actual filesystem and it's
all most likely incredibly evil code I never want to see.
Wrappers/abstractions are good. Shouldn't it be possible for
GStreamer<->KDE?
George
--
George <jirka at 5z.com>
She had lost the art of conversation,
but not, unfortunately, the power of speech.
-- George Bernard Shaw
More information about the xdg
mailing list