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

List:       kde-multimedia
Subject:    Re: aRts in trunk
From:       Michael Pyne <pynm0001 () comcast ! net>
Date:       2005-07-31 0:16:08
Message-ID: 200507302016.12830.pynm0001 () comcast ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 30 July 2005 08:14, Christian Esken wrote:
> > svn will check out any URL you give to it, and if you're using
> > kdesvn-build you can just stick "branch 1.5" into your arts module
> > config, re-checkout, and be done with it.
>
> Are you sure: Will any application in trunk compile/work with that version?
> Probably subtle fixes were appiled, so that it compiles with QT4 (source
> code fixes, #include's , #define's, ...).

Well like I mentioned, arts 1.5 and arts trunk have just recently diverged.  
If they worked with arts trunk last week then they should work fine with the 
more recent arts.  The idea here is to kill the fork early before that 
becomes an issue. ;-)

As far as KDE support code around arts, I'm not sure if that code would be 
compatible between KDE 3 and KDE 4, but as long as we base the code on arts 
1.5 then they should at least be compatible with the same arts.  Or in a 
diagram:

arts 1.5
+- arts-kde-4
\- arts-kde-3

Or in other words, we may need to port the current KDE 3 wrapper around arts 
to KDE 4 so that applications can develop against *something* until kdemm is 
more or less finalized but that shouldn't be an aRts issue.  And if 
applications simply use aRts directly that shouldn't be an issue either way.

Regards,
 - Michael Pyne

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia


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