Matthias Kretz wrote: >On Tuesday 14 September 2004 20:25, Ryan Gammon wrote: > > >>A couple of quick questions: >>1. Is anyone interested in a helix-based implementation of these >>interfaces? (helixcommunity.org, helix client is the open-source media >>engine that powers the RealPlayer). >> >> > >I am. And I'm all for including it in kdemultimedia. I won't be the person >implementing it, though. > > Sure :) The interfaces as they stand right now don't look like they're something that's going to be too difficult to develop. I'm sure I could take a stab at the basics it when I have some spare time. >>2. I'm a little confused by channels -- if there's something someone can >>point me at that talks a bit about what this is, it'd be much appreciated. >> >> > >The Channel interface is not finished. It's pretty much a placeholder >currently for an idea of Dik Takken (look at his mails to kde-multimedia - >and the one to kde-core-devel if you want to know all the details). But >basically it's a means of making apps use more advanced features of the media >backend without the app actually knowing. So you could define a Channel that >would send the audio through some effects before playing to the soundcard. Or >another one that would send the data to a file or another computer. > > Ok, makes sense. From a different point of view, a channel is kind of a bunch of settings for the media engine (volume, equalizer settings, reverb, brightness, hue, device/computer name, etc.) >>3. If one wanted to provide access to extended media engine >>functionality with these interfaces, how would they go about doing it? >> >> > >The idea currently is: "not at all". All the interface provides is the name >and some general info on the backend kdemm would use. If an app wants more >than the simple API in kdemm it's supposed to use the backend framework >directly and don't mess with kdemm at all (of course it's not disallowed to >do, but it's probably not a good idea). > > Ok. >>For example, we developed a simplifed gtk widget around the Helix Player >>for our Helix Player 1.0 / RealPlayer 10 for linux project. There's a >>lot of media engine functionality that we didn't want to add to the gtk >>api -- we wanted to keep it simple -- so we added a mechanism to get at >>the underlying engine. >> >> > >And how do you do that? Thinking of kdemm that would mean installing a lib for >all backends that can then be used at compile time by apps? Isn't just using >the backend's API directly enough? > > The "how" in our gtk widget case is that we created methods in our widget wrapper that provide access to the underlying IUnknown's for the COM-based client engine. Using those IUnknown's, one can navigate through the various components that make up the underlying engine, tweaking the advanced functionality as required. For kdemm, one idea would be to use QCOM (http://doc.trolltech.com/3.0/component.html). I'm not sure how much QCOM is actually used in kde, if at all, but if it's viable, one could: - add a getUnknown() method to KDE::Multimedia::Player that returns a QUnknownInterface - most apps use the basic KDE::Multimedia::Player api - apps that want/need advanced engine functionality can QueryInterface for back-end specific extensions - apps need header files for the interface definitions for those extensions, but don't actually have to link directly to the back-end. If QCOM's not popular there're other possibilites. Maybe KParts... I think I understand your original point here though -- why use a generalized framework with various backends, and then turn around and link directly to the underlying backend for specific functionality, thus tying the app to that specific backend. Why not use the specific backend to start with? Well, we have something for people who want to develop against helix as a specific backend called hxclientkit. https://player.helixcommunity.org/nonav/2004/developer/doc/hxclientkit/HXClient.htm It's a C api. You pass in an XID and a display, and you're set. If people want to take that and create a KDE player, awesome. One could even create a QWidget-derived widget around that base, and have a first class qt widget. I think, though, that the api you guys are developing is going to be wildly popular. It's simple, it's developed with kde in mind, it will be part of the kde platform and will meet the play-stop-pause needs of 90% of the apps. With a way of handling extensions, it could handle the needs of 100% of kde apps. There'd then be no need for the hypothetical QWidget-derived widget thing, and the poor linux multimedia application developer is saved from grokking yet another multimedia api. The KDE platform gives him everything he needs to get up and running, multimedia included. Does this make sense? Would people rather see a "class HelixVideoPlayer : public QWidget" layer that a player has to use directly, or something that implements KDE::Multimedia::Player and provides extensions for anything outside of that basic API? Would anyone use a HelixVideoPlayer instead of KDE::Multimedia::Player? >>Let's say I wanted to make playback statistics (packet loss, etc) >>available to an app, but that statistics was not something that was >>standardized enough across backends that it made sense for kdemm. >> >>Would I implement those methods on a hypothetical HelixVideoPlayer >>class, and cast from a VideoPlayer up to a HelixVideoPlayer in my app? >> >> > >One could do that, but I don't think it's a good idea. What would be better >IMHO is to have Qt/KDE bindings (meaning C++ with Qt/KDE APIs) for the >framework. > > Bindings are a cool idea, but not something I'd really sign up for in my spare time :) -- not only are there a lot interfaces to cover in the Helix Client, there'd be some ongoing work there to keep the bindings up to date as new COM interfaces are added to expose new functionality. -- Ryan Gammon rgammon@real.com Developer for Helix Player https://player.helixcommunity.org _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia