Oops, sorry for the bad email address autocompletion... lots of stuff
happening over in http://code.google.com/p/twisty :-)
On Sat, Jul 18, 2009 at 9:55 AM, Ben
Collins-Sussman<sussman_at_red-bean.com> wrote:
> 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=2372281
Received on 2009-07-18 16:57:33 CEST