libtagaro -> kdereview [-> kdegames]

[Ben Cooksley]

On Thu, Apr 21, 2011 at 11:56 PM, Stefan Majewsky
<stefan.majewsky at googlemail.com> wrote:
> Hi,
>
> what is the technical procedure for moving libtagaro.git to kdereview?
> I think sysadmins need be informed, and hope that those are reading
> here.

Project moved to KDE Review.

Regards,
Ben Cooksley
KDE Sysadmin

>
> Assuming that this goes well: I hereby propose to move libtagaro to
> the kdegames module after the usual review period. For the time being,
> because kdegames has not yet moved from SVN, this would create a
> module that is split between SVN and Git, but a similar situation
> exists with kdegraphics, so I hope this is not a problem. In any
> event, scm-interest is CCd if anyone wants to discuss this.
>
> Rationale: libtagaro intends to replace libkdegames in the long run.
> libkdegames was developed long before such important technologies as
> QGraphicsView, QML and OCS, which define how our games work now or in
> the near future. Therefore, the scope of the support library that is
> libkdegames changes rapidly.
>
> Currently, libtagaro contains
> 1. an advanced version of KGameRenderer from libkdegames, which adds
> some further optimization opportunities and flexibility
> 2. a simple sound effects API which, if possible, uses OpenAL to
> reduce playback latency
> 3. some basic layouting components for QGraphicsView-based games
>
> Not much of this is new in the kdegames codebase. Number 2 is already
> used by Granatier (by means of a static source copy), number 3 is
> already used by Kolf (in the same way). Number 1 is, as I said,
> heavily based on KGameRenderer which is already used by about a dozen
> games.
>
> I want to add more components, especially to accommodate the needs of
> mobile form factors, but doing so will be much easier when I can rely
> on the games having a hard dependency on it. Previously, I planned to
> make libtagaro a private library inside the module, but this approach
> is unpractical while the rest of kdegames is still in SVN, or when
> kdegames moves to Git with a split repository layout. I therefore plan
> to install headers publicly, but explicitly state that there is no
> API/ABI stability guarantee for the time being, i.e. SO versions will
> likely be bumped often over the course of the next few 4.x releases.
>
> I conclude my explanations with a braindump of what needs to be done:
> * TagaroAudio falls back to Phonon when OpenAL is not available, but
> the Phonon backend is not yet implemented. (Mathias Kraus of Granatier
> helps with that.)
> * No CMake find-script etc. is installed at the moment. AFAIK it would
> be best to include this with the rest of the kdegames module. Also, it
> is probably not state-of-the-art to detect libsndfile through
> pkgconfig. Granatier has a FindSndfile.cmake which I plan to copy.
> * I have not checked Krazy output for quite a while, though I think it
> was empty some two months ago.
>
> Greetings
> Stefan
>