Hi!

On Thu, Mar 16, 2000 at 10:43:35PM +0000, Nicolas Brodu wrote:
> It's there, in the KDE CVS.

Please check that things still compile/work before commiting to the CVS.
Some stuff in kdemultimedia is broken currently, as the code wasn't using
the new API yet.

I've hopefully fixed most stuff by now.

> Look at the examples hellomain, flow and x11comtest to have an idea of what it
> looks like. Older examples are still there, to show the necessary _base addition
> when using this kind of code.

Currently, some stuff feels a bit unconfortable. We should see if we can get
these things out of the way or whether the new C++ api can be adapted in a
way that these issues disappear. (Or move the new api to a not-that-central
place).

* Member objects and new style C++ api:

  I am not quite sure how to handle things like this cleanly:

  /* old code */

  class SomeObject {
    StereoEffect_var effect;
    SomeObject()
    {
      /* creates effect here remotely */
	}
  };

  /* new code (?) */

  class SomeObject {
    StereoEffect effect;

	/* this is not that nice, but if we don't do so, we get auto-creation */
	SomeObject() : effect(Reference::null())
	{
	  /* create effect remotely here? */
	}
  };

* Passing of parameters

  /* idl code */
  Foo foo(Foo foo);

  maps to

  Foo_base *foo(Foo_base *foo);

  I am not quite sure, but people will certainly be really confused about

  - when to use Foo_base *x;
  - when to use Foo_var x;
  - when to use Foo x;
  - when to use Foo *x;

  Parameters like that, return codes like that, reference counting (and
  using _copy()) is relevant here, but not there, and things like that.

  The complexity of reference counting is unfortunately now not gone, but
  we have two approaches where with one you need to think different than
  with the other.

  I'd like to have a more unified approach if that is possible.

* Object is an interface, too:

  Object is an interface which behaves like other interfaces. It's just not
  mentioned in core.idl. Thus, it is not called Object_base, and has no
  smartwrapper called Object, which leads to these things being quite a bit
  inconsistent.

  For that reason, using Foo x; x._useRemote() or x._lookupMethod(m) won't
  work right now.

Well, all in all, I'd like to recommend you to read

In kdelibs:
- arts/soundserver/artscat.cc
- arts/soundserver/artsplay.cc
- arts/soundserver/soundserver_impl.cc
- arts/examples/artscapi.cc

In kdemultimedia:
- arts/tools/main.cpp
- kaiman/kaiman.cpp

to see how the new API currently isn't consistently used throughout all
sources leading to possible confusion. If we could get this all a bit
more polished/clean still, it would be nice.

Keep in mind one thing: the thing people should to with aRts is remote
usage. Thus the API should make remote usage as easy as possible.

Also compositional abilities (implementing a new object in terms of several
connected old objects) are probably relevant (at least later).

The examples flow (and similar) are not that representative, as they wouldn't
work in a realworld environment, as the soundserver is using /dev/dsp and
flow can't. Thus, at least some kind of communication is required even for
that simple cases.

> I'd now like to add a command-line option to mcopidl to generate automatically
> some empty implementation files. The development process for a new object would
> look like:
> - write foo interface in foo.idl
> - mcopidl -a_new_option foo.idl  // to generate foo_impl.h/cc.empty for ex
> - fill the gaps and compile
> - now can use the foo object directly (with the new C++ syntax) anywhere.

Great. I did that for mico once, and it did improve working with it quite
a bit. With the very very small object MCOP offers everywhere, results
should be better, still.

> I also plan to describe this in a documentation file when it's done.

I am currently writing on the multimedia chapter in the KDE2 book. I plan
to put a preview on the web soon. That should contain such things.

> Now, a question. There is talk on kde-core-devel for freezing kdelibs. I
> personally think that freezing arts is a bad idea. Freezing all the other libs
> is a good thing, because it will allow people to start writing binary compatible
> apps using those libs. But aRts/MCOP is still moving, and IMHO it's not ready
> yet for people to start coding apps on top of it with a binary compatible
> restriction on us. There are such things or extensions like video which will
> surely require a binary incompatibility somewhere/'somewhen'.
> Should we talk about it (and to the release coordinators) on kde-core-devel?

Well, about somewhere/somewhen: the problem is, that knotify, kaiman, kmidi,
artscontrol, the plain C api, libkdemedia and (soon) artsbuilder will be
using mcop, so we can't change too much too long. Adding another data type
like video should be no problem.

But we have to stabilize nevertheless. KDE2.0 absolutely needs a stable
aRts/MCOP thing, while it doesn't need video. We have to make these things
work now.

That said: I don't think we can't change a like of code after the 30th. aRts
is less critical than, say, libkdecore.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-