Active activities as Widgets

[Gerard J. Cerchio]

Eben Eliason wrote:
>>> There are some activities where the chat is an integral part of the
>>> participants' experience. In my case, chatter during the Go game may be
>>> nonexistent to multiple lines of interactive tutorial per move to
>>> razzing and praise from any of the observers. This is why I plan to have
>>> a mute button that mutes all chat from observers. Unchecked, the button
>>> allows kibitzing from all XO's in the buddy panel that joined the PlayGo
>>> activity.
>>>       
>
> Well, the exact implementation isn't well defined at this point.
> Obviously it's advantageous to be able to chat and work/play at the
> same time.  Doing this generically is hard because the screen is
> rather small and there is no place where such a chat window can always
> be positioned such that it isn't in the way.  The overlay idea,
> fullscreen or not, is the best general purpose solution we have so
> far.  Perhaps if we gain compositing support it can work somewhat like
> growl on OSX; perhaps a global keystroke will initiate a new "chat
> bubble" so to speak, so that joining in the conversation doesn't
> require clicking a button on screen or shifting contexts.  We're not
> sure the details yet, but the more seamless we can make it the better.
>
>   
> Obviously you gain the most real-estate for the chat this way.
> However, this also cuts off the activity completely, if only
> temporarily, which may not be what we want in the end.  I think
> something slightly lighter would be desired.  The question remains as
> to whether or not it is repositionable, since we have yet to introduce
> the idea of "windows."
>
> Obviously the push-to-talk method mitigates this problem, since the
> "interface" for such a system requires one onscreen button, or even
> one well known shortcut.
>   
I would like to see the OLPC retain its non-windowed presentation style. 
I have run into people that have no idea how many windows are running. 
When they do not see the browser, they simply start another one, 
ignoring Z order and minimized applications. Don't laugh, my wife and I 
are the ISP for our condo complex and we have a few service calls along 
these lines. Given the OLPC environment, fixed frames and whole screen 
activity switching makes a lot of sense. So if I am performing an 
activity that does not require chat and wish to reference a colleague on 
line, hitting F3 and choosing the chat application is not offensive at all.

For those activities that require chat, the interaction should happen in 
the context of the application's display structure. I am lucky that my 
particular application is square, this lends the rest of the rectangle 
to the buddy panel, which has the list of the participants in the upper 
half with the lower half containing the chat window. I am just finishing 
the basic game communications and will be moving on to the game player 
negotiation and setups this weekend.  I am resisting tabbing the tool 
bar for these tasks if at all possible to prevent my square Go board 
from getting any smaller.

I have been reviewing the code in the chat application and given the 
abilities of the dbus do not feel that text messages will add all that 
much complexity to the application. My original query was not as much 
having a chat window in my activity but more of a Delphi like component 
that I could drop into the buddy panel weld into my existing tubes and 
be done with chat.
> I think there's something to be said for activities which don't
> require much oomf.  I think the "do one thing, do it well" mantra is a
> good one, and one that might apply here.  The screen is small, so
> dedicate as much space as possible to the board, which has a large
> number of squares.  There is very limited RAM and CPU on these
> machines, so just because your game doesn't eat too much doesn't mean
> you should assume it will be reasonable to consume a significant
> amount of these for "add-ons", not to mention greatly increase network
> activity.  I'm not sure that a multi-way video conference is even
> feasible yet.
>
>   
I have now become anxious about whether the 19x19 go board is feasible 
on the OLPC. The game does have 9x9 and 13x13 modes of play. But the Go 
world considers these less than optimal. There will be quite some time 
before I get my G1G1's and only have sugar-jhbuild to run on. Is it 
possible for anyone reading this to download the basic frame and report 
if the 19x19 grid is usable?  You may find it at 
https://dev.laptop.org/git?p=projects/PlayGo;a=tree

Thanks

- Gerard