[Kde-games-devel] GSoC 2010

[Arjen-Wander Hiemstra]

On Friday 29 January 2010 12:55:33 Mauricio Piacentini wrote:
> I got this impression from the information at the most recent Gluon blog
> post:
> 
> http://blog.heimr.nl/ahiemstra/2010-01/whats_happening_gluon
> 
> That seems to tell that the Creator will use kdelibs, but for all
> other libraries (and the players) only Qt is being considered. Good to
> know you are aiming for using kdelibs in the desktop player as well. I
> am not sure if it is really the best thing for Mac/Windows users :),
> but at least on Linux/Unix we should probably integrate it with the
> KDE SC. Still, libkdegames and other shared technology we use in the
> desktop games is probably not going to be used for Gluon games, right?
> 

Hmmm, thats my blog post, and it was really not meant to give that impression. 
Maybe I should clear it up with a new blog post if there is more confusion 
about that.

The idea of the Gluon Libraries is that they provide a Qt-based interface for 
several more low level libraries, as well as some "glue code" to support 
object hierarchies and such. It does not make a whole lot of sense to have 
these libraries depend on KDELibs, as there is little added value for these 
libraries. 

Then there will be a very simple Qt-only player, which will basically be a 
graphics display widget in a window, which can be used as player if there is 
no KDE available. The "real" player, with features like GHNS integration and 
others, will be using KDELibs and possibly other technologies. (Plasma 
perhaps? I like how Bangarang uses it.)

There is also Gluon Creator, which is a major part of our project. This is 
heavily based on KDE library technology and we are not planning to change 
that. We're planning to use the KDevelop Platform libraries for our code 
editor, which means we'll be even more linked to KDE on that front. ;)

As for libkdegames, I'm not sure what functionality it provides, so I cannot 
comment on that. Considering that Gluon Games will run in the Gluon Player, 
they will most likely not make use of libkdegames, no.

> >  We're very much aiming for that one :)
> 
> I realize that maybe a fraction of this sense of non-integration comes
> from having the code in a separate repository. Maybe this is due to
> the proposed git change, but it is really difficult for some people to
> keep track of what is happening inside kdegames SVN and lists, without
> having to go to other places to find out what is happening for each
> separate project.

Our current repository is a Git repo. I don't know who originally proposed 
this, as it was already on Git when I joined. But I personally would not 
really want to go back to SVN. I'm becoming more and more confident with Git 
and things like our current work on renaming would be a lot harder without it.

When KDE Games moves over to Git we can of course see if it is doable to move 
Gluon over to extragear/games or even KDE/kdegames. 

> 
> Notice that I like the Gluon architecture very much, and in the
> future, who knows, it might even replace the whole kdegames module,
> with people rewriting their games to run in the same player. This
> would likely solve a lot of our maintenance problems. But right now it
> is really a separate community, which I particularly think is not
> ideal.

I agree that the separate community things are not ideal. But we have been 
mostly busy with getting a first alpha out. I think after the alpha release it 
is a good moment to see how Gluon can become more of a part of KDEGames.

Regards,
Arjen Hiemstra