[Kde-games-devel] Library layout proposal

[Brian Croom]

Hi Stefan,

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?

--Brian

2010/8/14 Stefan Majewsky <kdemailinglists at bethselamin.de>

> On Thursday 12 August 2010 18:50:29 Stefan Majewsky wrote:
> > Possible libraries include:
> > * libkgamevisuals: KGameRenderer, QGraphicsView-based convenience
> classes,
> > and a KGameTheme on steroids which is boiling in my mind
>
> Some first parts of this library are now available. There is:
> * KgvTheme and KgvThemeProvider, the generalized form of KGameTheme
> * KgvRenderer, a renamed version of KGameRenderer (with the custom colors
> stuff and the primary view stuff stripped out; both things will be done
> properly later)
> * KgvConfigDialog, which includes an updated version of the
> KGameThemeSelector
>
> The code for the library is available from [1], and attached to this mail
> is
> an example application [2], which shows how easy to use the stuff in
> libkgamevisuals is (note esp. how the renderer automatically picks up
> themes
> which are selected in the config dialog).
>
> My short-term roadmap for libkgamevisuals is:
> 1. design and implement KgvBoard, as a superior replacement for the
> automatic
> rescaling in KGameRenderedObjectItem (aka KgvSpriteObjectItem)
> 2. combine KGameSvgDocument, KSpiral's SvgReader, and some stuff from QtSvg
> into a QSvgRenderer on steroids, as a much superior replacement for the
> aforementioned components and the QPaintDeviceColorProxy
>
> Though the second point sounds complicated, that's actually the low-hanging
> fruit. I also want to do an interaction framework which scales to different
> form factors and input methods (something like what I've done in Palapeli,
> though this one has serious design flaws and limitations).
>
> And even more important, we need a concept how our interface can adapt
> itself
> to devices where KXmlGui is not the right solution. I think we'll need to
> abstract KXmlGui at some point, to be able to exchange that for on-screen
> (as
> in: on the QGraphicsView) controls like in KBattleShip.
>
> Okay, I'm really going to finish the mail now. I'm sorry if this is going
> too
> fast for you, but the code is just flowing out of my hands into the editor,
> and I can't do nothing about it.
>
> Greetings
> Stefan
>
> [1] git://git.bethselamin.de/libkgame.git / http://git.bethselamin.de
> [2] For those who are reading this mail in the mailing list archive: This
> example application compiles against commit 3c8d6c2 from [1].
>
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20100816/0402b5de/attachment-0001.htm