> > 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. > > This is not the functionality that I interpreted from Bert's comment: > > > > I thought this was intended to be a feature similar to the frame (and > > actually summoned by the frame key), layered on top of the activity, > > so it actually would work for *all* activities, Python or not. > > > > - Bert - > > > > I may be wrong in interpreting the ubiquitous chat interface as a full > > screen overlay on top of the application where the child must either > > chat into the overlay or switch modes to play the game. Are you > > suggesting that the ubiquitous chat can be relegated to its own panel on > > the activity's screen so there is no mode switching between chat and the > > "underlayed" activity 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. > > Would either of the two (or more) participants > > in the activity be able to mute observers? I find both of these > > functionalities fundamental to the activity experience and the tutored > > activity experience. This is an absolute fundamental requirement to any audio/video chat, in my opinion, for the sake of privacy. This requirement needs to make it into the HIG. > > Also, being that most of the video processing is offloaded in the Geode, > > I look forward to morphing the chat panel into a video call to my Go > > opponent. The PlayGo application takes very little resource, so there is > > plenty of ommf left over to run the video call. It would be the next > > best thing to playing in the same room. 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. - Eben _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
