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

List:       kde-multimedia
Subject:    Re: Easy MCOP! The Component extension proposal.
From:       Nicolas Brodu <nicolas.brodu () free ! fr>
Date:       2000-03-06 12:04:26
[Download RAW message or body]

Stefan Westerfeld wrote:
> 
> > Here we go. First the motivation. If you look at the testflow examples, you'll
> > notice that each module definition is about 15 lines, and contains 95% of
> > administrative code (i.e. code just there to set up things).
> 
> That is right. However, consider this the API for the visual artsbuilder,
> which you can use to build flow graphs "without" C++ API. The essential
> idea is, that artsbuilder will never be able to directly write things like
> 
>   mixer->setInputLevel(1,0.14);


This isn't intended for artsbuilder (see below)

> 
> because it doesn't even know that there is a mixer. Rather, all objects
> should have so much meta information that they describe themselves. Arts-
> builder then can provide a property editor for objects that he doesn't
> know. Similar to the way Delphi for instance provides the ability to put
> together all objects, without knowing how they work or even knowing their
> existence at the time Delphi was written.

I perfectly understood this point, and that's why I meant by saying "My goal is
to keep all the MCOP features". It's just that it would IMHO be a very bad idea
to impose programming MCOP-aware apps only through artsbuiler. Imagine I write a
module for xmms that is MCOP aware, just because I want xmms to be compatible
with artsd. I just want to use a programming API, and at present this imply
learning many concepts and having a good knowledge of how things work
internally. People will use MCOP in their own existing (i.e. not artsbuilted)
apps only if it's really easy to use.

> Qt doesn't have this, but they are working hard on making this work soon,
> as I can see from their new Qt-2.1 property inventions.

Granted, but it will still be possible to use their existing excellent API.
I mentionned VTK on my previous mail because they had this problem. The
Visualisation ToolKit is designed for scientific visualisation, and use many
components, which outputs you can feed to other components inputs to create a
visualisation pipeline. They had this problem exactly, and decided to create a
good API and not a visual builder. Since it's that good, they could easily port
it to tcl, java, python...
My point there

To sum it up, graphic design with artsbuilder is very good if you want minimum
programming, but people might want to program directly for many reasons and it
will help extending MCOP.

> For MCOP these things will work in conjunction with the InterfaceRepository.
> You can go do any object and ask: hey. What properties do you have. What
> streams? What methods? What are the parameter names? How do the involved
> structures look like? This is what artsbuilder will be able to use to
> configure/connect/combine objects without knowing them.

That is all very good and should of course be kept. But for someone who already
know what he/she wants, and program directly without artsbuilder, 
I guess just declaring 'MP3Reader mp3("mysong.mp3");' is much better than asking
for the properties, methods... etc.. and then invoking them.
If you wish, you'll still be able get the 'mp3' object reference, send it over
the internet, and remotely ask its properties, methods, etc. It's just that many
apps won't do it.

> First of all, here is the current testflowcxx.cc. I couldn't go to bed
> without having a better example in the CVS ;).
> 

:-) Much better already. Thank you for all the details you wrote in this mail.
I'll come back to you when I've digested all that, with more comments/ideas.

> I haven't understand what code exactly you generate and how components
> and interfaces differ, I'm sorry.

They don't differ, that's the trick! It just tells mcopidl to generate in
addition some administrative code to make the use of the component very easy.
I also use it to rename the object names:
MyObject      => MyObject_base
MyObject_skel => MyObject_skel
MyObject_stub => MyObject_stub
MyObject_var  => MyObject_var
MyObject_impl => MyObject

So now MyObject is really what you expect when you use it.
Hence the MP3Reader mp3("mysong.mp3");
Of course, I had to fix reference counting and many other internal things, and
I guess there's still a few problems.

> 
> Ok, my reply was even longer than your message ;-) - byte streams are
> possible asynchronously, and artscat for instance uses them.

All right, I'll have a look.

> Hope to hear from you soon - as you see your mail did already improve things ;)

The whole point!

Just let me some time to understand more what happens internally.

Cheers,
Nicolas
-- 
A shortcut is the longest distance between two points. (unknown author)

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