[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: SmartWrappers => Object conversion done!
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-05-15 17:45:15
[Download RAW message or body]

   Hi!

On Mon, May 15, 2000 at 04:05:50PM +0100, Nicolas Brodu wrote:
> Stefan Westerfeld wrote:
> > True, thats my plan, too. There is some experimental video code in
> > kdemultimedia/noatun, by the way, which uses two special mcopidl options
> > to allow declaring VideoFrame streams. See avideoframe.cc/avideoframe.h.
> > 
> > To the PlayObjects <-> "Real streaming" issues: Of course having real
> > streaming is always better, that is putting data raw into a mp3 decoder
> > as asynchronous byte stream, and getting out the decoded data (maybe) as
> > byte stream, too.
> > 
> > PlayObjects are just the simple solution to have something that will
> > definitely work for KDE2.0, the "real solution" is splitting into smaller
> > components.
> > 
> > To the SynthModule inheritance: I think it should stay. A SynthModule is
> > a module that has the start()/stop() functionality which you will need
> > for all kinds of streams - its just the name that may be confusing a bit.
> 
> Of course it should stay... in C++!
> I mean that for the examples I posted, an interface is written as:
> interface MyInterface {
>     out audio stream gargle;
> };
> and does not inherit from SynthModule (which is now implicit since I declared a
> stream).
> It's just a matter of mcopidl adding a parent (SynthModule) when a stream is
> detected. The coder doesn't even need to know, as inheriting from the skel
> doesn't make SynthModule appear. That way, SynthModule is really internal, and
> the idl looks nicer. The start()/stop() functionality is viewed as something you
> get automatically when you declare a stream.
> 
> OK for this change?

I know that the temptation is big to let mcopidl generate everything sometimes,
where needed or if the phase of the moon is like this. We can do that, after
all. However, doing so excessively will make things very hard to understand.

I don't want methods popping up and disappearing at random. If they are not
declared in the interfaces, they are not supposed to be there. If you need
something sometimes but not always, then inheritance is the way to go.

How should a JavaScript binding know that there might be a stop() sometimes,
but not always? How should a user know, who only has read the IDL files (which
will be the source of documentation via kdoc)?

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]