On Monday 24 February 2003 20:10, Havoc Pennington wrote: > Well, I don't know anything about multimedia, but hopefully the above > is useful information about GLib policies/intentions. GLib in itself is not the problem. I and many others KDE developers enjoy it and it's already used in ARTS (see arts/gmcop). The issue arise due to the fact that GStreamer object system is based on GObject which doesn't naturally fit into Qt object system. People are in general afraid of GObject ( by the way you should make Mathieu Lacage maintain his GObject docs in glib cvs not on his website :p ) People are afraid that this would give Gnome an unfair edge ("hey, KDE is super bloated and confusing because it has two object systems and to code in KDE one has to learn Gnome and KDE"). These theories are of course fallacies and we need to get to the bottom of those and make sure everyone understands that this is simply not true. ( it's enough to look at Scotts JuK which uses Tim's GStreamer bindings to see that ). [ Havoc you can end reading right here if you want to save time ;) ] I think the problem is that although we bring up different frameworks ( by the way Tim http://www.networkmultimedia.org seems to be very well designed. I just started reading their docs and I'm fairly impressed ) we still haven't specified what we are exactly looking for. So at this point I'd like to propose to do the following : - create a complete and comprehensive list of futures we are looking for (low latency? easy of integration with our object system? ... ). What are our needs? Anyone wants to start? - a person who wants to propose a framework will do analysis of it based on the above list. That will immediately tell us which frameworks are better suited for our needs. Comments? Zack -- Notice: Your mouse has been moved. Windows will now restart so this change can take effect. _______________________________________________ kde-multimedia mailing list kde-multimedia@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-multimedia