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:
- Bert -
--> peace (~4613a7e8@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@hubble.immuexa.com) has joined #etoys <bertf> you're on Eastern time right? <bertf> Hi Karl <karlram> hi --> Ted_Kaehler (~48c167b2@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@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@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