From kde-multimedia Mon May 15 17:45:15 2000 From: Stefan Westerfeld Date: Mon, 15 May 2000 17:45:15 +0000 To: kde-multimedia Subject: Re: SmartWrappers => Object conversion done! X-MARC-Message: https://marc.info/?l=kde-multimedia&m=95841290631337 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