Hi all,

participance is ramping up again :) We talked about a variety of issue, including

* feature freeze has been extended to this weekend by the Sugar folks:
  http://wiki.sugarlabs.org/go/0.90/Roadmap
* what changes to include before alpha release
* in particular, contributions by Jerome and Ricardo
* how to get QuickGuides working

Full log below.

Hope to see you next Monday, at 12 noon Squeakland Time as usual:

	http://tinyurl.com/34k9xmx

- Bert -

--> peace (~4613a7e8 at hubble.immuexa.com) has joined #etoys
<bertf> ah ... jerome?
<peace> yep
<bertf> nice to see you :)
<peace> good to finally get the timing right
--> karlram (~51aa9a20 at hubble.immuexa.com) has joined #etoys
<bertf> you're on Eastern time right?
<bertf> Hi Karl
<karlram> hi
--> Ted_Kaehler (~48c167b2 at hubble.immuexa.com) has joined #etoys
<peace> 3pm dst
<karlram> it's been a slow summer with little etoys work form me
<bertf> well, for all of us it seems :)
<karlram> :-)
<karlram> how was etoys camp
<bertf> I have only started again this weekend
<karlram> any feedback
<bertf> squeakfest was small but nice
<karlram> whats left to do before realease ?
--> ritaf (~ritaf at mgdb-4db8daa8.pool.mediaWays.net) has joined #etoys
*** Mode #etoys +v ritaf by ChanServ
<bertf> well, actually bundling up everything
<ritaf> hi
<bertf> like the translated quickguides
<peace> what stage is the release in. Whats frozen? What can be added/fixed?
<bertf> ritaf: karlram asked about feedback from Squeakfest
<karlram> we add buf fixes
<karlram> bug fixes :-)
<bertf> peace: no big changes anymore, no new features. it's "feature freeze"
<peace> ah/ can that include retargeting of sliders and buttons?
<ritaf> karlram: bert told us how to submit bugs,
<bertf> peace: yes, that code has long been written so can still get in
<ritaf> and the educators want help testing new versions
<ritaf> we also talked about Richos work, it would be great to have some of his things in the new version.l
<peace> that will be good. it will open up large possibilities.
<bertf> peace: also, the freeze is not absolute. if we feel an imporvement is high impact and low risk we can still take it in
<bertf> it's just that we should not add big new untested features right until the release is out
<peace> Well, the other thing in that category is some patches to the current gif reader
<bertf> well bug fixes can get in longer than features
<karlram> peace: I added quite a few of your gif fixes
<peace> karlram: cool
<bertf> peace: we're following the SUagr release cycle, as OLPC is our largest user base: http://wiki.sugarlabs.org/go/0.90/Roadmap
<bertf> s/SUagr/Sugar/
<karlram> peacew:http://tracker.squeakland.org/browse/SQ-597
<bertf> peace: have you tried a current dev version?
<bertf> Ted_Kaehler is working on bringing the QuickGuides in
<peace> bertf: thats a good question. I think I've downloaded one but not unpacked it. Nor played.
<karlram> quickguides will be nice :-)
<bertf> peace: at least soem of your stuff is in
<peace> it's good to here about the anigif patches. The targeting stuff would be enough for this round.
<karlram> ritaf: nice if educators con help test stuff and give suggestions
<bertf> I'd like the smooth curves to get in (SQ-211)
<ritaf> I was thinking if we should add a link to the beta-version on the downloads page
<peace> eventually I would like to see the new anigif stuff get in. With that I can pretty well render most gifs on the web.
<ritaf> then anyone can easily find and test the beta-version
<bertf> ritaf: yes, once we have it. we're jsut figuring out what needs to be done to make an alpha/beta release
<bertf> so far there are only developer versions of 4.1, not for users
<karlram> SQ-211 is quite big and a little too late for release ?
<bertf> nah, if you look at the roadmap the Sugar folks changed feature freeze to Aug 16
<bertf> That's the enxt weekend
<karlram> Ok :-)
<bertf> usually people get more active when freezes are over, which is one point of having them ;)
<karlram> peace: are you using Monticello now ?
<bertf> so we need to collect stuff that has been implemented, and push it. and get all missing bits in place.
<peace> for a very few things. My mc-fu is quite small.
<karlram> peace: it can grow fast :-)
<bertf> peace: we also take changesets, but MC is less work for us
<ritaf> did richo put more things in the inbox? we would like tpo have graphing and bubbles in the next version
<bertf> yes that's in the onbox
<bertf> inbox
<ritaf> that's what the educators would like to have
<bertf> however, I have not heard feedback from the other developers
<bertf> I looked at it and did not like the code very much
<peace> the changesets for the targeting stuff exist.
<bertf> scottwal: did you have a look?
<scottwal> sorry, did not.
<bertf> scottwal: the issue I see is that there are a lot of Player subclasses
<bertf> basically, a new Player for each new Morph
<bertf> do you think that could be a problem down the road?
<scottwal> Doesn't Kedama also have a lot of custom Player subclasses?
<scottwal> Oh, I see, different issue.
<scottwal> It's just the proliferation of uniclasses, "whether needed or not"?
<bertf> actual classes
<bertf> when a user substitutes a receiver in a script with a different player, it will break. The canonical way is to add the methods to a single player, and then check if the costume is the one you expect.
<bertf> we used to have all methods for all different morph just in Player I thought
<Ted_Kaehler> Not sure what you mean.
<bertf> karlram: have you looked at it by chance?
<scottwal> yes, except for KedamaExamplerPlayer, KedamaTurtleVectorPlayer etc.
<bertf> Ted_Kaehler: when you use a tile specific to say Sketch and then change the receiver to a Holder it will still work
<bertf> because all tile methods are implemented in Player 
<Ted_Kaehler> A holder containing a sketch?
<bertf> no. just replaceing the receiver tile with some other player
<scottwal> so certainly we've always strived to have a "single root player class" rather than custom explicit Player subclasses, for just the reason Bert says...
<Ted_Kaehler> yes, as long as the methods are really in Player.
<scottwal> Does Dr Geo have idiosyncratic Player subclasses
<scottwal> ?
-*- bertf looks
<bertf> scottwal: no, it adds methods to Player
<scottwal> so unless there's a good reason in the code in question to have Player subclasses, probably it's better not to.
<bertf> There are only two non-Kedama Player subclasses specific to a Morph
<scottwal> (However, the "power of working code" might be a good reason.)
<bertf> that's CardPlayer (for stacks I assume) and Component (Fabrik?)
<scottwal> right.  both of them dead ends...
<bertf> but they had good reasons to extend the Player model
<scottwal> yes
<bertf> to subclass it I mean
<scottwal> right
<bertf> in Richo's code I don't see a good reason.
<bertf> guess I;ll have to send an email :)
<bertf> also, he added #to:
<scottwal> #to: to what?
<bertf> Point
<bertf> which could have any number of meanings IMHO
<scottwal> and which meaning did he implement?
<peace> bertf: does it mean the difference between two points?
<bertf> I'll have to look again, sec
<bertf> no, it creates an instance of Vector
<scottwal> yikes
<bertf> which is a new class jsut holding two points. then there is a VectorMorph as subclass of PolygonMorph
<bertf> used for line segments in charts I think
<bertf> the points on a chart are a SketchMorph subclass
<bertf> so there is a PointMorph and a PointPlayer. IMHO it's better to just use exostign classes
<scottwal> bertf:  your advice about coding is always graciously given and always well taken.
<peace> bertf: PointMorph is an important missing concept.
<bertf> too bad we did not really point out the implementaion flaws earlier
<Ted_Kaehler> about Quickguides...
<bertf> peace: how so?
<scottwal> is it really too late?
<bertf> scottwal: no, but because nobody complained, he used this style throughout his work
<bertf> Ted_Kaehler: yes?
<peace> bertf: things get built out of points, Morph skiped that and started with rectangles. Bug abound.
<Ted_Kaehler> I have etoys-dev 2379, Jun2010, then fully updated, and Quickguides do not work.
<Ted_Kaehler> The index page shows, but no buttons work there.
<Ted_Kaehler> It may be the new index translating code.
<Ted_Kaehler> Any hints before I plunge in to find out what is wrong?
<bertf> Ted_Kaehler: I get an error in makeCategoryMenu:
<Ted_Kaehler> yes.
<bertf> Ted_Kaehler: but I have not looked deeply yet
<bertf> PagesForCategory should have been filled
<Ted_Kaehler> yes.
<bertf> maybe because the index.txt is missing?
<Ted_Kaehler> that's a good hint.
<peace> bertf: meant bugs abound.  From the center handle never staying in place to poor bounds tracking for tilted morphs.
<Ted_Kaehler> Is there one available, or do I need to create it?
<bertf> OTOH neither buildDefaultIndex nor loadIndex is called
<bertf> peace: agreed. though that's not what Richo's PointMorph is about
<Ted_Kaehler> those may be at prep-time only.
<bertf> Ted_Kaehler: I think you need to make it yourself
<bertf> I hope Korakurider will chime in soonish :)
<Ted_Kaehler> yes
<peace> bertf: yes. But iirc Ricoh was making something work in its own domain. So he made stuff for that. Integrating into the general system is now the problem.
<bertf> peace: precisely
<bertf> I'll also point out that for general inclusion, GSoC is not a good class name prefix
<bertf> also, some more stuff is sitting in the inbox
<bertf> like my timer code
<bertf> and a morph drop handler
<bertf> and karlram's world geometry tiles
<bertf> any opinion on these?
<Ted_Kaehler> Is there an easy way to make all fonts smaller in the dev image?
<bertf> Ted_Kaehler: I guess you want to disable screen scaling, and then there is a doit, let me check
<bertf> hmm, no. you could change the sizes in restoreDefaultFonts and execute the doit
<Ted_Kaehler> no scaling helped.
<Ted_Kaehler> There sure seems to be some code missing for the Guides.  How did this get in with no testing?
<bertf> we are abut to test now
<bertf> about
<Ted_Kaehler> ok.  certainly buildDefaultIndex needs to be called.  I'll be quiet now and see what I can do.
<bertf> no need to be quiet, but thank you for looking into it :)
<bertf> karlram: did you look at the Camera code by chance?
--> hilaire (~hilaire at bon74-1-88-184-136-97.fbx.proxad.net) has joined #etoys
<bertf> well, okay. let's continue by email. Thanks everybody for stopping by! See you next week, same time!
<hilaire> ah, just in time
<bertf> hilaire: hey, what's up? :)
<hilaire> not mutch
<hilaire> Arriving at the end :)
<bertf> did you get any more feedback on your xo bundle?
<hilaire> not directly to the bundle
<hilaire> but a math teacher involved in XO for Philippine contacted me
<hilaire> just to say thank you
<hilaire> John Sincak
<bertf> nice :)
<Ted_Kaehler> Execute (QuickGuideMorph buildDefaultIndex), then open the guides, and they work.
<bertf> hilaire: do you think you could make an example project for us explaining a bit about Dr Geo?
<hilaire> The work on DrGeo with a feature complete UI was really badly need, and I am glad I did it.
<bertf> yes, looking forward to have that in etoys too :)
<bertf> Ted_Kaehler: the english ones I guess. All of them?
<hilaire> bertf: I can, but someone else should do it. I don't mean people from Squeakland, but people already using it.
<bertf> hilaire: if you get someone else to do it, sure. must be MIT though, not GPL
<hilaire> I see in the web use cases of DrGeo in south america, but when I ask feedback I receive none.
<bertf> that's the same everywhere
<ritaf> hilaire: the feedback is always a problem
<bertf> are you using Firefox?
<ritaf> hilaire: do you remember names of people using it?
<hilaire> the people should get educated to feedback and giving back also
<hilaire> ritaf: no, I saw in a page a big poster full of DrGeo use case
<bertf> Anyone using Firefox should give the Firefox developers feedback. Few do.
<hilaire> ritaf: http://community.ofset.org/index.php/File:Drgeo-ceilbal1.jpg
<hilaire> ritaf: it is from ceibal
<ritaf> this is ceibal, I'll ask Carlos
<hilaire> ritaf: yes, I am curious