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

List:       kde-multimedia
Subject:    Re: KDE2.1 multimedia planning
From:       David "Hamish" Harvey <david.harvey () bristol ! ac ! uk>
Date:       2000-10-31 14:10:44
[Download RAW message or body]

On Sun, 29 Oct 2000, Antonio Larrosa wrote:
> I'd like to propose doing an important change in aRts, and let it link
> to DCOP.
>
> Afaik, the only reason aRts is not linking to kdelibs and/or qt
> is so that the gnomes can use it in the future. But I don't see
> this happening, so not linking aRts to kdelibs/qt will only mean
> wasted efforts/time/etc.
>
> To provide signals/slots between different applications we should use
> DCOP, it's a standard they can also use if they want (by writing
> their own implementation), and would mean a reduction of code and
> simplification for ourselves.
>
> For signals/slots inside an own application, Qt is ok for KDE apps,
> glib/gtk/whatever is ok for GNOME apps, the only problem is artsd.
>
> But are the gnomes going to use the same artsd ? or are they
> writing their own ? If they're writing their own, I'm all for
> linking artsd to the kdelibs if that would mean a simplification
> of code and simplicity of our libraries.
>
> Please don't reinvent the wheel, there're reasons to use mcop
> for large amounts of transfers, but signals between apps is a work
> for dcop.

While this is a valid point, I would say that keeping arts independent of 
kdelibs is still a good thing. My interest in this is that I am beginning to 
use mcop as the basis of some (non-audio - hydrological modelling, as it 
happens) work, as the principle on which it operates is a very close match to 
a prototype I built in smalltalk before I looked at arts. Independent of my 
desire to maintain platform (linux) independence (which I have in principle, 
if not in practise, with MCOP at present) my view of the situation is this.

True, app->app communication is a work for DCOP, but perhaps only for "apps" 
in the sense of user applications, rather than services. Consider, for 
example, if you had the synthesis process running on a separate computer from 
the GUI (I don't think this is unrealistic, if arts were to be used in a 
studio setting) having arts tied to kdelibs and qt would require that all of 
this overhead (and X, if DCOP uses ICE I suppose) be installed on the 
synthesis machine purely to provide a signal/slot mechanism.

Essentially, what am saying is that tying MCOP/arts too closely to 
Qt/DCOP/kdelibs renders it unfit for anything beyond use as a synthesis 
engine on a personal computer, whereas it could be so much more powerful. And 
that's before thinking about using in _different_ GUIs/desktops.

BTW, in the process of working with asynchronous streams, I have come across 
the following two little bugs (I think).

1) ASyncPort::processedPacket (in asyncschedule.cc) has the line 
"assert(count == 1)" which fails if a stream has two subscribers (where count 
== 2). Chaning this to "count == subscribers.size()" fixes the problem. 

2) I had a lot of problems with packets, where if a new data type had a 
destructor, the program segfaults when the RawDataPacket destructor calls 
delete contents (in datapacket.h). Should this line not read "delete [] 
contents".

Cheers,
Hamish


-- 
+----------------------------------+-----------------------------------+
| David "Hamish" Harvey            | Email: David.Harvey@bristol.ac.uk |
| PhD Student                      |   Tel: +44 (117) 928 9768         |
| Water Management Research Centre |   Fax: +44 (117) 928 9770         |
| Department of Civil Engineering  | http://www.cen.bris.ac.uk/        |
| University of Bristol            |           civil/pgra/dph/dph.htm  |
+----------------------------------+-----------------------------------+


_______________________________________________
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]