AToM3 SVG Canvas Project

 Considered multiple ways of using Firefox as the canvas. The most promising
model found thus far is the following:



This model has a serious disadvantage, IMO, and that is that AToM^3 cannot "push"
information to the canvas. It must instead depend on the canvas asking for the
information (a "pull" model). This means that whenever the user requests that 
operation X be performed, and operation X does Y, W, and Z which each require 
re-drawing the canvas, then logic must be moved to the javascript side to make
sure those updates happen. 

 AGG: Anti-grain Geometry 
This looked really promising. It's written in C++ in a portable fashion and is 
actually compilable by myself on WinXP with MinGW. It also features a demo SVG 
viewer application. It works perfectly... except for text and bitmaps. I'm sure
there's some way to get text working and I could live without bitmaps although
that's probably even easier to add than the text. Would make a beautiful
back-end for AToM^3...

 Qt Library
The Qt library is available freely for non-commercial purposes and is claimed to
have built-in SVG support. Well it works! The SVG demo application requires a total
of 8 megs (although I compiled everything, which used up 400 megs). 
Problems:
1) Very bizzare font handling. The fonts in AToM3 canvas, Firefox (SVG), and
Inkscape (SVG) are identical (some issues in Inkscape though). In the Qt SVG Viewer
the fonts are drawn completely differently. While they are the correct font-family,
the height/width of the font is wrong, and it's very noticeable in my test case
since I drew boxes around each font (the boxes are the correct size). 



 View the SVG in FireFox for the correct version 

2) Embedded bitmap doesn't seem to work. *shrug*
3) Requires a width/height specification for the drawing, something I've omitted in 
my SVG exports thus far since other viewers have no trouble without it. Still not an 
issue at all.

 Zinc
A Tkinter compatible canvas that supports gradients and SVG like curves. Zinc proved
to be difficult to compile due to its dependencies (i.e.: I do NOT want to install 
ActivePython, ActiveTcl, AND, ActivePerl to run this thing). 

 Sauvage
Yet another SVG capable, Tkinter compatible, back-end. Unfortunately, the author
describes it as "alpha" and I have no time to support it. Scary.

C++ Layout server

 Implemented Circle layout 
 Implemented Spring layout 
 Implemented FTA layout 
 Implemented Tree-like layout 
 Added a pipe client to AToM3 (based on the QOCA one) that can use the C++ layout
implementations. This makes testing easy as the Python and C++ implementations 
will draw the graph exactly the same. The layout server is easy to compile with
g++ and make.
 Although very preliminary, timing results indicate that the C++ implementations 
are about 100 times faster than the Python equivelents. This is dramatic, since
a O(V^2) algorithm like Spring was interactive (less than 1 second) for only 50 
vertices in Python, and yet in C++ it is possible to do Circle then Spring for 
1000 vertices in one and a half seconds. 
Note: Although these time results are not for the same graphs, what is most expensive 
in Spring layout is simply calculating the repulsive force of every vertex against
every other vertex. Which should be equally expensive for any graph with the same
number of vertices.

The DChartsV3 Digital Watch

Sequence of SVG shots documenting this mini-project

 Created a digital watch formalism in AToM3 
 Used formalism-specific UI techniques to model watch behaviour 
 Digital watch runs within AToM3 (i.e.: time updated, indiglo button makes
the display glow 

SVG Exporter

You will need Firefox 1.5+ or some other viewer to display the SVG.
All primitives SVG test export
Tricky text SVG test export

 Wrote an SVG exporter for AToM3. Works on all objects one can possibly put
on the canvas in AToM3. It is accessible via the Postscript export dialog.

Old content follows...

Recap of meeting on Tuesday September 7

 Implement a scoped layout system. In particular, looking at bridging the gap
between low level user-input and high-level model behaviour. Initial requirements
sketch indicates I'll need to model the behaviour of the toolbar buttons, use
scoped UI to overide the default UI behaviour for: Open/Load models, Selection,
Finish dragging, Connect. The internal AToM3 code for selection and connection
will also need to be modified slightly. Selection: must prevent it from allowing
the selection of an entity from an external scoped UI zone 
(which is currently possible). Connection: must know what got connected, so the
task is to return the newly created object... which sounds simple unless you've
seen atom3/kernel/user interface/drawconnections.py


 Reading project! Concatenate all the papers I've read, look for more, 
bibtex'ify the whole thing, and make sure I have summaries for them all. On
Sept. 12, I must drop everything and get started on this. 

 Re-organize already developed layout algorithms to make them as AToM3 
independent as possible. Allow them to be used non-graphically (input coords and
sizes, output new coords). 
Once everything is nice and clear, gain some C++ experience by implementing some
of these algorithms in a more efficient language, and then embed it back into
Python AToM3. 


 Present the best way to code Python to MSDL on Sept 9. 
I have devoted a section of my website to this:  Python IDE 

Recap of meeting on Thursday July 14

 Look into Graph Grammars and how the result of a transformation is visually 
layed out. Should be possible to improve layout significantly, possibly with
the use of linear constraints. 
UPDATE: was able to position GG created nodes close to what they connect to,
and to re-draw their arrows nicely... 


 Put together a framework of layout algorithms that can easily be applied
to various formalisms from a statechart. Exploit scoped nature of some layout
problems. 


 Proceed with either Rhapsody or State Flow to produce C code from a 
statechart and embed it into python AToM3. 

Recap of meeting on Tuesday June 7

1) Talked about an alternative to Inskape called Skencil/Sketch. The idea
is to use these programs to work with SVG graphics and produce high quality
images for research papers. Skencil also has plugins, including SkLatex that
allows the visual creation of latex formulas, and their automatic conversion to
a pure vector form that SVG understands. I will determine how easy it is to 
install Skencil and SkLatex and whether or not they're useable...

Update: Successfully installed both Skencil and SkLatex on Red Hat 8.0. This
required installed TeTex 3.0 from source, PMW megawigets (pure Python), and
PSTOEDIT 3.33 (3.40 should work too) from source. I had previously installed 
PIL (Python Imaging Library) and Python 1.4 with Tkinter, so I didn't need 
to install those. 

Modus operandi: convert PS files to SK files with PSTOEDIT. In Skencil, load
SK files and create SkLatex formulas, mix well, and output SVG or PDF :)
NOTE: If you export then re-import SVG, you lose textures and gradients, but
solid colors and everything else survives unscathed :) 





2) Clean up changes to the SCC generator. The changes make it possible to use
SCC generated DCharts code with the Tkinter GUI loop by removing non-Tkinter
threads from the generated code. By including the modified generator in the main
SCC package, less confusion all around. 



3) Attempt a SWIG'ification of Cassowary C++ distribution. Goal is to be able to
easily compile the C++ code on many platforms. QOCA's C++ distribution has 
already proved to be extremely challenging in this regard. As a last resort,
the QOCA Java distribution (which includes the Cassowary solver), will be used
via TCP/IP communication with the Python implementation of AToM3. 

[Updated info]
i) Unable to compile C++ version of either Cassowary or QOCA (cross-platform 
compilation of C code is really ugly is it not?)
ii) Implemented a parser to convert string commands to QOCA calls in Java
iii) Implemented Pipe communication between Python and Java. Am able to start
a Java jar file automatically given a Java in the environment path.
iv) Implemented TCP/IP communication between Python and Java. Requires manually
starting the TCP/IP Java server. Have a nice Java GUI to start/stop server.
TCP/IP has advantage of working on a remote computer and displaying standard
error streams to console :)
v) Implemented a low level Python wrapper over the two communication types.
vi) Implemented a medium level Python wrapper over the various QOCA commands.
vii) Implement a high level Python wrapper for complex QOCA constraints
similar to that of GenGED. Note: GenGED uses ParCon which can handle 
disjunctive constraints, something not natively supported by QOCA (although
there are research papers that have implemented this in QOCA, without 
releasing source code, and with not terribly great performance. Disjunctive
constraints are necessary to specify outsidness constraints and attach to
border constraints. Thus alternative solution mechanisms will be needed). 
viii) Integration of QOCA module with AToM3. This is very 
difficult to work into the existing architecture. Currently QOCA can constrain
the position and size of entities. Should it be extended to indivual components
of a visual icon? 



4) 
Once constraints are working, use them with the following formalisms:
   i)   Entity Relationship 
   ii)  Petri-Nets 
   iii) Devs 
   iv)  State-Charts 

UPDATE: Attempted to use linear constraints with State-charts. Did not work well.
Investigated implementation of DiaGen which uses linear constraints for statecharts
and found they didn't manage any miracles either.
CONCLUSION: Linear constraints are useful only for a restricted set of graphical
layout problems. In other words, only those formalisms that can be described with
rigid constraints like simple trees and top to bottom flow charts have any chance
of working well. 

   v)   PacManV3 




5) Objective of opportunity (didn't come up in the meeting minutes but...):
I discovered that Eclipse + PyDevs + PyLint = Python IDE from heaven. After 
seeing Shahla using Eclipse for coding standards, I decided to try it out for
my Java code. I was stunned, it's about 1000% better than NetBeans. Makes 
coding more fun it does! Then I started wondering what Eclipse could do for 
Python... and what do you know, it works wonders. Can see errors in real-time
(make a syntax mistake? Red marker appears right at that line!). But it gets
better, you can even see "design" errors, like lines that are too long, methods
that take too many arguments, classes that are too long, etc. This is provided
by PyLint, which when used individually, gave a code rating of -8 or so out of
10 for ATOM3.py after finding many thousands of questionable items...

Recap of meeting on Monday May 16

1) I have completed the class diagram formalism I mentioned. It is modeled in
Entity Relationship version 3 and allows you to hide/show aspects of the class
diagram by editing the ASG properties (where you give your model a name).
Caveat: the graphical icons do not inherit, nor do attributes that are shown in
the visual icons. This formalism is now the default in the bug fixed version of
AToM3 I've put on my website. I hope Sagar will finally be able to implement a
decent version of Bond Graphs with this! 


2) Dealing with the threading issue in AToM3 user interface and statecharts.
I'm still unsure as to whether I should implement polling on the AToM3 side or
change SVM to have a special option for dealing with GUI event loops. On the
other hand, if I'm going to implement the dynamic keybinding idea in the
statechart, I'll be spending so much time re-working the statechart that the
polling idea will be easiest to implement.  


3) [See 3 for June 7, 2005]
Work on integration of a constraint solver with AToM3. Will need some
formalism that allows for the specification of such constraints and the
generation of appropriate code... mmm, should the constraints for a formalism
be stored in a seperate file or spread out accross each formalism component? A
single file for just constraints probably makes more sense. Idea for formalism
that specifies constraints: use graph grammar to transform a class diagram into
a constraint specification model, then work on that.  



4) Integrate C code generated by Stateflow with AToM3 for Icon Editor
behaviour. [Need StateFlow]



5) Implement a hierarchical layout algorithm that is fully integerated with
AToM3. 



6) This isn't so much on my todo list but we did discuss the idea of weaving
together a hierarchical visual model with an equally hierarchical behaviour
model, all connected to a static class model that provides state variables and
methods.