aRts and Gnome

[Stefan Westerfeld <stefan space twc de>]

   Hi!

That KDE2 will be using aRts has been definitely decided at the KDE-TWO
conference. After showing aRts at the conference everybody afterwards was
happy that it could go into KDE2 ;) - ask any core developer who was there.

On the other hand, it would be good to have more certainity about Gnome,
i.e. wether aRts should go in Gnome now or not now or never.
I would be happy if we could make available "aRts as Gnome soundsystem"
as well, and this descision will also would influence how development on
aRts will continue.

So here are the most important issues as I see it:

(i) language       -> aRts is not written in plain C

  aRts is implemented in C++, currently basing on mico as well. If for some
  reason each piece of Gnome core technology has to be implemented in plain
  C, we can stop discussing right here.

  After discussing with Owen on IRC yesterday, the idea he had was - well
  just do a small C wrapper library. Sure. That it is implemented in C++
  also allows you to do things like "writing a plain-C-api", or even do
  plain-C-plugins, if you care about that.

  However, the other thing he meant was: if the interfaces are clean, we
  just can reimplement it in C later. Well, if you want that, please start
  from scratch. aRts is a complex multimedia component system, which is
  intended to give you a lot of services. So there will be (are) lot's of
  interfaces and ways-things-work. Things will be constantly improved for
  now, so I can't limit myself to: "aRts only provides these fifty lines
  of interface, and if you reimplement them, its still aRts". Believe me,
  it is *not* a sound server, aRts is intended to be competitive to what
  people call "virtual studio technology", as well as other stuff like
  i.e. DirectMusic. You can't do that in a few lines. You need a proper
  object model etc.
  
  On the other hand, aRts  does not use Qt in the core, for the sake of
  portability.  Just plain STL to do strings, lists etc. So there are no
  "we-don't-like-Qt" issues.

(ii) gnome-coding  -> somebody familiar with Gnome/Gtk+ has to do it

  That is the critical point. Somebody should step up and say: "ok, I'll
  care about it". I can supply any information you might need, and we can
  discuss all implementation details, concepts, etc.

  But I can't do the Gnome/Gtk+ code. I've already enough to do with
  hacking on the aRts core stuff, caring for the KDE2 integration and
  maintaining artsbuilder and all components. Besides Qt/KDE/CORBA/STL,
  there is currently no room left for learning GLib/Gtk+/Gnome/ORBit/GNORBA
  whatever.

  Also I am not really good at thinking in plain C. ;)

(iii) mico         -> is mico suitable for now?

  aRts is implemented on top of mico (BOA, not POA), and I don't think
  somebody will get it compiled on ORBit easily. Mico is a bit ugly,
  because it takes quite some resources. Well, you know yourself.

  I know that issue, and also CORBA is not the perfect technology to base
  multimedia on. Elliot also needed to do extensions in GMF to do streaming,
  and I need in aRts as well. Also, transferring events, etc. over CORBA
  is slower than it has to be.

  MCOP is an experimental technology I am working on to solve the problem,
  which basically is a fast multimedia ORB (nothing to do with CORBA, though).
  Finishing that, you could declare streams directly in your mcop-idl files,
  and have a proper object model.

  However it might be good to release aRts (that is: use it for desktop
  tasks) even before that (porting everything to MCOP may take it's time).
  So one idea might be: go with mico as long as mcop isn't ready, and then
  slowly port to mcop.

  Going the progressive way also gives certainity that the system will work
  at any point. Well, there are pro's and con's of either way, but as soon
  as somebody from Gnome feels responsible (and has looked in the code,etc.),
  we can plan together what we really want to do.

URL: http://linux.twc.de/arts

If you read the concepts section, and a bit of other stuff, you'll see
approximately what I implemented. There is no documentation about the
internals, but reading the CORBA idl file is a good start. Also, looking
at a simple module (e.g. Synth_ADD) in modules.cc. Depending on how MCOP
is doing, I'll see what developer documentation I need to write (either
old/new object model).

I hope to get cooperation really started with that mail.

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