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

List:       kde-multimedia
Subject:    Re: ANNOUNCE: aRts - mikmod
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-03-17 13:13:46
[Download RAW message or body]

   Hi!

On Fri, Mar 16, 2001 at 10:46:13PM -0800, Charles Samuels wrote:
> I've just released an aRts plugin to play trackers files with arts (& noatun):
> 
> http://noatun.kde.org/plugins/arts_mikmod/
> 
> It can't seek, but that has libmikmod to blame, otherwise, it works, and sets 
> a good example for other plugins to be based on.

Very good. Just a few remarks (as if this is the reference, it should better
be as correct as possible):

1. don't include generated files and/or sources 

   The reason is: if you do, and there is a bug in mcopidl, or a new feature
   gets added, your generated .cc/.h files never get updated. On the other
   hand, if you use mcopidl from KDE2.1 you can't be sure that it will compile
   on a KDE2.0 system (whereas the other way round it is guaranteed to work,
   to allow KDE2.0 built plugins to be binary compatible). So call mcopidl
   manually.

2. don't mix up files providing type information and files providing trader
   information

   You will need to provide:

    * two files containing type information (a machine readable version of what
	  the .idl file contains), called <idlfilename>.mcoptype and <idlfilename>.
	  mcopclass
    * one file containing trader information per interface you implement,
	  called <interfacename>.mcopclass (where here namespaces are mapped to
	  directories, like Arts::FooBar -> Arts/FooBar.mcopclass)

3. don't call the .idl file the same than interfaces implemented in the .idl
   file - rather call it something like the library name (i.e. libartsflow
   = artsflow.idl = artsflow.mcopclass/artsflow.mcoptype) - this is related
   to 2.: if you call them the same, then you'll have collisions for the
   name of the type file and the name of the file containing per-implemented-
   interface-trader-information

4. things that are not part of aRts (like third party plugins) probably
   shouldn't use the Arts namespace/module, to prevent collisions with further
   extensions in aRts

Hope this doesn't sound too negative ;).

   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]