[Kde-games-devel] aKademy meeting and APIs (was Fwd: KDE/kdegames/katomic)

[Mauricio Piacentini]

Aaron J. Seigo wrote:
> i'll be meeting up with kde-edu people @ akademy to discuss a bunch of these 
> related issues. i'd like to invite kde-games team members to join us.. we 
> don't have a firm date/time yet, but it will likely be either monday or 
> wednesday at this point.

That will be great. We already have developers that work on more than 
one module (games and edu, games and plasma), so this will be a nice 
opportunity for us to continue enhancing our common policies! And in the 
future I expect that some games will be implemented as plasmoids, so the 
boundaries will blur even further.

>> For each theme there is a *.desktop file, one of which is called
>> default.desktop (the default theme for new players).  Mauricio chose
>> the *.desktop format because:
> we (plasma) should adopt the same key names as you guys for things like the 
> preview.
> 
> perhaps the kdegame theme .desktop entries could also be made a bit 
> more "standard" (i use that term loosely in this context) for things like the 
> author name, email, etc.. see:
> 
> http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/classKPluginInfo.html

Sure, this could be nice, and something we can do right now. For 
KGameTheme however we chose to keep a more abstract way to expose 
properties (using a key/string pair.) But the actual key names could 
follow any standard we pick: we should discuss this at this akademy 
meeting, and implement it before 4.0 ships.

>> Mauricio has added classes KGameTheme and KGameThemeSelector
>> to libkdegames.  The first is to find, load and decode a theme.  The
>> second is to drive a theme-selection page in KConfigDialog.

Actually milliams did the cleanup and abstraction of my KMinesTheme 
classes to make them fit for libkdegames. Which can only be good, as I 
see that he is working with libplasma in the past few weeks as well :)

Just to make things clearer: as far as I am concerned you are very 
welcome to provide more abstract implementations of these concepts that 
we could share with other (non-kdegames) apps in the future. You have 
much more experience with libraray and API-design than most of us in 
kdegames. On the other hand, it is also nice to use kdegames as a 
testground for some of these issues imo, starting with an 
application-specific implementation, then abstracting it to libkdegames. 
This process can lead to even more refined shared classes that can be 
made available at a more global level. This process seems to be working 
fine for the past few months, KScoreDialog is another example.

> hm.. i'll have to take a look at these classes indeed. we have dialogs for 
> this from kicker (and superkaramba, which is based on the one from kicker). 
> it probably makes sense from a user experience POV to harmonize all these 
> visually and work flow wise...
> 
> we'll also be using the new GetHotNewStuff2 dialog for downloading themes and 
> something called "plasmagik" for the packages, but that won't be in kdelibs 
> until 4.1 due to it missing the libs cut off. we'll be giving it a temporary 
> home in libplasma until then.

Notice that the libkdegames theme selector config dialog page already 
has integration with GHNS2 (also added by Matt.) It has not been really 
tested and reviewed deeply, but we can make a mental note about tackling 
this issue at aKademy, as Josef will probably be there!

Regards,
Mauricio Piacentini