Projects/Games/Porting to libkdegames v5

This page is a historical record

The information on this page is outdated or no longer in use, but is kept for historical purposes. Do not consider anything here to be current, up-to-date, or useful for today's world. Please see the Category:Archives for similar pages.

This document describes the changes introduced with libkdegames v5, which first appeared in the KDE 4.9 release.

New components

• KgSound provides a simple API for playback of short event sounds. Low latency is achieved through the use of OpenAL, with a Phonon fallback if the required libraries are not available.

Also, multiple new components have been added which replace existing components. These can be identified by the common class name prefix "Kg". See Reworked components for details.

Removed components

• The KGGZ framework has been removed completely.
• KGameLCD — Use QLCDNumber instead.
• KGameMisc — Instead of a random name, we advise to use generic names where appropriate.
• KGameProgress — Use QProgressBar instead.
• KGameSvgDigits — If you need SVG digits, include them in your own SVG theme.
• KGrid2D — You'll need to do the math yourself.

Reworked components

Difficulty

KGameDifficulty has been replaced by the KgDifficulty and KgDifficultyLevel classes. KgDifficulty stores the current level by itself, and allows for multiple KgDifficulty instances at the same time, although a singleton is provided by the Kg::difficulty() function. The following table shows how to port common uses of KGameDifficulty to this singleton:

Replace this...	...by this	Comment
KGameDifficulty::standardLevel	KgDifficultyLevel::StandardLevel
KGameDifficulty::Medium etc.	KgDifficultyLevel::Medium etc.
KGameDifficulty::addStandardLevel(level)	Kg::difficulty()->addStandardLevel(level)	As a convenience, consider to use the new addStandardLevelRange() method.
KGameDifficulty::init (window, receiver, slot)	KgDifficultyGUI::init(window);
	QObject::connect(Kg::difficulty(), SLOT(currentLevelChanged(const KgDifficultyLevel*)), receiver, slot);	Change the slot to the new signature. The old signature contained a standard level argument: Use the "standardLevel" property of the new argument instead.
KGameDifficulty::level()	Kg::difficultyLevel()
KGameDifficulty::setLevel(level)	Kg::difficulty()->select(level)	If used to restore the selected difficulty from the config file, delete the whole call and your custom config key. KgDifficulty remembers the level selection by itself. Please refer to the APIDOX for details, e.g. how to specify a default difficulty for the first run.
KGameDifficulty::levelWeights(), KGameDifficulty::localizedLevelStrings(), etc. while setting up a KScoreDialog	dialog->initFromDifficulty(Kg::difficulty());	If you need the QMaps from these KGameDifficulty functions, you can construct them by iterating over the KgDifficultyLevels. levelWeights maps hardness->key and localizedLevelStrings maps key->title.
KGameDifficulty::setRestartOnChange(roc)	Kg::difficulty()->setGameRunning(roc && running)	These two properties of KGameDifficulty are redundant: If both are true, the user will be asked for confirmation before the level is changed. If you do not want this, just do not use the setGameRunning method.
KGameDifficulty::setRunning(running)
KGameDifficulty::setEnabled()	Kg::difficulty()->setEditable()	The property has been renamed to clarify its purpose.

Theming and KGameRenderer

KGameTheme has been replaced by the KgTheme and KgThemeProvider classes, which generalize its behavior, overcome several hardcoded assumptions and offer some additional convenience.

KGameTheme implicitly looks for themes in KStandardDirs::locate("appdata", "themes"). KgTheme expects you to discover themes with a KgThemeProvider. The following mimics the old KGameTheme behavior:

KgThemeProvider* provider = new KgThemeProvider(QByteArray(), parent);
provider->discoverThemes("appdata", QStringLiteral("themes"));

If you want to use KgThemeProvider's functionality to automatically save the selected theme, give a non-empty value in the first parameter (see documentation). The default is "Theme". The following explanations will assume that you use this new functionality.

KGameRenderer's constructor syntax has changed. If you use KGameRenderer, give a KgThemeProvider to it:

//before
KGameRenderer renderer("themes/default.desktop");
//after
KGameRenderer renderer(provider);

And redirect the setTheme() calls to KgThemeProvider:

//before
renderer.setTheme("themes/default.desktop");
//after
provider->setCurrentTheme(provider->defaultTheme());

Themes in the context of KgThemeProvider are KgTheme instances, rather than simple strings. The valid instances are usually created with discoverThemes(), and can be retrieved with the themes() method.

The KGameRenderer::themeChanged(QString) signal is replaced by KgThemeProvider::currentThemeChanged(const KgTheme*).

Replace KGameThemeSelector by the new KgThemeSelector class.

//before
KGameThemeSelector selector(parent, Settings::self(),
    KGameThemeSelector::NewStuffEnableDownload);
//after
KgThemeSelector selector(provider,
    KgThemeSelector::EnableNewStuffDownload, parent);

If the theme selector is the only page in your KConfigDialog, you can discard the dialog and use KgThemeSelector's stand-alone behavior:

//simple example
selector->showAsDialog();
//complex example
KStandardGameAction::preferences(selector, SLOT(showAsDialog()), actionCollection());

Just constructing and displaying a KgThemeSelector is enough if you use automatic theme selection saving. Since KgThemeSelector applies selection changes automatically, you need to listen to KgThemeProvider::currentThemeChanged if you need to act on theme changes manually.

Any manual selection saving code can be discarded. Selections in the KgThemeSelector will automatically be saved to the application config file. Since KgThemeProvider always saves in the [KgTheme] config group, you might need to migrate the old configuration key. Refer to the kconf_update documentation for details, or look at the update script for the kdegames module (in the libkdegames source tree).

Build system changes

If you use a version of libkdegames from before the 4.9 release, you're CMakeLists.txt looks like this:

find_package(KDE4 REQUIRED)
include(KDE4Defaults)
find_package(LibKDEGames REQUIRED)

add_definitions(${QT4_DEFINITIONS} ${KDE4_DEFINITIONS}
include_directories(${KDE4_INCLUDES} ${KDEGAMES_INCLUDE_DIRS})

...

target_link_libraries(mytarget ${KDEGAMES_LIBRARY})

Because the old LibKDEGames package did not have a way to specify versions, we had to change the package name. libkdegames v5 is found by the "KDEGames" package, that is: The third line in the snippet above becomes

find_package(KDEGames REQUIRED)

The old LibKDEGames package and the new KDEGames package both set the same variables (with the same semantics), so no porting needed there:

${KDEGames_FOUND}
${KDEGAMES_LIBRARY}
${KDEGAMES_INCLUDE_DIR}
${KDEGAMES_INCLUDE_DIRS}

You can setup your build system such that you can use either the old or new libkdegames, depending on what's available. For example, replace the find_package(KDEGames) line by

find_package(KDEGames)
if (KDEGames_FOUND)
    add_definitions(-DNEW_LIBKDEGAMES)
else (KDEGames_FOUND)
    find_package(LibKDEGames REQUIRED)
    add_definitions(-DOLD_LIBKDEGAMES)
endif (KDEGames_FOUND)

Then use the defines NEW_LIBKDEGAMES and OLD_LIBKDEGAMES in your code.