kdemm backends & Helix

[Zack Rusin]

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.