[Kde-games-devel] Moving first parts of Tagaro into kdegames for 4.6?

[Parker Coates]

On Tue, Sep 21, 2010 at 02:59, Stefan Majewsky wrote:
> as you might have noticed, we (mostly Brian) are stuck with the KBlocks port.
> Those games which are being ported from QGraphicsSvgItem to KGameRenderedItem
> actually become more complex because one has to add new code to determine the
> renderSize. It would be best if the items could automagically determine their
> renderSize.

Hello Stefan,

I know this is kind of obvious, but I thought I'd point it out anyway:
we don't really /need/ to port everything to KGameRenderer. If KBlocks
(and other QGraphicsSvgItem based games) are running fine, then is
there really a problem? KGameRenderer was introduced to reduce the
duplication of and improve the average quality of
SVG-to-cache-to-pixmap rendering code in our games. QGraphicsSvgItem
based code had no such code to begin with so there's no way that
adding a rendering framework with simplify the code. (I understand
that the performance of QGraphicsSvgItem leaves a lot to be desired,
but are any of the games currently using it noticeably slow?)

So unless there are currently issues that I'm not aware of, I think
leaving KBlocks alone should be considered a perfectly valid option
for SC4.6.

> Long story short: I would like to hear your opinions on including first parts
> of libtagaro in the kdegames module during the 4.6 cycle. Because the API is
> in no way stable, libtagaro would be a private library for the 4.6 release
> (and probably also for 4.7). If this is done, this would probably also mean to
> remove KGameRenderer from libkdegames again, because the same functionality is
> provided by Tagaro::Renderer.

Could you expand on what you mean by "a private library"? If you mean
to make the Tagaro library internal and private to a single game, then
I fully support the idea. (See LibKCardGame and KPat in SC4.5.) That's
a great way to stabilise APIs and wrangle with abstractions without
affecting anyone else.

If you mean to create a top-level directory for Tagaro and have
multiple games using it, I'm not even sure that's technically feasible
while keeping the library private. Packagers would have to package it
separately, so BICs and SO versions would have to be watched.
Something that can be "apt-get installed" by Joe User hardly seems
private any more.

I guess a third option would be to split Tagaro up and makes the
different parts internal to different apps. If Granatier really needs
Tagaro::Board and friends, move it there for
testing/development/refinement. Do the same for Tagaro::Audio and
Grantier. Honestly, I don't know if this makes sense or not, but I
just thought I'd throw it out there.

The forth (and probably easiest) option is to abandon the concept of
libtagaro and simply move the components into libkdegames one by one
as they become feature and API complete, doing a "s/Tagaro::/KGame/g".
Like the option above, this probably depends on how interconnected the
different parts of libtagaro are (and how willing you are to give up
your "fancy library name" :) ). Of course, once all the various
components have been moved into libkdegames, we could look at
deprecating the entire library and moving only the clean, modern and
working parts to a new libtagaro.

> Benefits:
> - Visibility of Tagaro development improves.

I don't mean to be contrary, but you've always had the option of doing
Tagaro development with the greater visibility offered by
playground/games. I understand the appeal of Git and your reasons for
using it, but I think the better visibility issue is mostly orthogonal
to inclusion in the main module.

> Possible disadvantages:
> - Because Tagaro's API is not stable, we cannot install it for others to use
> it, and changes in Tagaro might mean to adjust usages in a dozen games.

This is really the big issue. Talk of outside users mostly academic,
as I'm not aware of any games developed outside of KDE's SVN which on
libkdegames. On the other hand, our module (and playground) contains a
huge number of games many of which are unmaintained or barely
maintained. So I think internal users are a much bigger concern than
external.

I really wouldn't to see some of our less maintained games ported to a
non-stable Tagaro. Active developed code depending on unfinished libs
is fine and inactive code depending on stable libs is fine, but
inactive code depending unfinished libs is dangerous. I'd hate to see
a bunch of games left "stranded" should the Tagaro project fall
through. I mean no offense, but Tagaro currently has a bus factor of 1
and that's unlikely to change in the near future. For this reason, I
think KGameRenderer should be kept around /at least/ until libtagaro
1.0 is released.

> Another point which needs discussion is the review policy. I've no problem
> with the current Tagaro code being kdereviewed (is that a proper word?), but
> what happens with the code which we add to Tagaro after it has been included
> in kdegames? (This concerns e.g. the complete networking and canvas interface
> code.) Because the API is private at this point, this should not be a problem.
> (The situation is quite similar to libkcardgame IMO.)

This really depends on which definition of "private" we're talking
about. If the library is internal to an actively developed game (as
with LibKCardGame) then there's no need for official review. It's just
an implementation detail of that application and won't require review
until it's made public.

Sorry that the above is mostly negative. In reality, I have high hopes
for Tagaro and look forward to seeing it mature. I'm confident that
you'll get there eventually, but not confident enough to risk the
stability of the module in the meanwhile.

Parker

> P.S. Tagaro::Renderer has one feature regression compared to KGameRenderer: It
> misses the customColors support because the used methodology is a ugly hack.
> I'm working towards a proper, albeit minimally more complicated, solution.

Does the customColors stuff actually have any users currently? I know
no one in the main module is using it.