Work Progress - Mar 24 - Mar 31

* Implement "Drawing module/template", which encapsulates some common drawing logic. Below shows the logic of drawing a square. This is done by editing the OnCall() event of Module1 (a Drawing Module).


* Make Drawing module callable by main Hand object. Below shows the logic of the main Hand object. You can see the "Call Drawing Module codelet" is there after the Hand moves to certain locations (100,100), (200,200).


* Below is the result of the simulation.

Work Progress - Mar 15 - Mar 23

Graffiti Grapher: Refactoring the original implementation, now able to do basic drawing. (Click to enlarge the screenshots)



Possible Extensions:

• Creating GraffitiTemplate class, which allows users to edit the drawing logic of some commonly-used complicated shapes (like pentagon) using codelet drag-and-drop and store as some template objects. It can called again and again by TimestepAction object, so users need not repeat the drawing logic to draw shapes of the same kind.
• Implement repetition for TimestepAction/GraffitiTemplate by fitting in a RepeatTime attribute storing the number of times its action is repeated. Then on simulation and when it is triggered to do something, the actions in the corresponding statement tree is executed for that number of times.
  
• Changing how the spray stroke is rendered so it looks closer to what is really happening in reality.
• Try occlusion between the spray can and the wall
  

Work Progress - Mar 1 - Mar 14

Update pCSDT.Presentation.Graphics2D to support

• Periodic update of PObjects in the simulation canvas without flickers (Demo: Run GG application, create a SprayCan object, adjust its position - you can see it move to a new position without leaving trace at its previous position.

To do:

• Complete migrating drawing action code from the GG Engine to SprayCan PObject.
  
• Change the paradigm of drawing: The drawing actions should change the pixel colors of a Wall PObject, which has a BufferedImage representing the drawing result so far. The Wall renders itself when the simulation runs.
  
• Visualize the sequential applications of multiple SprayCans: The difficulty is that the actions of different SprayCans are specified in different statement trees, but not a single tree.
• Abandon the custom command parsing system in existing GG and move it to the one implemented in the core: The challenge is how we can visually build the repeat...end in the statement tree by codelet drag-and-drop.
  

Work Progress - Feb 22 - Feb 26

Research on refactoring Graffiti Grapher app - mainly moving the draw action from the engine to a new SprayCan class, so it can better model the reality.

Challenges:

• The current Graffiti Graphic app is using pCSDT.Presentation.Graphics2D engine, which differs from what I used (and so am more familiar with) previously (pCSDT.Presentation.OpenGL). The Graphics2D engine has no auto drawing the PEngine and PObjects implemented.
• The existing app uses a command execution mechanism different from the Core. We may need to port the command execution mechanism back to the core. But this also means we need to implement repeat() functionality to the core.
  

Work Progress - Feb 15 - Feb 19

A few working pCSDT applications on the web:
* Music Player (due to Tanushree, who fixes bugs which make the framework fully functional on the web)
* SkateBoarder

Work Progress - Feb 8 - Feb 12

* Putting pCSDT apps to web

• Files with instruction (Download)

* Faster computation of the skateboarder application
* Support of multiple skateboarders
* Complete the onCollide PEvent of Skateboarder and BoardLine

Work Progress - Feb 1 - Feb 6

* Possible to enter values to the textfields in the PStatmentMethods visualized in the middle JPnlScriptlet window. The values are saved appropriately in the underlying statement tree data structure.

* The statements in the statement tree can really be executed (at least the OnBegin which works once the simulation begins.)

* Towards a demonstration

• For a PObject to be creatable by Menu action, one needs to provide a constructor with two parameters - name and description.
  

* Study on PEvent

• Examples of how to trigger PEvent other than OnBegin are not there in the SkateBoarder code.
• One can simply treat the Begin Event as the only statement tree associated with an object on the render view, just like what we have in Scratch.
• 8:05 AM me: PEvent?
  8:06 AM cmercenary: Yep.
  That's the one.
  Now, you can also make your own PEvents. For instance:
  Let's suppose you want to give the user a way to have code be run when something happens in the simulation.
  8:07 AM For instance, the skateboarder tips over.
  What you would do would be:
  1) Create a new PEvent. Give it a name, etc. You can see SkateBoarder.java:59 for an example of this.
  2) Annotate it with the @AutomatableEvent annotation, to signal to the core that you want the user to be able to use this event.
  8:08 AM 3) Call the event's Invoke method when the conditions of the event are satisfied--in this case, when you detect the boarder has tipped over.
  Follow?
  8:10 AM me: Get (1) and (2). But for (3), what do you mean by "detecting the border has tipped over"?
  8:11 AM cmercenary: Well, the simulation runs and moves the boarder a little bit forward every few ms, right?
  me: Yes. So it's the responsibility of the programmer, not the user, to tell when the PEvent (in this case, tippedover) should be triggered, right?
  8:12 AM cmercenary: Correct.
  In fact, think about it like this:
  The programmer sends messages to the user's code via PEvent.
  8:13 AM The user sends messages to the programmer's code via PMethod (or, more specifically, PStatementMethod)..
  8:14 AM me: You mention separate statement tree roots are associated with different events. So the scriptlet window has to know which event it is currently editing, so as to display the correct statement tree for editing, correct?
  cmercenary: Exactly.