Re: [gluon] Fwd: Gluon: gamesmodel

[Laszlo Papp <djszapi@xxxxxxxxxxxx>]

Hi,

I am almost ready with the gameitemsmodel class that I am proposing
into the player/lib/models. There is no UI member hard-coded, just
pure "raw" data. Clean, scaled for performance, easy and can be used
from the QML Player too. It uses the proper item data role mechanism.
I think this implementation could be used by any standalone player.

Much closer to the ghns, knewstuff3 way and this example:
http://doc.qt.nokia.com/4.7-snapshot/declarative-modelviews-abstractitemmodel.html

Please give me your 2 cents on it whether or not I can overwrite the
other one after I fixed the things - after the release for sure - in
the related players which used the "old" one.

https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/player/touch/models/gameitemsmodel.h
and
https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/player/touch/models/gameitemsmodel.cpp

Best Regards,
Laszlo Papp

On Sun, Feb 6, 2011 at 1:59 PM, Laszlo Papp <djszapi@xxxxxxxxxxxx> wrote:
> On Sun, Feb 6, 2011 at 1:51 PM, Shantanu Tushar Jha <jhahoneyk@xxxxxxxxx> wrote:
>> Kindly CC the ML ...
>>
>> ---------- Forwarded message ----------
>> From: Shantanu Tushar Jha <jhahoneyk@xxxxxxxxx>
>> Date: Sun, Feb 6, 2011 at 5:19 PM
>> Subject: Re: Gluon: gamesmodel
>> To: Laszlo Papp <djszapi@xxxxxxxxxxxx>
>>
>>
>> Um, is it really a good idea to do something UI specific in a model (storing
>> and returning a widget in the model) ?
>> Imo model should only be concerned about the data.
>
> Unfortunately, I cannot inherit your model implementation because it
> contains two basic methods you had to reimplement that I also need to
> reimplement. (But this also means that there is no code duplication).
> I think the current model implementation has bottlenecks regarding the
> performance. (fex. it always builds the project by a data method call
> and not just once in the constructor involving the low-level dir
> manipulation all the time).
>
> My approach and design are a bit different, closer to the ghns,
> knewstuff3 ui way. (They did not put this into the lib either because
> it is quite standalone dependent - standalone related model, view,
> delegate)
>
> This way I do not need to return the elements separately in fact, just
> to build a gamesviewitem list in the ctor of the model and then just
> asking the widget that the update widget "draws". The current way now
> always asks the data and builds all the time.
>
> This is a good example what I I am proposing:
> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/knewstuff/knewstuff3/ui/itemsmodel.h
> (Also the own delegate:
> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/knewstuff/knewstuff3/ui/itemsviewbasedelegate.h#L40).
>
> I have already started the implementation and I am ready with the
> model and view. Let me show you the final result when I am ready with
> the own delegate. ;)
>
> Thank you in advance !
>
> Best Regards,
> Laszlo Papp
>

---
+----------------------------------------------+
Gluon is a high-level game development library for the KDE desktop enviornment.
http://gluon.tuxfamily.org/
http://gitorious.org/gluon