WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
>> You mentioned standard KDE
>> requirements, are these documented somewhere?
> Yes. There are several tutorials, howtos and policies in techbase.kde.org
> and it might be a good idea to browse community.kde.org first. There are
> standard requirements re main window, menus, documentation of your game,
> documentation of API (doxygen), translation of strings (i18n), storing and finding
> data and graphics files, remembering previous setup (KConfigGroup), artwork,
> your own app's settings, keyboard setup, schedules, feature lists, committing code,
> help menu … and on and on.
> Re libkdegames you will need KStandardGameAction (standard menus and icons
> for Hint, Solve, Pause, etc.). You might also need KGameRenderer if you have
> a lot of graphics and themes, but perhaps not. SVG files can be slow to load
> and render or re-render if the main window gets resized. If so, KGameRenderer
> makes caching of already-rendered graphics automatic, making the game much
I spent some time today integrating KDE technologies. My master branch
now uses KApplication, KXmlGuiWindow, KDE i18n, KScoreDialog,
KGameDifficulty and KStandardGameAction.
I've also applied for a developer account. If the application is
approved, I will move the repository over to KDE hosting.
> Last but not least, I suggest reading the code of an existing not-too-large game,
> such as KDiamond, to find out what the various files are, what they do and how
> they work together.
That's a good point. KSudoku and KMines have been a big help so far.
Please excuse my not replying to all points (including all other
replies), it's late and I need to get some sleep :)