Yes yes, a design with clear delineation of responsibilities! Looking
forward to it.
I spent a long while yesterday anazyling Twisty's UI code (it was all
done by Marius, so I was ignorant). And really, the whole combo of
ZScreen/ZWindow/ZOutput etc. is entirely redundant with what Roboglk
wants to do -- it's an alternate competing framework that we should
trash. However, as you point out, the internals of those Z-classes
are good code examples to study, so that we can fill out roboglk
faster. Even the TwistyView class is skeletal and offers us no real
advantage (at the moment) over a normal TextView (or some roboglk
subclass thereof.)
The main design of Twisty is to bring up a 'main screen' which greets
the user and allows them to launch specific games in alternate
threads... really just one 'child' thread at a time. I was originally
hoping we could could ignorantly launch model.c as our game-thread...
but it turns out that even the 'main screen' is using the
ZScreen/ZWindow stuff just to print the welcome message. Gah, oh
well.
So yeah, we need some roboglk classes ASAP that at least allow us to
rewrite the welcome screen by doing simple printline() calls to it.
On Sat, Jul 18, 2009 at 8:03 AM, Edward
McCardell<edward.mccardell_at_gmail.com> wrote:
> In my last message I mentioned working on implementations of Glk and
> GlkTextBufferWindow and putting them in the glkjni roboglk repository; now
> that I've finished my morning pot of coffee I realize that this idea needs
> some coordination.
> Following the idea that Twisty should be a high-level consumer of roboglk, I
> am working on defining classes which would, in broad terms:
> - inform Twisty that a glk window is requesting input,
> - provide a method for Twisty to call for each input key,
> - return the appropriate events to glkjni, and
> - forward glk output by calling methods on an object supplied by Twisty.
> That last one is the one that needs the most work, depending on whether the
> code for low-level window output lives in Twisty (and roboglk would just
> call a Twisty-supplied "print" method) or in roboglk--with the roboglk code
> "driving" a Twisty-supplied TextView.
> Instead of getting ahead of myself again, I will get my thoughts in order
> and put them in concrete form with a proposal detailing my current ideas for
> roboglk's responsibilities and the division of labor.
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372280
Received on 2009-07-18 16:55:42 CEST