#4517 NORM Never A: The Sugar frame can't pop up when running etoys.

[Zarro Boogs per Child]

#4517: The Sugar frame can't pop up when running etoys.
-----------------------------+----------------------------------------------
  Reporter:  Takashi         |       Owner:  bert          
      Type:  defect          |      Status:  new           
  Priority:  normal          |   Milestone:  Never Assigned
 Component:  etoys-activity  |     Version:                
Resolution:                  |    Keywords:  killjoy?      
  Verified:  0               |  
-----------------------------+----------------------------------------------

Comment(by smcv):

 There are two models that could be followed for TakeScreenshot. Is it a
 request that could be waited for (a method), in which case its current
 name and implementation as a method are good, or is it an asynchronous
 event, in which case it should be a signal called something like
 ScreenshotCheckpoint?

 It appears that in this case, the shell has to wait for the activity to
 take the screenshot, so this needs to be a method.

 Edited transcript from #olpc-meeting (irrelevant messages mostly removed):

 {{{
 14:38 < marcopg> smcv does it make sense to consider some methods of a
 DBus
                  service optional? Is there a better way than just trap
 the
                  exception?
 14:39 < smcv> marcopg: um, context?
 14:39 < marcopg> smcv: the activity instance service has a TakeScreenshot
 method
 14:39 < marcopg> smcv: which the shell call when the activity can take a
                  screenshot of itself
 14:39 < smcv> marcopg: it's possible, but not a wonderful design
 14:40 < marcopg> smcv: only the shell knows if the window is covered for
 exampe
 14:40 < smcv> here's how I'd do it...
 14:40 < tomeu> hmm, perhaps we should have a Previewable interface?
 14:40 < tomeu> with only one method, though...
 14:40 < marcopg> smcv: the problem is that not all activities care about
 this
                  method, and forcing them to impl it (empty) sort of sucks
 14:40 < bertf> marcopg: shouldn't that actually be a signal?
 14:40 < smcv> option 1. have a Screenshottable interface with one method,
 and
               give the "base class" a method for capabilities discovery
 14:41 < bertf> marcopg: only interested activities subscribe to that
 14:41 < tomeu> hmm
 14:41 < smcv> Telepathy does this (Channel and Connection have about a
 dozen
               optional interfaces each, and a GetInterfaces() method in
 the
               common interface)
 14:41 < smcv> bertf: no, I don't think so
 14:42 < bertf> smcv: because it is not a broadcast?
 14:42 -!- uwogBB [n=uwog at nat.betterbe.com] has joined #olpc-meeting
 14:42 < smcv> option 2. have a method that everything implements, but
 using
               subclassing or something, arrange for it to raise a known
               exception (org.laptop.Errors.NotImplemented?) if the
 activity
               author doesn't override it
 14:43 < smcv> option 3. same as option 2, but instead of raising a known
               exception, it returns a known failure value. e.g. if we have
               TakeScreenshot ( void ) -> ay: bytes, then maybe the base
 class
               would return an empty byte-array to signify "no screenshot"
 14:44 < bertf> smcv: TakeScreenshot actually doesn't return anything
 14:44 < smcv> bertf: o rly?
 14:44 < rwh> can we try to stick to the agenda a bit and defer in depth
              discussions till later? I don't have too much time now and I
 think
              things get confusing rather quickly
 14:44 < smcv> oh, does it save it to the datastore? :-(
 14:44 < bertf> smcv: it's a hint to the activity that it might be a giood
 idea
                to take a screenshot now
 14:44 < tomeu> smcv: I think we cannot assume all implementors of the
 activity
                interface will subclass from the same class
 14:45 < tomeu> smcv: only most of the python ones
 14:45 < bertf> smcv: etoys has its own frame buffer so it does not care
 about
                this hint at all
 14:45 < smcv> tomeu: yeah, but it's presumably acceptable to have a slight
               increase in work done by the non-python ones...
 14:45 < tomeu> smcv: the meaning of the method is to signal the activity
 that
                it should take an screenshot now because it's a good moment
 to
                do so
 14:46 < smcv> if there's no return value, then it might be possible to
 make it
               a directed signal
 14:46 < tomeu> smcv: this is what we currently have
 14:46 < smcv> (yes, you can send directed signals)
 14:46 < bertf> smcv: the problem at hand is that Sugar breaks when an
 activity
                does not handle that method. Which is unacceptable.
 14:46 < tomeu> a signal looks better to me, as bertf suggested
 14:46 < smcv> but only if the sender of the signal never needs to know
 when the
               activity has finished sending that signal
 14:47 < smcv> unless success is indicated by a ScreenshotTaken signal, I
               suppose...
 14:47 -!- Xavi [n=xavi at host151.201-252-51.telecom.net.ar] has joined
           #olpc-meeting
 14:47 < tomeu> smcv: hmm, I think we want to wait blocking for a small,
 fixed
                amount of time
 14:47 < tomeu> marcopg: the plan was for the shell to wait for 0.05-0.1s.
 so
                the activity had time to take an screenshot?
 14:48 < marcopg> yeah the call needs to be blocking :/
 }}}

 The option I didn't outline there was:

 Option 4. Make sure every caller of this method treats errors as non-fatal

 and I think this is what marco is asking for. This should be done in any
 case, to defend against activities that don't work or have hung.

 The method should be called with a small timeout, and errors should not
 cause failure: perhaps something like:

 {{{
 try:
     activity.TakeScreenshot(timeout=0.1)
 except DBusException, e:
     logger.debug('ignoring error raised by TakeScreenshot(): %s', e)
 }}}

-- 
Ticket URL: <https://dev.laptop.org/ticket/4517#comment:2>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system