Hi Stefan,<br><br>Some of these classes, such as KgvBoard and KgvView look quite useful. I will be interested to watch how development in the coming days and weeks. As I am new to the development practices here, I just wanted to ask whether this forthcoming work means that efforts porting to KGameRenderer should be deferred until the Kgv* code is ready for general consumption?<br>
<br>--Brian<br><br><div class="gmail_quote">2010/8/14 Stefan Majewsky <span dir="ltr"><<a href="mailto:kdemailinglists@bethselamin.de">kdemailinglists@bethselamin.de</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Thursday 12 August 2010 18:50:29 Stefan Majewsky wrote:<br>
> Possible libraries include:<br>
> * libkgamevisuals: KGameRenderer, QGraphicsView-based convenience classes,<br>
> and a KGameTheme on steroids which is boiling in my mind<br>
<br>
</div>Some first parts of this library are now available. There is:<br>
* KgvTheme and KgvThemeProvider, the generalized form of KGameTheme<br>
* KgvRenderer, a renamed version of KGameRenderer (with the custom colors<br>
stuff and the primary view stuff stripped out; both things will be done<br>
properly later)<br>
* KgvConfigDialog, which includes an updated version of the KGameThemeSelector<br>
<br>
The code for the library is available from [1], and attached to this mail is<br>
an example application [2], which shows how easy to use the stuff in<br>
libkgamevisuals is (note esp. how the renderer automatically picks up themes<br>
which are selected in the config dialog).<br>
<br>
My short-term roadmap for libkgamevisuals is:<br>
1. design and implement KgvBoard, as a superior replacement for the automatic<br>
rescaling in KGameRenderedObjectItem (aka KgvSpriteObjectItem)<br>
2. combine KGameSvgDocument, KSpiral's SvgReader, and some stuff from QtSvg<br>
into a QSvgRenderer on steroids, as a much superior replacement for the<br>
aforementioned components and the QPaintDeviceColorProxy<br>
<br>
Though the second point sounds complicated, that's actually the low-hanging<br>
fruit. I also want to do an interaction framework which scales to different<br>
form factors and input methods (something like what I've done in Palapeli,<br>
though this one has serious design flaws and limitations).<br>
<br>
And even more important, we need a concept how our interface can adapt itself<br>
to devices where KXmlGui is not the right solution. I think we'll need to<br>
abstract KXmlGui at some point, to be able to exchange that for on-screen (as<br>
in: on the QGraphicsView) controls like in KBattleShip.<br>
<br>
Okay, I'm really going to finish the mail now. I'm sorry if this is going too<br>
fast for you, but the code is just flowing out of my hands into the editor,<br>
and I can't do nothing about it.<br>
<br>
Greetings<br>
Stefan<br>
<br>
[1] git://<a href="http://git.bethselamin.de/libkgame.git" target="_blank">git.bethselamin.de/libkgame.git</a> / <a href="http://git.bethselamin.de" target="_blank">http://git.bethselamin.de</a><br>
[2] For those who are reading this mail in the mailing list archive: This<br>
example application compiles against commit 3c8d6c2 from [1].<br>
<br>_______________________________________________<br>
kde-games-devel mailing list<br>
<a href="mailto:kde-games-devel@kde.org">kde-games-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-games-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kde-games-devel</a><br>
<br></blockquote></div><br>