[etoys-dev] Etoys developer chat log

karl ramberg karlramberg at gmail.com
Thu Jun 10 17:27:14 EDT 2010 

On Thu, Jun 10, 2010 at 11:18 AM, Derek O'Connell <doc at doconnel.f9.co.uk>wrote:

> Sorry I missed this weeks mtg. I hope to put spend some more time on
> WebCamMorph this weekend...
>
>
>  * also camera support hopefully, need to simplify interface
>>
>>
>
>  <bertf>  karlram: the current one has too many controls. we should put in
>> just the bare minimum and then see what people find missing
>> <bertf>  but having camera support on all platforms would be awesome
>> <karlram>  Sounds good
>> <karlram>  Many of the controls are a bit hard to understand :-)
>>
>>
>
> Last weekend I added help text to both the SqueakSource wiki and in the
> class comments. If these are not enough then let me know.
>
> WebCamMorph started off as a simple demo of how to use CameraPlugin class
> and any further development was really just me satisfying my own curiosity.
> If it does not satisfy Etoys educational needs then feel free to chop it up
> as you see fit. Alternatively give me a clear idea of just how simple you
> want it and I will see what I can do. The simplest version I can think of is
> no control over resolution/fps/etc and just a single "capture" command
> (including display update). To me this seems too simply though because we
> are dealing with a video camera and not a common digital camera used to take
> snapshots. The two have different purposes and work differently as a
> consequence and the current controls in WebCamMorph are simply a reflection
> of that.
>
> -D


I guess how one wants to use the webcam is the deciding factor.

As you said these are the most basic needed:

Camera is on  [true/false]
Camera last frame (as from old camera morph)

To capture motion one can just have a ticking script adding Camera last
frame to a holder.

This would be very rudimentary

How to show more features and what features are needed for etoy use must be
discussed.

As Bert said before, once added, features are hard to remove without
breaking compatibility.

Karl












>
>
> On 07/06/10 21:26, Bert Freudenberg wrote:
>
>> We had a chat again:
>>
>> * Etoys will follow the Sugar release schedule:
>>   http://wiki.sugarlabs.org/go/0.90/Roadmap
>> * should prepare a first alpha release in June, with translations and
>> DrGeo for wider testing
>> * also camera support hopefully, need to simplify interface
>> * there is a decompiler problem, possibly because of Eliot's changes
>> * multi-touch working pretty well on iPad now
>> * need idea about how to debug missing mouse-overs
>>
>> Full log below, as usual. And see you next Monday, same time:
>>
>>        http://tinyurl.com/2bjpzbe
>>
>> - Bert -
>>
>> <bertf>  hi karl
>> <karlram>  hi
>> <karlram>  not maye here
>> <karlram>  many
>> <bertf>  yep
>> <bertf>  busy, hopefully ;)
>> <karlram>  he he
>> <karlram>  I had some issues with a ehancement I integrated
>> <karlram>  enhancement
>> <bertf>  the broken viewers?
>> -->  hilaire (~hilaire at bon74-1-88-184-136-97.fbx.proxad.net) has joined
>> #etoys
>> <bertf>  ah, hi hilaire :)
>> <karlram>  jup , it added all sort of stuff to variables categorie
>> <hilaire>  hello
>> <karlram>  hi
>> <bertf>  do you think it's okay now?
>> <karlram>  It was a one line fix
>> <bertf>  good
>> <bertf>  hilaire: thanks for submitting dr geo :)
>> <karlram>  But images must get past the bad fix without opening a
>> viewer....
>> <bertf>  I wouldn't worry too much abouht that
>> <karlram>  Ok
>> <bertf>  we're just a handful people updating regularly  I think
>> <karlram>  you are right
>> <bertf>  do we need a do-it to fix it, if someone loaded the broken
>> version?
>> <karlram>  I had another issue
>> <karlram>  deleting a etoy variable seems broken
>> <karlram>  when  the variable is part of a etoy script
>> <bertf>  hmm. that should be a blocker ticket
>> <bertf>  just so it is not forgotten
>> <bertf>  you mean when the var is already used in a script?
>> <karlram>  I'll add it, the Decompiler complains about some issues
>> <bertf>  ah. might have to do with eliots changes then
>> <karlram>  Should I notify Eliot ?
>> <bertf>  wouldn't hurt
>> <karlram>  Ok
>> <bertf>  in any case, we should commit to a release schedule. I think
>> adopting the Sugar one makes sense
>> <karlram>  and sugar release is ?
>> <bertf>  a July release would be too rushed
>> <bertf>  I sent mail about that, give me a second to find it
>> <bertf>  http://wiki.sugarlabs.org/go/0.90/Roadmap
>> <karlram>  July seems very close
>> <bertf>  right. september sounds sensible
>> <bertf>  we still should try to get an alpha release out asap
>> <bertf>  including dr geo and the new translations
>> <bertf>  so more people can test that stuff
>> <karlram>  Sound good
>> <karlram>  dr geo is big , in many ways
>> <karlram>  :-)
>> <karlram>  a huge framework
>> <karlram>  and lots of classes
>> <karlram>  and lot and lots of new stuff to learn :-)
>> <bertf>  indeed
>> <bertf>  but if we can get the fonts out of the image, we still will have
>> a smaller image even with dr geo included
>> <bertf>  richo started on that
>> <bertf>  he pushed Andreas' font loader code
>> <bertf>  maybe we should start freezign features a bit earlier than the
>> Sugar schedule ...
>> <bertf>  hilaire: did you want to talk about somethign specifically?
>> <karlram>  what about the camera morph stuff ?
>> <karlram>  wait another release to mature?
>> <hilaire>  bertf: no
>> <bertf>  karlram: no I think it would be a nice feature to have
>> <bertf>  karlram: but I would start simple
>> <bertf>  hilaire: okay. thanks for stopping by :)
>> <bertf>  karlram: the current one has too many controls. we should put in
>> just the bare minimum and then see what people find missing
>> <bertf>  but having camera support on all platforms would be awesome
>> <karlram>  Sounds good
>> <karlram>  Many of the controls are a bit hard to understand :-)
>> <bertf>  yeah
>> <hilaire>  I need to rest
>> <hilaire>  bye
>> <karlram>  ye
>> <karlram>  bye
>> <hilaire>  add a hard time with students today..
>> <-- hilaire (~hilaire at bon74-1-88-184-136-97.fbx.proxad.net) has left
>> #etoys
>> <karlram>  Students are not always what you want them to be :-)
>> <karlram>  I sent a mail to Eliot about
>> http://tracker.squeakland.org/browse/SQ-710
>> <bertf>  thanks
>> <bertf>  I got multitouch workign this weekend :)
>> <bertf>  on the iPad
>> <bertf>  you can draw with more than one finger, or move multiple objects
>> at once
>> <bertf>  pretty cool
>> <bertf>  now if you also could rotate and scale them with two fingers that
>> would be awesome :)
>> <karlram>  Oh, sound cool
>> <bertf>  And now that I compiled the VM with enabled optimizations it's
>> even quite usable ;)
>> <karlram>  I remember some issues with mouse over states from earlier
>> touch based computers
>> <bertf>  I was using it without optimizations for like two weeks .. was
>> rather slow
>> <bertf>  yes, some things rely on mouse overs
>> <bertf>  e.g. the color selector in the paint box
>> <bertf>  I'd have thought it goes away on mouse-up, but apparently noe
>> <bertf>  not
>> <bertf>  hmm. your Etoys-kfr.19 looks identical ...
>> <karlram>  I was fighting mouse over issue with SelectionMourh, very
>> annoying....
>> <bertf>  but there is no diff
>> <bertf>  no changes
>> <karlram>  Hm, very weird, my image had the wrong method still
>> displaying...
>> <karlram>  I got confuced...
>> <karlram>  confused
>> <karlram>  lol
>> <bertf>  always check changes before committing
>> <karlram>  I know
>> <karlram>  Back to the mouse over issues, do you  know a good way to debug
>> them ?
>> <bertf>  I'd simulate at touch event
>> <bertf>  that is, filter out all mousemove events that have button=0
>> <bertf>  so you only get mouse down, move, and up, but no moves after
>> mouse up
>> <bertf>  that should recreate the problem  on a normal machine
>> <karlram>  ok
>> <karlram>  ipad is not a very fast machine ?
>> <bertf>  karlram: it feels very fast
>> <bertf>  just not in etoys
>> <bertf>  for Etoys it's about the XO-1 speed I would say
>> <bertf>  so not great but usable
>> <bertf>  okay, thanks for chatting, I'll send the log as usual
>> :)_______________________________________________
>> etoys-dev mailing list
>> etoys-dev at squeakland.org
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>>
>>
>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100610/f4e51d6d/attachment.html

More information about the etoys-dev mailing list