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

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

−

== New components ==

== New components ==

Line 128:

Line 127:

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 <tt>[KgTheme]</tt> config group, you might need to migrate the old configuration key. Refer to the [[Development/Tools/Using_kconf_update|kconf_update documentation]] for details, or look at the update script for the kdegames module (in the libkdegames source tree).

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 <tt>[KgTheme]</tt> config group, you might need to migrate the old configuration key. Refer to the [[Development/Tools/Using_kconf_update|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:

+

+

<syntaxhighlight lang="cmake">

+

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})

+

</syntaxhighlight>

+

+

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

+

+

<syntaxhighlight lang="cmake">

+

find_package(KDEGames REQUIRED)

+

</syntaxhighlight>

+

+

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

+

+

<syntaxhighlight lang="cmake">

+

${KDEGames_FOUND}

+

${KDEGAMES_LIBRARY}

+

${KDEGAMES_INCLUDE_DIR}

+

${KDEGAMES_INCLUDE_DIRS}

+

</syntaxhighlight>

+

+

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 <tt>find_package(KDEGames)</tt> line by

+

+

<syntaxhighlight lang="cmake">

+

find_package(KDEGames)

+

if (KDEGames_FOUND)

+

add_definitions(-DNEW_LIBKDEGAMES)

+

else (KDEGames_FOUND)

+

find_package(LibKDEGames REQUIRED)

+

add_definitions(-DOLD_LIBKDEGAMES)

+

endif (KDEGames_FOUND)

+

</syntaxhighlight>

+

+

Then use the defines <tt>NEW_LIBKDEGAMES</tt> and <tt>OLD_LIBKDEGAMES</tt> in your code.

Revision as of 13:33, 6 November 2012

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

Contents

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.

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:

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:

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*).

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:

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: