[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] Library layout proposal
From:       Brian Croom <brian.s.croom () gmail ! com>
Date:       2010-08-16 20:46:26
Message-ID: AANLkTimrAKvAxSkhEZoBTx8-m73Tm0-L4PutXb2RvfJH () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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@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@kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>
>

[Attachment #5 (text/html)]

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">&lt;<a \
href="mailto:kdemailinglists@bethselamin.de">kdemailinglists@bethselamin.de</a>&gt;</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> &gt; Possible libraries include:<br>
&gt; * libkgamevisuals: KGameRenderer, QGraphicsView-based convenience classes,<br>
&gt; 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&#39;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&#39;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&#39;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&#39;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&#39;m really going to finish the mail now. I&#39;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&#39;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>



_______________________________________________
kde-games-devel mailing list
kde-games-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic