Talk:Activities/Physics

Roadmap

• Keep UI clear and simple!
• Fix 1777 and 1194
• Migrate code to SugarGame
• Add paint daub feature
• Add and make roll tool more realistic?
• Add Rocket motor?
• Expose material selection in the UI
• Add custom cog drawing tool to allow experimentation with gear systems

Future (?)

• Allow (some) motor/force/object to be triggered on/off
  • keyboard events (perhaps limit to 0-9 digits?)
  • collision sensitive object/button

Suggestions

I wonder if it would be possible for you to add the option of gas/liquid elements as well as heating/freezing devices ?( (i.e. for gas extraction simulation, steam engine etc.) --Dominik

IRC Physics chat on #sugar-meeting Friday 17th July

You join #sugar-meeting

asaf joins #sugar-meeting

<garycmartin> asaf: Hi!

<asaf> garycmartin: Hello!

<garycmartin> bjordan: ping, you about?

<garycmartin> asaf: finally, realtime chat, you get to experience my bad spelling and typing first hand :-)

<asaf> I have nothing to bragg about :-P

<asaf> do you think we should wait a little for brian?

<garycmartin> asaf: how are you for time? We can wait a little if it's ok with you, though Brian didn't reply to my email about the meeting today.

<asaf> I'm in no hurry. I can be here for about 3 hours or maybe more.

<garycmartin> bjordan: ping, ping :-)

<asaf> should we wait 10 more minutes?

<garycmartin> asaf: No it's half past, I think he was not able to make it.

<asaf> ok, lets begin

<garycmartin> Any one eles here to chat about Physics?

<garycmartin> asaf: so how painful is the work you're looking at for file format. I must say pickleing is working great for me, I'm just worried the format may well break with a future cersion of box2d

<asaf> Is not that bad

<garycmartin> asaf: mind if I start a meeting, can then post the logs?

<asaf> the difficult part was to learn where to put it and how everything fits toghether

<asaf> ok

<garycmartin> #startmeeting

<garycmartin> hmmm....

<asaf> actually I'm almost done with having the file format with json

daveb joins #sugar-meeting

garycmartin will copy paste meeting text, the meeting bot seems to have died.

<asaf> I can save all de bodies and I just have to add the joints to get the same functionality as we got with pickling

<garycmartin> asaf: Cool, that great news. I thought json was going to be a pain to get going.

<asaf> what I'm worried about is that if we add new features we have to be carefull to see what has to be added to the savedata

<garycmartin> asaf: new features where? Physics or Elements (I take it you don't touch box2d)?

<asaf> you're right, I don't touch box2d

<asaf> and I'm not sure if we should add them in Elements or Physics

<garycmartin> asaf: Had a email from Gabriel Eirea with a nice feature request from her son (who really likes Physics), asking for 'rocket motors' :-)

<asaf> right now the save/load code is in physics.py but maybe I't could fit with elements

<garycmartin> asaf: what features have you been considering?

<asaf> that is a good idea, I didn't think about it

<asaf> well, first of all is to change the motor for an unpinned roller

<asaf> like the one you expected the first time you used it

<garycmartin> asaf: rocket motors, yes it the directional force 'tool' a little like the torque rotation one I talked about early on after you added the pin and pinned motor.

<asaf> and I know now how to implement them :)

<garycmartin> asaf: moter, so if you wanted a 'driven, pinned wheele' you need to both pin it first and then apply a moter property to it?

satellit joins #sugar-meeting

<garycmartin> asaf, cool! :-)

<asaf> yep, that sounds good

<asaf> so I think we agree to keep Physics as a playground type of thing

<garycmartin> asaf, I could even add some smoke trails and sparks for rockets ;-)

<asaf> yes, that was my next suggestion

<garycmartin> asaf: playground, yes. That also seems to be what I'm seeing in comments I'm reading from others.

<asaf> you mean something you stick to a body and it leaves a trail

<asaf> ?

<garycmartin> asaf: well, I like the idea (educational +) that you could "daub" some paint onto an object (attach a point to a shape) and it would then leave a trail behind (just a fixed length tail long enough to be useful in watching paths of motion).

<garycmartin> asaf: perhaps think of it like the streamer ribbons some dancers user.

<asaf> that sounds nice

<asaf> the next thing I thought about is drawing the velocity vectors of things

<garycmartin> asaf: re:rocket smoke. That was more just a fun/joke idea, but I'm sure kids would love it.

<garycmartin> asaf: velocity vectors. Yes, I've been thinking about a grid 'overlay' as well. perhaps velocity vectors could be considered another 'overlay'. Perhaps 'stress' as well (if tiy look at the Bridge activity they change the colour of objects based on stress so you can see which part is about to fail).

<asaf> I think that stress doesn't have an important role right now, maybe if we make things breakable

<garycmartin> asaf: what do you think of having some custom "backgrounds", with the ability for a kid to add their own (Paint then import image). The "backgrounds" would be just visual wall paper, but could be used to suggest goals/projects.

<garycmartin> asaf: stresses/breakable, yes good point, maybe something for laater.

<asaf> I imagined a starfield background in which we add a solar system with the activity

<garycmartin> asaf: "backgrounds" could also be a way of implementing the grid, it's just a pre-defined image.

<asaf> I thought of drawing velocity vectors to make easier to build a solar system

<garycmartin> asaf: what would be really cood for backgrounds is if "paint daub trails" were written to it, so they could be infinate/perminant.

<garycmartin> asaf: backgrounds could then also be saved back out as images so kids could create trails of motion and use them in other work.

<asaf> so while the activity is running you only see a finite trail but in the background keep the whole history?

<garycmartin> asaf: don't we have the wrong type of gravity (Galileo?) for a solar system. It's parallel to a ground surface, not rounded for a body.

<asaf> I haven't said it but I think we should add a "force center" tool

<garycmartin> asaf: finite trail, no if we had writable backgrounds we would just use it instread of trying to draw longs paths. I was thinking a bakground image could be used as the clear screen blit, if it's fast enough...

<asaf> and since we'll add the ability to turn of gravity we could achieve it that way

<garycmartin> asaf: force center, yes for replusion and attraction type things.

<garycmartin> asaf: yes, a toolbar icon for "world" could have some global settings in it.

<asaf> yes, I think that will add a whole new dynamic to the activity

<garycmartin> asaf: I'll be trying to keep such settings hidden inside pop-up palettes, and have a minimum of new user interface buttons so we don't scare folks with complexity.

<garycmartin> asaf: so hovering over the box tool would expose extra settings for material type, but a kid could just click on the box icon and get the default.

<asaf> The problem I see with layering the interface is that once you get a hold of it would be slow to be changing tools

<asaf> I also think that object properties should be modifiable at runtime

<asaf> not necessarily at creation

<garycmartin> asaf: Hmmm, I worry about complexity. The mental modle of changing the property of something you've already created is quite expert.

<asaf> hm. we have a dilema

<asaf> If you modify it at runtime it easier to experment with the effect of different materials

<asaf> for example, if you build a contraption and change the material of a single piece

<garycmartin> asaf: was just looking for that other physics sim tool (I sent your some gifs from it), it allowed all that kind of introspection of object properties but ended up looking like a cadcam pro tool.

<asaf> ah, yes, I think I installed somewhere, it seemed complicated

<daveb> yeah i think delete/add new type of object makes sense

<garycmartin> asaf: Mecanimo, found it :-)

<asaf> how will the toolbar look in each case

<asaf> ?

<asaf> the circle tool will have sub tools such as rock/wood/helium ?

<garycmartin> asaf: I can generate some mock-up. But I was thinking a little like Paint. Where you can just click the Brush tool and get the default/last set, or if you hover or right click, you get a larger palette with different options.

<garycmartin> asaf: circle tool. yea, something like that.

<garycmartin> asaf: one thought...

<garycmartin> asaf: you were after a 'selection' tool I think. If it's possible, how about the "grab" tool becomes a "select/manipulate" tool (works just like grab does now), but it's palette could have all the objects properties in, for modification if needed?

andresambrois leaves: Remote closed the connection

<garycmartin> asaf: (so the last thing you 'grabbed' would be the current selection)

<asaf> by "it's palette" you mean it's sub menu?

<garycmartin> asaf: That keeps all that detail out of the way unless you want to start tweaking :-)

<garycmartin> asaf: yes all the current "sub menus" are gtk+ palettes, at least that's what I believe :-)

<garycmartin> asaf: the new toolbar designs (if accepted) will also give us more options. Currently tabs are not accessible enough for kids, the new desigs could have a secondary toolbar you could click lock open displaying properties for easy edit (could do that now with a tab I guess)

<asaf> i'm worried that that will require to many clicks and it wont be agile to work with

<garycmartin> daveb: Yea I think delete/add is going to be 90% of our target user behaviour. Though I guess it's that 10% minority that may be doing the really cool stuff :-)

<daveb> more like real aphysics, unless you have some serious equipment its hard to modify the material of an object :)

<asaf> In my proposal we could have a select tool and add another toolbar in the bottom to modify properties

<asaf> maybe we could hide the toolbar in the bottom to simplify the g\u00fci

<asaf> arount what school grade is the target audience?

<garycmartin> asaf, too many clicks is a fair and valid point :-) I'm just not sure that's how most of our target users will use Physics. As Simon noted, some younger kids have dificulty even with dragging the mouse to size an object. We should strive to keep it looking like a simple paint program

<asaf> are they the main user group?

<garycmartin> asaf: we have 6-10yr olds +/-2 depending who you ask! Of corse it works for older kids but they can cope with more complicated current desktops.

<garycmartin> asaf: the 'rocket moter' feature request came from a 7yr old :-)

<asaf> hm, I see

<garycmartin> asaf: I think Simon is currently working with 7-8-9yr olds

<asaf> Isn't it simpler to have the property modifier hidden than to have many submenus?

<asaf> are you thinking on being able to modify the world gravity?

<garycmartin> asaf: in my mind, I see each tool having several associated properties in its palette, so each palette is specific to the tool. So the Motor drop down palette would have clockwise/anti-clockwise, strong/weak/medium; the Circle tool drop down palette would have colour, stone/wood/rubber/helium; the World tool drop down would have background image, gravity.

<garycmartin> asaf: (is there a world 'friction' to simulate air density/viscosity?)

<asaf> I think it is asociated to each body but we could modify them all at once

valhalla joins #sugar-meeting

<garycmartin> asaf: If we added a Selection tool button, its dropdown palette could list all the currently selected objects properties for modification. But I'm not sure how common this will be used (but it is a nice 'high ceiling' feature for advanced users)

<asaf> so if you wanted to create a clockwise strong motor you first select clockwise motor and then select strong and after that you create the motor?

<garycmartin> asaf: yes, you'd right click or hover over the Motor button, its details palette would reveal, you'd click on the change of options you want (it's not a menu so it stays oper while you tweak settings) and then you move the cursor away to the canvas area and start adding objects.

<garycmartin> asaf: the palette keeps state so it stays with those settings until you next change them again. I want 5 helium baloons, 3 rockets, and a rubber box. Please. ;-)

<asaf> I still think we should do it the other way. If you wanted to modify the direction of a motor you'll have a problem

<asaf> but mabye we shoudl think about this

<garycmartin> asaf: :-)

<asaf> we still have many things to do before we get to this point

<garycmartin> asaf: With a "Selection/Grab" button, you'd just need to click on the object and then reveal the Selection/Grab button palette. The the properties would be there for modification.

<asaf> just to be clear, in your scheme you are not considering modifying a motors direction are you?

<asaf> hm, so I don't get it

<garycmartin> asaf: modifying moters direction. Yes, if we make a current Grab tool, a Grab/Select tool, It's palette could then be used to display all the selected objects properties. But I do think this is an advanced users tool, 90% of the kids will likely never use it without guidance. And it's rather complicated to implement I'm guessing :-)

<asaf> what you are saying is that we should have the sub menus and also a property editor palette?

<garycmartin> asaf: think of your proposed property editor user interface at the bottom. Now just take whateve controls you were going to put in that UI and put them in the palette of the grab/select tool. They stay out the way so as not to complicate the UI, unless you want to make a modification.

<asaf> ok

<asaf> I think I get it

<asaf> I'm still worried about the ease to experiment

<garycmartin> asaf: I think I should make a mock-up, I think we are both talking about the same features just presenting them in a different way (you want an upfront custom palette always on screen, I want to hide them one layer down in a toolbar menu so as not to scare folks and use existing Sugar designs

<asaf> yes, I think that's it

<asaf> I rather have a hideable toolbar on the side or at the bottom

<asaf> but I think we are talking about the same thing

<asaf> ok

bjordan__ joins #sugar-meeting

<garycmartin> asaf: We could put your palette idea in as a toolbar "Properties" tab, that way you could switch to that tab and perminantly see the edit property edit controls. With a custom properties palette down in the main canvas it's getting fairly non Sugar standard and is eating into the main user interface canvas area.

<bjordan__> hi asaf, garycmartin

<garycmartin> bjordan__: Hey, you made it ;-)

<bjordan__> sorry I'm late, I think I did some mental time conversion math wrong :-p

<garycmartin> bjordan__: and have missed a great chat with asaf!

<garycmartin> bjordan__: I'll copy this thread and put it on the wiki Physics talk page

<bjordan__> garycmartin: thanks!

<garycmartin> bjordan__: (the meeting bot seems to be dead, maybe someone didn't stop the last meeting)

<asaf> Hi brian

<bjordan__> any questions I can still help with at this point?

<bjordan__> hey asaf

<garycmartin> bjordan__: So the big news is that asaf is close to having json working! :-)

<bjordan__> that's great!

<satellit> I just saved it as txt from Xchat if needed

<garycmartin> satellit: thanks, I'll take another copy at the end for the wiki.

<asaf> I'm a bit worried about adding new features to the activity

<garycmartin> asaf: how so?

<asaf> when we add new features we have to be careful to think if we have to add more data to the save file

<garycmartin> asaf: so by "new features" you mean new object types in the world?

<asaf> yes

<asaf> like a rocket motor or a rolling ball

<garycmartin> asaf: are force and torque generators not already part of box2d?

<asaf> although if I add support for Controllers that kne just told me about we may not have any problems

<asaf> the problem is that what i'm doing right now is getting SOME properties of the bodies and storing them

<asaf> for now I have enough information to restore the world but I'm not sure if that will be true in the future

<garycmartin> asaf: ahh ok. Well that's also good :-) That's the step that gives us control of the save format so future format changes can be managed.

<asaf> I think that if I add controller support and we implement new features with them we'll have no trouble

<garycmartin> asaf, cool, did kne cc: the rest of us on the Controler feature?

garycmartin goes to look at email

<bjordan__> sounds like it should ensure backwards compatibility

<bjordan__> great!

<asaf> I think so, he put it in the ticket

<garycmartin> asaf: OK, I get all those so it's in my inbox :-)

<asaf> FWIW for each body i'm storing its position, userData, angle, angularVelocity, linearVelocity and shapes it's attached to

<asaf> if the shape is a circle I store radius, density, restitution, friction and position relative to body

<asaf> if the shape is a polygon I store the same stuff but insted of radius I store vertices

<asaf> That for now takes care of everythin drawn, I still have to take care of joints and controllers

<garycmartin> bjordan__: so was there anything specific you had on your mind that you wanted to cover?

<garycmartin> asaf: thanks, I take it userData, is a 'black box' of items, perhaps colour?

<asaf> yes, right now it only has color

<asaf> I may add an object ID to make things easier

<garycmartin> asaf: OK.

<bjordan__> garycmartin: nope, nothing specific for this meeting. on my end, I'm working on making single-click default shapes and getting the new libraries integrated in a sane way

<garycmartin> bjordan__: cool, those were the items I was going to ask you about :-)

<bjordan__> one question re: default shapes, do we have it always create a standard medium-sized shape, or randomly generate a size?

<garycmartin> bjordan__: Have you tested yet if the new box2d has stopped crashing with small objects? If that's fixed that could simplify the tool logic quite a bit.

<garycmartin> bjordan__: standard medium sized shape would be my call.

<bjordan__> garycmartin: nope, haven't yet

<bjordan__> I will let you know when I try that

<garycmartin> bjordan__: lets not suprise users with randomness :-) Though I'm fine with random colour for now as it avoids that decision for the user.

<bjordan__> garycmartin: makes sense

<bjordan__> re: the libraries, I haven't been able to determine whether one can / how to include setuptools with a self contained package like Physics

<asaf> it could be something like standard medium sized +- small random modification just for fun

<garycmartin> asaf: that poor kid trying to build a pyrimid of blocks, only to find they don't line up correctly. Oooohh, you are sneaky! :-)

<bjordan__> so I'm leaning towards leaving de-.egged (unzipped) libraries in the lib/ folder until we can figure out how to include setuptools

<garycmartin> bjordan__: +1, it's a pitty they are quite so large, but compatibility is more important in my mind.

<bjordan__> garycmartin: good point, random sizes would mess with simple build-ability

<asaf> you are right, I think I need to get some 8yr old cousins to remember that age

<bjordan__> I will ask around about how to include setuptools, hopefully it will be possible

<bjordan__> asaf: :) even finding an older friend to play for the first time while you're there can be illuminating

<bjordan__> one thing I noticed is that the distribution of icons on the toolbar is a bit confusing

<garycmartin> bjordan__: actually it appears random...

<bjordan__> it goes magic pen / triangle / polygon tool / destroy / motor / box / grab / pin / circle / joint

<garycmartin> bjordan__: I did consider trying to fix that, but it's generated from a dictionary (which is implicityl un-ordered), so we'd need to add some properties and use them to position the buttons.

<bjordan__> garycmartin: ah. ok! should I file a bug for it for later?

<garycmartin> bjordan__: Sure yea.

<asaf> one thing I wanted to talk about is the roller ball

<garycmartin> asaf: :-)

<asaf> if we consider replacing the motor with the roller ball then we may have a compatibility issue

<asaf> because the pinned roller ball is not the same as a motor

<bjordan__> roller ball is basically a motor that fixes to an object instead of the background?

<asaf> yes, maybe to an object with no shape

<garycmartin> asaf: an object with no shape?

<asaf> another way of doing it is to create a controller that applys a constant torque to the ball

<garycmartin> asaf: +1 that sounds nice.

<asaf> i'm still not sure about the body with no shape approach

<garycmartin> asaf: where does the compatibility isue come in. Surly only an issue one we have a Physics-3 released with a formal save format?

<asaf> I know about that because yesterday on one of my attemps of saving the data, when I restored, the ground body where everything is pined started moving

<garycmartin> asaf: :-)

<garycmartin> asaf: Oh so you can pin/link to the fixed ground now? Last time I tried it wouldn't let me.

<asaf> I think you can

<asaf> I'll try it and get back to you

<asaf> the problem is that it will create a type of object that will no longer be possible to build

<garycmartin> asaf: Should we have 2 icon tool for forces, one for rotation (Motor) and one for linear (rockets). Though I guess both are the same if your placing a force vector. Hmmmmm.

<asaf> mm, but now that I think about it it wont crash or behave strangely

<asaf> well, the behavior will be quite different

<asaf> for the rotation you'll only select an object and for the linear you may have to draw an arrow

<garycmartin> asaf: a rotational torque will be on the objects centre, or the point you click?

<asaf> I have an example on how it could work

<asaf> If you have elements installed you can run it

<garycmartin> asaf: for the linear, again, would the force be applied to the point or the object center. If it's a point then a pinned shape can be spun by placing a vector force on a spoke edge.

<asaf> it's sort of in the center but it doesn't really matter

<garycmartin> asaf: the current pinned motor allows you to put the motor off-center.

<garycmartin> asaf: sorry not trying to complicate things, just bouncing ideas.

<asaf> the forces are can be applied in a point

<asaf> do you have elements installed? I can send you the example so you can see what I mean by "sort of in the center"

<asaf> the torque just makes it rotate

<asaf> but yo can pin int wherever you want

<garycmartin> asaf: I'm in Sugar here, with Physics installed, is that enough?

<garycmartin> asaf: sounds good :-)

<asaf> if you pin it too far from the center it will have a hard time rotating

<garycmartin> asaf: ahh sure ok. so the force is around the object center point, but pinning allows an 'off-centered' wobble :-)

<garycmartin> asaf: I've often wondered if we should try and make the left and right edges of the screen wrap around. All these little devices are going to go scrambling off screen, quick :-)

<asaf> that's true but I don't see an easy way of doing that

<garycmartin> asaf: no, I didn't either :-)

<garycmartin> asaf: at least lost object are being killed or put to sleep once they leave so far.

<asaf> we could add hard walls in the borders

<asaf> or leave it as an option in the world properties modifier

<garycmartin> asaf: Though it's worth noting that if you leave even a quite simple contraption running on an XO, it does slow doen and eventually lock up OOM I think, so some leaks in box2d I guess.

<garycmartin> asaf, yes, have it as a global option would be more user frendly.

<asaf> I think that if you put the file inside the Physics.activity it will work.

<garycmartin> asaf: (by 'simple' I meant 2 circles with centre motors, each with a link to a dangling box so the each whirrled around a box each, with ocassional collisions)

<garycmartin> asaf: (runs for about ~20min or so before locking up, need to test some more)

<asaf> I sent the roller ball example

<garycmartin> asaf: got it... le me try.

<asaf> ok, so what are the goal we have to achieve before v3 release?

<asaf> 1. compatible save format

<asaf> 2. replace motor with roller ball ?

<asaf> 3. Integrating librarys

<asaf> libraries*

<garycmartin> asaf: the ball escaped :-)

<asaf> try again

<garycmartin> asaf: 2. replace motor with roller ball. Just a suggestion, how about we keep pinned motor, and make roller ball a secondary palette option?

<garycmartin> asaf: or are the changes further down in the internals of elements?

<asaf> not really, we could do both with no problem

<asaf> ahh, one quiestion I have is if I should put as much as posible inside elements

<asaf> for example, the save/load code

<asaf> or the roller ball code and stuff like that

<garycmartin> asaf: caught it! It has rather a fiesty personality and wriggles a lot :-)

<bjordan__> put rollerball example up at http://shell.sugarlabs.org/~bjordan/sandbox.py (need to do it to get it into my VM anyway :-p)

<bjordan__> wow that thing is fast!

<garycmartin> bjordan__: you try catching it with a laptop track pad, took about 5 attempts! :-)

<asaf> ha

<garycmartin> bjordan__: just think of all the race loop-de-loop and jumps kids will be building for this :-)

<asaf> I just remembered that if you press spacebar you stop time

<bjordan__> haha, did, required some pre-launch prediction :-p

<garycmartin> bjordan__: just be thankfull that asaf didn't place it randomly, as some sneaky trick :-)

<bjordan__> garycmartin: oh man, lots of possibilities

<asaf> It's quite fun to throw the ball backwards (to the left) and try to catch it wen it goes by

<asaf> hahahaha

<garycmartin> asaf: yea tried that, and missed. It's like one of those school fate games where you have to hit the 'rat' dropped down a drain pipe :-)

<bjordan__> I wonder if someone will manage to make square wheels run smoothly in Physics http://en.wikipedia.org/wiki/Square_wheel  :)

<garycmartin> asaf: can I have a little think about the user interface for this. I'd hate to hide it away, torque and directional forces (lets call make it 'forwards' for now as apart from the magic pen shaps have a direction).

<garycmartin> asaf: ...torque and direction forces are nice tools that should really be quite visible.

<asaf> I didn't understad

<garycmartin> asaf: sorry, my bad writing. We currently have 'pinned motor' (which folks love, but likely because it's the only motor force at the moment), I think torque force, and directional force (forwards in direction of object axis?) should be exposed as top level buttons in the user interface. The question is where and how :-)

<asaf> ok

<garycmartin> asaf: for directional force (rocket motor) I'm still not sure of the right UI, drawing a force vector arrow is quite nice as you suggested. Maybe that is easy enough for kids? Not sure.

sdziallas leaves: "Ex-Chat"

<asaf> it certanly requires dragging the mouse but I can't think of any other way unles defining the direction at random!

<garycmartin> asaf: (rocket motor) my initial feeling was an actual shape like tool, that you drew a rocket like shape with (box with a pointed nose on top) it's size an orientation would then be the force. You would link it to other objects to build stuff with (rocket cars, pin wheels, etc).

<asaf> also I would like to take advantage of the situation to get into context, where in the world are you two and how are you related to the project?

<garycmartin> asaf: (rocket motor) the alternate option is to "paint" an existing shape with the rocket motor property. It then flys off in it's 'forward' axis direction. The rocket motor tool, could then have a sub palette for weak/medium/strong.

<garycmartin> asaf: I'm in Scotland/UK up in Edinburgh (yes it is raining and getting dark right now) :-)

<asaf> the reocket like shape sound good but I would just do a box, not the triangle because the triangle will make more difficult attaching the rocket to other stuff

<garycmartin> asaf: rocket, how do we know where the front is?

<asaf> if we don't add the triangle?

<garycmartin> asaf: yea

<asaf> the front can be the opposite side where the smoke comes out :)

<garycmartin> asaf: maybe an arrow shape on the box?

<garycmartin> asaf: lol :-)

<asaf> hehe, yes, we could add a sprite

<asaf> or mabye add nozzles to the square

<asaf> (a couple of small boxes under the box)

<garycmartin> asaf: I have the dubious honor of being the ActivityTeam coordinator. So I've been trying to rescue old, good activities from bit rot over on the laptop.org wiki.

<asaf> so you have a job in sugarlabs?

<garycmartin> asaf: Wade is the official ActivityTeam coordinator, but he has a new baby so has his hands full right now (and the last few months).

<garycmartin> asaf, no all sugarlabs folks are volunteers

<garycmartin> asaf: I'm a freelance developer/cgi type when I'm trying to put food on my table :-)

<garycmartin> asaf: how about you? Where you based?

<asaf> I'm in Mexico City

<asaf> I study physics and I'm currently working on my dissertation to get my degree plus some disctractions :-P

<garycmartin> asaf: Oooh, real physics!! :-) Excelent!!

<garycmartin> asaf: I think bjordan__ is shy, someone must be after him ;-)

<garycmartin> asaf: Actually I need to dash, just seen the time...

<garycmartin> asaf: really great to chat at last with you in real time.

<garycmartin> asaf: I'll take this log and post it on the Physics talk page so others can follow the plot :-)

<asaf> yes, nice chat, we have lots of work to do.

<asaf> should I add icons to the tools description at the wiki?

<garycmartin> asaf: we do, yes. Quick regarding Evements vs. Physics code. I'd try to guess if others may want to use some feature you think is generic enough, if so perhaps Elements is where it would be best going. If it's just something for Physics users, then keep it in Physics code (I know, I'm stating the obvious here, sorry).

<garycmartin> asaf: icons, sure if you want. I'll have a go at some full mock-ups as well and see where that takes us :-)

You are now known as away_garycmartin

<asaf> ok, write you later, bye

away_garycmartin waves to asaf and bjordan__ Must do this again, sooner rather than later :-)