From kde-multimedia Wed Sep 15 03:49:31 2004 From: Zack Rusin Date: Wed, 15 Sep 2004 03:49:31 +0000 To: kde-multimedia Subject: Re: kdemm backends & Helix Message-Id: <200409142349.31875.zack () kde ! org> X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109522048222406 On Tuesday 14 September 2004 22:14, Ryan Gammon wrote: > 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. I was planning to look into integrating Helix into KDE after I checkin the Mozilla code into their CVS. If you want to do that then we could help each other. I don't forsee this being more than two days of work. > 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. Hmm, this would be still equivalent of our QWidget binding. > For kdemm, one idea would be to use QCOM We don't use QCOM. > If QCOM's not popular there're other possibilites. Maybe KParts... Having a HelixKPart would be nice but largely for a different reason. Where KParts shine is in a per-mimetype environment, e.g. "hey, i have this url, can something handle it". Not a lot of people use the KParts streaming api. > 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/hxclientki >t/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. The thing is that we'll most probably need it either way. Anything that would display a video needs it. If we'll write a KPart we'll need a QWidget and we'll need it for the KDE::Multimedia::VideoPlayer. Essentially a nice way to start would be to have a QWidget with a set of basic interfaces for the client API. If we have a QWidget we're almost done :) > 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? This also wouldn't work all that well. You really want to have QWidget to have a little more intimate knowledge of what it's embedding to correctly handle resizing and layout. BTW, on Thursday I should be all day in the office, if you want to talk a little bit about this we can schedule a phone conference. Zack -- Sleep: A completely inadequate substitute for caffeine. _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia