Work Progress - Dec 15 - Dec 21

Demo: here

• Updated documentation on setting up pCSDT project here
• Undo the pop-up windows for coordinates in SB app.

Videos/Screenshots of recent work:

• Fix the bug that the variable name changed when moved and saved in the scriptlet window.
• Assignment, binary statements can now drag and drop freely throughout the application. Download and load this XML for an illustration of what can be done by drag-and-drop. Below is a script that can be created with drag-and-drop now.
  
• 
• Can now control whether the skateboarder yells something during simulation (with its "Start Yelling()" and "Stop Yelling()" method codelets, and what to say by its "Change message to yell to()" method codelet)
• Make grid the default, show # as well
• 

Work Progress - Dec 8 - Dec 14

Demo: here
Google doc TODO list: here

Done:
* Fix the bug that the variable name changed when moved and saved in the scriptlet window.
* Avoid invalid coordinate input by having users enter the coordinates in a pop-up window. (Try editing coordinates from the property window)
* Assignment, binary statements can now drag and drop freely throughout the application. Download and load this XML for an illustration of what can be done by drag-and-drop.
* Can now control whether the skateboarder yells something during simulation (with its "Start Yelling()" and "Stop Yelling()" method codelets, and what to say by its "Change message to yell to()" method codelet)

Mayan's suggestions
* [Done] Make grid the default, show # as well
* [Done] turn parameters to integer if possible
* [I move them to the advanced properties] hide the gravity parameters
* [Use tooltip text to explain the meaning of a negative value] name of the acceleration parameter
* [Fixed] omega in property dropdown

Work Progress - Dec 1 - Dec 7

Demo: here

• Robust handling of mistyped coordinates in SB
• Bug fix on JPnlLineProperty - no need to actually click and make selection before setting the corresponding object property
• Modify Bill's RW code to make it compatible with the latest core.
  
• Global variables are now available for drag-and-drop. Use them with care as it is still not perfect. (e.g. In [A = B + C], One can't insert a variable/an attribute to location B or C.)

Work Progress - Nov 24 - Nov 30

Demo: here

Done

• Align x, y coordinate side by side.
• Functional property assignment codelet in the template window. Drag and drop the assignment codelet (the last entry under the "Expressions" tab) to the middle window. Then you can drag and drop a property codelet to its left, and then drag and drop some constant to the right, as shown below. One can save and load such codelets.
  

Work Progress - Nov 10 - Nov 23

TODO google doc: here
Web demo: here

Bugs:

• File->New not clear everything properly. [Fixed]
• All event codelets show up in the same place in the scriptlet window if start with an XML file. [Apparently fixed by recreating the scene and save the XML file again]
• Can't see subfolders in File -> Open [Fixed]
• AutomableProperty "name" fails to show up properly if it special characters (like θ) are used. [Work around by avoiding special characters in the AutomableProperty "name" of the attribute]
• If the project contains scripts that use binary predicate in conditionals, the saved XML file can't be loaded properly. [Fixed]
• No horizontal scrollbar for the middle scriptlet panel. [Fixed]
  

Things to be improved:

• Anti-aliasing of the line segments (Still not managed to fix that - suppose to be related to GLCapabilities and GL_LINE_SMOOTH. Ref 1, 2, 3, 4)
• Let every landscape detect collision with the skateboarder [Achieved by offering the OnCollide event for the landscape object to sense when something collides with it. If one wants to ask the skateboarder to do something as a result, in the landscape's OnCollide event one can call the LaunchObject() method to invoke the OnBeingCalled() event of the skateboarder. In the OnBeingCalled() method of the skateboarder, one can use the if (LastCaller == xxx) conditionals to differentiate which landscape calls for actions and response appropriately.]

To think about:

• Should methods of an object be accessible by some other object?
• Provide drag and drop of assignment statement? Variables declared on the fly VS some predefined variables for looping/counting purpose?
  
• Timer, Goal position?
• Texturize the landscape (suggestion from Mayan)
• Grid display
• Ability to drag constant, object attribute and variable to the parameter field of method codelet
  

Work Progress - Nov 3 - Nov 9

Web demo: here

Work done:
* To adjust the visibility/editability of automatable properties, two additional annotations are introduced.
-- DesignTimeBehavior: It determines where an automatable property shows up in the property window at the bottom right. "B": show up in Basic tab of the property window, "A": show up in Advanced tab of the property window, "H": hidden. Default is "B".
-- RunTimeBehavior: It decides the editability and visibility in the Expression tab on the left. "E": editable (R+W), "R": read only, "H" - hidden. Default is "E". (Note: The Core infrastructure to differentiate "E" and "R" is yet done.)
-- Example usage:
@AutomatableProperty(name="mass", desc="mass", DesignTimeBehavior="A", RunTimeBehavior="H")
public float m_mass = 1.0f;
* Bug fix on "Detaching codelet from an event with only one child creates a java exception".
* Lighter background, darker lines
* Thickness of lines is now an advanced property of the line.
* Use of annotation to indicate the naming convention (the default name of the newly created object) and class description (descriptive text shown in the new object creation dialog).
-- Example usage:
@AutomatableClass(name="SkateBoarder", desc="Skateboarder")
public class SkateBoarder extends PObjectJBox2d {

Work Progress - Oct 27 - Nov 2

Work done:

* Change SB background to a darker one, so it is not that distracting.
* Attempt to speed up simulation:
-- Increasing the step size [adjustable as an advanced property "Speedup factor" of the BoarderEngine object]: It produces less precise collision simulation.
-- Changing the gravitational constants [adjustable as basic properties "X-gravity" and "Y-gravity" of the BoarderEngine (background) object]: It affects the simulation result.
* Negative acceleration done: Try triggering Accelerate() when the skateboarder is moving downhill.
* Implement brake() which does not accelerate when the speed has been reduced to zero. (Remarks: Negative jump doesn't make much sense as now jump is now defined as providing acceleration towards the direction of the surface normal (i.e. away from the surface). Negative jump then means accelerating towards the surface, which means no effect at all after immediate collision. Also, it doesn't seem a skateboarder can exert a force that is directed towards the ground.)
* Patterned placement of line segments: try adding line segment/broadline2 objects
* Rename RocketKick() to JetpackPush()

Work Progress - Oct 20 - Oct 26

Demo: here

Done:

• Place global methods after local methods
• Sine wave
• Survey on alternative physics engines: 1, 2, 3
• Collision optimization: 1) Model lines as series of 2-vertex polygons rather than 4-vertex blocks. 2) Make all objects that are not supposed to move as sleeping - this helps reduce CPU load, 3) Allow the user to reduce the maximum number of iterations allowed to the constraint solver (now as a property of the background object). 4) Assigning non-movable zero mass, so they are considered static. Hopefully the engine does not check for collision among static objects. Possible TODO: Only activate objects that are around movable skateboarder at every time step. Objects that are unactivated do not involve in collision test and thus collision detection is faster. (See Body.setActive() javadoc)
• Polynomial's default shape is now quadratic.
• Equation objects are now accompanied with the corresponding equations in the description section of the property window. (Ref: Unicode lookup table here)

TODO:
* equal inc for the lines
* Fix acceleration direction problem
* Rocket image for rocket jump
* Description of the equation lines - naming convention and general desc as annotations as description of the class in general, name and desc are description of the particular object

Work Progress - Oct 13 - Oct 19

SB demo: here

Polynomials

• One can now create new Polynomial, Rational and Exponential objects from the Create New Object button.

Poses

• Poses for Jump and Accelerate are done (One may add the Jump/Accelerate method codelet to the On "u"/"d" pressed event codelet of the skateboarder, then press the corresponding key during the simulation when the skateboarder is on some line to see the effect). When the skateboarder's downward acceleration is greater than a certain threshold, its look also changes.
  

Work Progress - Oct 6 - Oct 12

SB Demo with fixed method codelet input boxes (by Jason) and forgiving cursor (in CCD site): here

Work done

1) The degree of forgiving can be adjusted as advanced properties in the Engine/Background class.

The bounding box shown when the skateboarder is selected gives you an idea on how it works. Once you start the application, select the skateboarder and adjust its size which is its advanced property. Even if its size is very small (say 0.01), we still preserve an area for it to be selectable.

2) Background image
Now it is just a predefined image. We still need to think about how to allow user's own content to appear in the app.

TODOs

* Assignment, binary statement visualization in left window

* Poses

Some reminder developer notes

* uniscale for the G2D presentation engine
* GetPolyBound() of PObject should return a vector of vector of Vector3 class because multiple polygons may be needed to define the bounding polygons (e.g. the arc)
* Transparency of codelet in the drag layer
* drag method codelet in the left window does not show up in the drag layer.

Work Progress - Sept 29 - Oct 5

Demo URL: here

* Allow loading of external XML file (Ref). Now by specifying the location of the sample file in the JNLP file as follows, one can load a default script by saving it as an XML file and putting it on the web.

<jnlp ... >
...
<applet-desc name="pCSDT Applet" main-class="SB.SBGui" width="1000" height="600">
<param name="DefaultScriptUrl" value="http://www.rpi.edu/~laut/SBtest/SB2.xml"/>
</applet-desc>
...
</jnlp ... >

References: 1, 2, 3, 4

* On rolling over the simulation canvas, we now indicate the name of object that can be selected.
* Rename "On: Simulation" to "DoForever"
* Polynomial/curve: I implement an "Arc" object using center of a circle to indicate its location, and its radius, start angle and end angle to define the arc. You may try adding it from the "Create New Object" button.
* Skateboarder: To model the wheels better (so it wouldn't fall down in the following situation)
I model the skateboarder as rounded rectangle as follows:

TODO:

* Better default file

* Pose

* Forgiving cursor (still need to wait for Jason for some core code)
* Simulation canvas moves with the main character.

New ideas:
* Providing the option of adjusting the weight of the skateboard and the skateboarder. (Different relative weight may affect skateboarding stability.)
* On pressing a keyboard key, the skateboarder responses, like accelerate or jump.
* Better Skateboarder's kick functions - for example, accelerate and jump should be allowed only when he (his bottom to be more precise) is in contact with some surface).
* Ollie, which is rotation about multiple axes. We need to model the skateboard better (e.g. with two wheels and a board rather than a soild mass) in order to model that correctly.

Work Progress - Sept 22 - Sept 28

Web demo: here

Work done:

• App programmer can now put the properties in either "Basic" or "Advance" group. To put an AutomatableProperty in the basic tab, use the following construct:
  
  @AutomatableProperty(name="init-x", desc="x coordinate of initial skateboarder position", group="basic")
  public float m_initx;
  
  To put an AutomatableProperty in the advance tab, use the following construct:
  
  @AutomatableProperty(name="friction", desc="friction of the skateboarder", group="advance")
  public float m_friction;
  
  If you do not specify the group to which the AutomatableProperty belong, the Core will assume it is a basic property.

• Forgiving cursor - when the mouse is on somewhere where we have some object to click, we indicate that at the top of the simulation canvas. (See top left)

TODO with the SB app/Core:

• Forgiving cursor - making certain allowance on the minimum selection area (difficult as current code works with logical positions not screen position)
  
• Curved lines would be really nice—perhaps the same polynomials we put into the synth tool, and throw in a sine wave as well.
• Different poses (still in experiment, and should be done only when concrete direction of SB app is confirmed)
  
• Proper count on the current number of different PObject subclasses, so on creation of new subclass object we can assign appropriate numbers.
• Allow images for Engine (now renamed background)
• We need a better default file, one that has zero elasticity and more attractive behavior.
  
• It is very natural to want to place a “kick” at a certain time or location (or combination of the two). This will offer an opportunity to use a conditional, once we have one.
• It is a little counter-intuitive to think of kick in terms of iteration, I would not put that in the default file. I assume it is just in there because you needed to test the iterative loop.

Work Progress - Sept 15 - Sept 21

Web demo: here

Done:

• Restrict the number of decimal places shown in property window. As long as the number has not more than 2 decimal places, only 2 decimal places are shown.
  
• Resolve object selection when multiple objects lie on the same place. Now if multiple objects lie on the same position, any one of them has equal chance to be selected once we click on that point.
  
• Highlighting selected object available to apps using Graphics2D engine as well.
• The vertical order of the coordinate is now X first, then Y below.
  
• [Now the bounding box/highlight is gone when simulation goes on.] When the user starts, we don’t want a bounding box around the skateborder. But we probably want the skateborder’s script to show up as the default. So maybe he can just change color the way the lines do, rather than placing the bounding box around him.
• Get rid of “current x,y” and have only “initial x,y”.
• [Solved by resetting whenever we are updating any property of the object.] When you change a line position parameter, it’s hard to know what effect you had on the line, there is no immediate feedback to the user. It would be nice if you could see the line change BEFORE you press “begin.
• [I highlight which endpoint is which when the line segment is selected.] I found myself was struggling to figure out which end of the line was x1,y1 and which end was x2,y2. Not sure what is best to solve that problem. We could make a more pictorial version of the properties panel but that would burn up a lot of coding time. On the other hand it is important to keep in mind that the success of this hinges on reducing the amount of frustration experienced by the kids.

TODO with the SB app/Core:

• Proper count on the current number of different PObject subclasses, so on creation of new subclass object we can assign appropriate numbers.
• Allow images for Engine (now renamed background)
• We need a better default file, one that has zero elasticity and more attractive behavior.
  
• Curved lines would be really nice—perhaps the same polynomials we put into the synth tool, and throw in a sine wave as well.
• It is very natural to want to place a “kick” at a certain time or location (or combination of the two). This will offer an opportunity to use a conditional, once we have one.
• It is a little counter-intuitive to think of kick in terms of iteration, I would not put that in the default file. I assume it is just in there because you needed to test the iterative loop.
• When trying to select a line, it is easy to accidentially select the display screen instead. We need a “smart” mouse cursor that realizes that if you clicked really close to a line, that you wanted the line and not the screen.
• I think I would have only line position show up, and for the other parameters (color, width, elasticity, friction) I would make them click on “advanced” before they see them.

Work Progress - Sept 8 - Sept 14

Web Demo: here

Tasks completed:

• Core: Object duplication completed. Now after you right-click on the object and select duplicate, a new object with the same properties and scripts is created.
  
• Core: Allow default naming convention of individual objects to be changed via overriding the setNamingConvention() method of the pObject. Now when you create a new object, the default name of the newly created object looks better.
  
• SB: Rename default objects to desired names. (e.g. The default line is now named Line_0.)
  
• Core: Make OnCall() codelet a global feature available to all pCSDT apps. So now you see OnCall() event and the Launch object codelet for all the objects.
  
• Deployment: Allow both applet and Web Start versions of pCSDT to run on different OSs and CPU architectures.
  

Work Progress - Sept 1 - Sept 7

Work done:

• Now dragging method codelet away does remove the method from the script.
• SHOW GOAL IMAGE -> SHOW GOAL IMAGES
• Reduce the font size of the codelets a bit to make them smaller

Work Progress - Aug 25 - Aug 31

For trying out the effect:

• http://www.rpi.edu/~laut/SB2/app.jnlp
  

Work done:

• Bug mentioned in previous entry fixed.
• Having the middle scriptlet panel moved with dragged codelet. (Suppose the middle scriptlet window is already very full, so that one needs to scroll in order to access some script location. In the past, one has to click on the scrollbar, adjust the viewport of the scriptlet window to the required script location before you can insert a dragged codelet to the location. Now it is able to scroll the scriptlet window when you are dragging a codelet.)
  
• (x, y) mouse pointer location display
• SHOW GOAL IMAGE button and functionality

Bug to fix:

• Dragging method codelet away doesn't remove the method actually.

Possible next steps:

• Object duplication
• Codelet size reduction
  

Work Progress - Aug 18 - Aug 24

Instruction to test

1. Get the XML file at http://www.rpi.edu/~laut/SB/sb_sample.xml
2. Load the SB app at http://www.rpi.edu/~laut/SB2/app.jnlp
3. Load the XML file to the SB app from the main menu, File -> Open

Tasks completed

• Core: Right-click on the object list in bottom right window allows deletion and duplication of the selected object.
• Core: Complete the 2-button system, BEGIN/STOP and CLEAR DRAWING
• Help Ping to fix her loadXml file problem. My solution is to expose an interface called DeferredInitialize() for all PObject. Application developers should put PObject initialization code that depends on respective attribute values there. It will be automatically called when the object is created and added to the respective container (GUI for PEngine and PEngine for other PObject).
• Core: More precise decision on when the script associated with an event is dragged away from the middle scriptlet window (for deletion).
• Core: The button group is never floatable again.
• Core: "Create Object" button in Object Manager is now working. The newly created object is selected.

Bug to fix:

• On reloading an XML file, the object record in the object panel at the bottom right should be all clear before loading in objects in the file.

Next steps:

• duplicating objects
• show goal images
• xy cursor readout
• Middle scriptlet window rolls with the mouse cursor

Work Progress - Aug 11 - Aug 17

Web demo: here

About the renovated Core by Jason

• Add back a few modifications not taken care by Jason after his big renovation of the code.
• Fix the location where the pressed codelet should show up.

Core new feature continued...

• Object Property panel is now moved to the Object Manager at the bottom right.
• Drag the event codelet away from the middle scriptlet panel, and the associated script will be deleted. (still need some work)
• Vertical scrollbar always show up in the middle scriptlet window.

Suggestion: Use annotation to denote the default event for an object, rather than defaulting to the OnBegin event.

Work Progress - Aug 4 - Aug 10

• Core: The "RUN" button is renamed to "BEGIN". (TODO: drag the event codelet. Then all the scripts associated with the event should be gone. NOTE: In long term, we should separate the naming to a config text file.)
• Core: The tab and PObject duplicate bug as blogged in the previous entry has been fixed.
• Core: Right click on an object in the render view. One is able to delete and create a new copy. (NOTE: Currently not working with app usng Graphics2D engine. TODO: copy the properties and event scripts to the new object created on duplicate. Note the x,y display location of the PObject should be slightly displaced. Also PEngine shouldn't be able to get deleted or duplicated.)
• Core: Object Manager Panel now displays both name and class of all PObjects in the system, even if reloaded from file. The name and description of the PObject can also be updated.
• Core: Fix the bug of having multiple method codelets sharing the same PVariant as arguments.
• Core: Allowing default arguments on AutomatableMethod via argVals annotation.
• SB: Add the link to the demo here
  

Work Progress - Jul 29 - Aug 3

Work achieved:
* While codelet: Size of the operand part is now changing properly with the operands attached to it.
* Assignment codelet and comparison codelet can also be properly displayed in the middle JPnlScriptlet window.

Next step:
* Enabling codelet drag and drop to the while, assignment and comparison codelets. Shall take the idea from JPnlScriptlet which does similar things.

Bug report:
* Whenever I minimize the window and then maximize it again, the tabs on the left view repeats themselves, so do the PObjects in the right render view.

Work Progress - Jun 23 - Jun 30

Display the control codelet in the middle scriptlet window


Run SBGui. Select the default skateboarder. Drag the OnBegin Event codelet to the middle window. The prewritten script of that event is displayed.

TODO:

• Display all necessary JPnlLinexxx in the middle window.
• Beautify the control codelet display. Make it expand appropriately according to number of statements associated with the control codelet.

Work Progress - Jun 17 - Jun 23

Investigating how to implement the If/while conditional

As the first step, I would like to implement the forever and repeat[x] conditionals, which are also available in MIT scratch. They are good starter, as they do not involve putting things into the conditional part. I just need to concentrate on how to put statements to be executed in the repeat loop.
Then I will work on the variable stuff, which is the prerequisite for codelet-within-codelet to be possible. Some ideas from MIT Scratch are as follows:
Possible parts for this part
* visualize a true/false constant
* visualize a comparison statement
* visualize declaration of a variable
* visualize assignment to a variable
* visualize if
* allow codelet-within-codelet by drag-and-drop
* Implement the more difficult parts of the conditionals - drag-and drop to the condition part.

Progress

Add a control tab and visualize some starter control codelets (Forever and RepeatN)

Work Progress - Jun 9 - Jun 15

GG: Complete code cleanup and documentation
GG: Web deployment package updated (Available here)
Core: Now if anything up to the center point of the codelet overlaps with the left border of the panel, it bounces back just like the right side. If anything beyond the center point of the codelet overlaps with the left border of the panel, it is erased. (Fixed app: here)

Work Progress - Jun 2 - Jun 8

Updated GG apps: here

A few bug fixes:

• Now there is no need to have codelets overlap to join them together. Bring them to sufficiently close proximity is sufficient.
• Now when you click on any part of the method codelet (except the textfield area), you can drag it.
• The application is now able to be expanded to full screen.

Work Progress - May 29 - Jun 1

Fix the drag-and-drop of the existing Core (http://www.rpi.edu/~laut/GG/app.jnlp).

• Pressing the codelet in the codelet template window on the left does NOT duplicate codelet in a different position.
• Releasing the codelet in the middle scriptlet window drops the codelet to the exact vertical position where it is dropped.
• The drop line now indicates where the top of the dragged codelet collapses with the codelets in the middle scriptlet window.

TODO: The current scriptlet window displays the script of at most one event at one time. To allow the scriptlet window to show the scripts of more than one event at the same time, a considerable rewrite of the scriptlet window is needed.

Work Progress - May 21 - May 28

Default script idea:
Have a look of the constructor of GG/DrawerEngine.java. Currently we have a few default ActionScripts (formerly named drawing modules) already defined (moduleR, moduleP, moduleI). When you start the application GG/GGGui.java, you'll see they show up as a square blocks R, P and I in the right panel. Click on each of them, and then click on the "Event" tab on the left panel. Drag the OnCall event "codelet" to the middle window. Then you'll see the series of default instructions associated with the OnCall event codelet. Your task is to produce something similar with the "ToDraw" event codelet of another object of class SprayCan (which appears as a square with "*" in the right render window). That is to say, when I select the SprayCan object on the right render window, and then drag the "ToDraw" event codelet to the middle window, I can see a series of default instructions. Indeed these instructions will be executed once I click on the RUN button. You may perhaps try to reproduce a default script similar to what is shown at https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHQLKP_lbg_e8c0hUaSPXzH4msjxoybWPj0eJ63PehCnAeP2LKR2U1L6N0Ojvm5KFiU7vSE_yrCbulogAE91A_HfNo4osSVNh5R1Vzw-H_VFxP8JR0W_MizJQXfPUoE7IiYgJ8yEVcSvzr/s1600/shape.bmp as a starter. I think the goal is to produce a simple example script that can demonstrate the possibility of the program.

GG Border idea:
The border issue involves coding a method codelet to draw a flood-filled region defined by a series of points. Examples of method codelets can be found in GG/SprayCan.java and GG/ActionScript.java. Each of them is started with something like @AutomatableMethod and then a typical method definition. Inputs should be
* The coordinates of a few points (perhaps 4 points) which define the boundary of the graffiti shape
* For each border line, the width (starting from 0 to some finite value) and the color of the border
* The flood-fill color
I expect the method, when called, can produce a progressive animation of flood-filling the region defined by the boundary. An example of progressive animation can be found in the SprayCan's method MoveBy(), whose effect is shown at http://csdt-laut.blogspot.com/2010/04/work-progress-apr-7-apr-14.html
To animate the flood-filling sequence, I suggest scanline conversion (http://www.siggraph.org/education/materials/HyperGraph/scanline/outprims/polygon2.htm).

Some minor updates on graffiti grapher

• Rename TimeStepAction to SprayCan, DrawingModule to ActionScript
• The drawing action now stops properly.

Links to the skateboarder and graffiti grapher pCSDT apps (using Java Web Start)
http://www.rpi.edu/~laut/SB/app.jnlp
http://www.rpi.edu/~laut/GG/app.jnlp

Work Progress - May 13 - May 20

Send code to Ping and Bill
* Code
* Instruction to set it up in Netbeans

To do for the summer
* GUI drag-and-drop bug fixing
* IF/While conditional
* Enable drag into codelet

Work Progress - May 5 - May 12

Looks like JNLP is a better option than applet in hosting pCSDT applications.
Example JNLP: http://www.rpi.edu/~laut/GG/app.jnlp

Work Progress - Apr 30 - May 3

Drawing borders for the Graffiti shapes

It looks like there are two ways to produce the borders we need for the graffiti shapes. See the following hand drawing for an example.


* The first shape can be reproduced in the program by drawing the background shadow (of a bit larger scale - example and/or a bit displacement - example) first, before drawing the foreground shape. The screenshot below shows the existing code manages to work for both cases.

TODO: In long term, I would like to extend the DrawingModule code, and provide an interface InvokeDrawingModule(ModuleName, Scalew, Scalex, Scaley, Offsetx, Offsety) to allow arbitrary offset, scaling and rotation before using the drawing module.

* The second shape can be drawn by incorporating border to line drawing, which starts from the bottom, and then goes up, takes a circular track and finally runs past the previously-drawn vertical stroke. However, I don't prefer this approach as it does not mimic the way graffiti shapes are drawn. If the purpose of the program is to teach how graffiti is drawn, this may not be a good way to go.

Work Progress - Apr 22 - Apr 29

Web Deployment

Web version of GG app: http://www.rpi.edu/~laut/GG/

The web deployment package now works with JDK version 1.6.0_15 or later. The updated files are available here. The reason why the old deployment files no longer works can be read from here.

From the main menu, click on Create->TimeStepAction to create a spraycan object. It will show up as a square labelled "1" at the top of the render window. To insert action, select the "OnTriggerTimeStep" event for the time being.

From the main menu, click on Create->DrawingModule to create a drawingModule object. It will show up a a square labelled "Module1" at the bottom of the render window. To insert action, select the "OnCall" event for the time being.

To call a drawing module in some part of the script, use the "InvokeModule" codelet available in the TimeStepAction/spraycan object. Give the name of the Module you want to call as the parameter.

You may check my previous entries for some examples.


Sample drawing modules

Sample drawing modules for letter "R", "P" and "I".

Create the following script in a TimeStepAction's OnTimeStepAction() event.

Then start the simulation.



NOTE: One can click on the module's OnCall method to edit the script there.


TODO

• Incorporate border to the drawing
• Set "paint on" as default
• Correct the angle specification - now 90 degree points downwards but we expect it to point upward (But it is related to pointing-downward y-coordinate in Java drawing canva)
  
• Abolish those codelets with change-width-on-moving counterparts
  
• Method clean-up
• Find a mechanism to give default parameters to the codelet dragged
  

Work Progress - Apr 15 - Apr 22

Able to specify the total width change for a MoveBy/DrawArc action.



In progress: web deployment - http://www.rpi.edu/~laut/GG/

Work Progress - Apr 7 - Apr 14

Instead of drawing line-by-line, now it is able to draw pixel-by-pixel. So we now have drawing animation.



TODO: change width when drawing the line, set up pre-defined module of drawing alphabets

Work Progress - Apr 1 - Apr 6

* Able to draw the line segments one at a time, while the UI remains responsive.



* TODO: May be able to create drawing animation by progressing the line drawing action a little at a time.

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.

Work Progress - Jan 24 - Jan 31

Progress:

• The dragging action is now able to update the statement tree data structure. Currently the drag simply append a new PStatmentMethod statement to the statement tree data structure. (See my modified InsertCodelet() method in JPnlScriptlet.java for details.)
  

Demo:

• Run SB/SBGui.java
• Select the Skateboarder object on the right render window.
• Go to the "Events" tab. Select an event
  
• Go to the "Methods" tab. Drag any method prototype to the middle JPnlScriptlet window.
  

-- On dragging --

-- Right after drag --

Next step:

• PStatement.Void display - should we provide an empty textbox and let the user enter the value directly? Since then we need to turn that PStatement.Void object to a PStatementConst object.
• An illustrative example of execution of statements in the statement tree.
  
• Enable addition of codelet to arbitrary location of the statement tree.
  
• Enable removal of codelet by selection at arbitrary location of the statement tree.
• The height of the method prototype (with multiple arguments) when it is being dragged needs to be fixed. The width of the method prototype with no argument, when standing in the middle JPnlScriptlet window on its own, needs to be fixed as well.
  
• Utility's changeArraySize() method has generic array creation issue. I rewrite a intuitive code to replace any call on this method. We may need to investigate the issue to help keep our code elegant.
• JPnlScriptlet window may show the current event being edited.
  

Work Progress - Jan 18 - Jan 22

Summary of my work in the winter:

• Complete the display of objects' method prototype (which is going to be for users to drag and construct their simulation's visual programming) on the left hand side of the pCSDT main window. Now when a particular object is selected in the render view on the right hand side of the pCSDT main window, the available methods of the object are shown, with their respect argument names.
• Complete the display of the PStatement tree, which tells what actions to do when an event is triggered, at the middle of the pCSDT main window. Now once an event of a object is selected, the corresponding PStatement tree will be shown.

The two images in the weekly progress section presents visual illustrations of the above two points.

Potential future work:
For the scripting functionality you mention, sorry I didn't have a time looking into it in details. The existing code has just allowed me to complete the display part of the method, though. Below are some potential tasks I can think of (may be done in parallel):

• The Save() function in every JPnlLine subclass.
• The actual drag-n-drop. I think the right function call has already been available in the repository's drag-n-drop test code.
• The completion of the display of other function blocks, like the if...then..., while do...
• The execution of the PStatement tree when the corresponding event is triggered. (My impression is most parts have already been completed - of course you need to check with Jason for the actual situation - we may just need an example to demonstrate it.)

Weekly progress
Run SB/SBGui.java for a demonstration.

• Enhancement on the the codelet prototype and statement tree view, as follows.

• Add a static member of PStatementConst called Void, which corresponds to a PStatementConst wrapped around a PVariant.Void. Since then when a codelet is freshly dragged from the prototype view on the left to the statement tree in JPnlScriptlet window in the middle, the parameter values can be initialized directly with the same PStatmentConst.Void, instead of instantiating separate PStatementConst objects. This saves memory. See SB/BoarderEngine.java line 115 in revision 242 for an example.
• Documentation
  

Work Progress - Jan 11 - Jan 15

Finished rendering the statement tree in Scriptlet window

• I've set up an example in the skateboarder code (SB/BoarderEngine.java). I create an event for the BoardEngine called DummyEvent. It is accessible under the Events tab on the left window as soon as we run SB/SBGui.java, at which time the stuff associated with the Engine are loaded. Click on it, and you'll see the methods associated to it displayed.
  
• Rendering of the statement is delegated to the individual statement types. In this example statement tree, in the Something2() method we have parameter val being evaluated by a binary statement "x + x". the rendering of the binary statement part is depending on the existing implementation in the class JPnlLineBinary.
• Fix the problem that when another object is selected, the statement tree in the scriplet window is not clear.
• Fix the problem that the method's parameters are not immediately shown after the corresponding object is selected.

Work Progress - Jan 4 - Jan 8

- Collect further system specification from Jason

- To do:
1) Display PMethod in Prototype window

• In code responsible for displaying PMethod in the prototype window, set all the input fields as disabled always. [Done]
  

2) Render the statement tree in Scriptlet window

• Create a new static member of PStatementConst called void, which corresponds to a PStatementConst wrapped around a PVariant.Void. [Seems to be done somewhere when bunch of PMethodStatement's are created]
  
• Understand the PStatement life cycle:
  1) A separate statement tree is associated with each event. JPnlScriplet.BindCodelet(.) is the way for the Scriplet to obtain the current PEvent's statement tree to render. PStatementList seems not able to attach children statements...
  2) When a PStatementMethod is created, the parameters should be a bunch of PVariant.Void.
  3) User inputs the data to the input fields.
  4) When about to execute, obtain data from the input field via PStatement.FromString() method
• Concerning the display:
  1) PVariant is wrapped with PStatementConst.
  2) Call the following recursive construct to show up GUI
  for (IStatement s:m_statement.GetChildren) {
  JPnlLine gui = s.GetGui(info);
  Add Gui to self;
  }