On Thu, Apr 21, 2011 at 11:56 PM, Stefan Majewsky <stefan.majew...@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 >