Source Code

[Karl DD]

For those interested in checking out the source code, the Subversion repository is availble to browse online here: http://svn.al.chemy.org/. There will also be documentation online in the near future detailing how to make an Alchemy module. But for now if you have any questions, please post them in the development forum

[lazor]

I would really like to check out the codebase a little bit more in detail. But doing that via the WebSVN frontend is very tedious. Is there some way to get direct access to the svn repository? So that I could check out the sources via some SVN client. Or, alternativly, a tarball would be sufficient to get me started.

[Karl DD]

Hey lazor,

You can check out the source here: http://svn.al.chemy.org/svn
I'm using Netbeans, so if you check it out with that it will compile and run straight off.
Otherwise in another IDE you will have to make your own build file or adapt the ANT one included.
The only thing you might need is Launch4j installed in C:/Program Files/Launch4j to compile an .exe on Windows.

Javadocs are here: http://docs.al.chemy.org/ - some of this might have changed.

Also, I've uploaded a template for making a create module (with Netbeans) here:
http://dev.al.chemy.org/files/AlchemyMo ... te-006.zip
It is kind of extra-commented for newbies, please take no offence!

Let me know how you get on!

Karl

[lazor]

Hey Karl,

I downloaded the sources and setup netbeans. Building the project under Linux worked without any problems so far.

I already started browsing and looking at the source code, but so far only very briefly. I've been thinking about trying to come up with an implementation of that undo idea I had. Maybe I will have some time next week to spend for that.

If you yourself have any pointers or opinions on how to implement such a feature let me now.

[Karl DD]

Sounds great.

From what I imagined your idea to be, I envisioned some kind of palette/window with a tree like structure of nodes:

Tree.gif (474 Bytes) Viewed 1191 times

Each node represents the canvas at one point (or one specific evolution) in time.
In fact it is a bit like the TRUNK & BRANCHES of source code version control etc...
The main trunk being the present drawing, and the other branches being points where you have reverted (undo'ed) away from.
So in theory you could keep going back and forward between several branches by clicking on the nodes.

To implement this, my first thought was that it would be nice to save all this in the Session PDF.
But the process of writing to PDF and importing everything back in as before, is hacky and not so simple (see AlcUtil.getPDFShapes to see what I mean).

Right now individual shapes are stored in the AlcShape class, but there is no class designed to hold a group of them.
So making such a class to store a 'drawing' and some undo-like keys to decide when to store them. Or this could be tied to the Session menu for simplicity?
The problem will be storing all this info... could be quite memory consuming?
Might need some way to filter out duplicate shapes from each drawing. Eg the first shape drawn will most likely be in every single drawing that is produced from there on in...
I guess the PDF file approach would have been quite good in this respect, as it is stored in a flat file.

What do you think?

[lazor]

Sorry for the late answer.

I have been doing some work recently, looking through your code and experimenting with tree-like data structures in java. My plan so far is to implement a tree-like data structure that acts like a list, and then use that data structure to replace the shapes member of the canvas class, making the commitShapes function use that tree-like data structure to store the Shapes instead of an ArrayList.

With 'acts like a list' i mean that it stores a reference to the Node to which the last Shape was appended, and exposes the methods of the List interface (like add(), addAll(), get(), etc.) which operate on the path between the stored Node and the root Node of the Tree.

Additionally that Tree data structure will also expose methods to change the stored reference to point to another Node of the tree, so that reverting to a earlier state of the design process is possible.

For example the first few changes to the canvas would result in a tree that is just a straight line, every change to canvas would be appended to the Node representing the previous change. The user could then at some point decide to 'go backward in time', changing the active Node to an earlier one. The canvas should update accordingly to reflect that the user us 'going back in time'.
When the user decides that he found a state from which he would like to continue designing, he can just make changes to the canvas again, and these changes would be appended to the now active Node as a new branch of the tree.

This would give the user essentially a 'normal' undo operation, but everything the user designed so far, would stay in the tree as a seperate branch.

Also, it would be possible to give to user some kind of gui to examine the tree, and to select nodes manually from which he wants to continue designing instead of having a direct undo function.

The problems I see with this so far are that without a gui to navigate the tree it is difficult to go forward into the 'future' of a branch once you have multiple possible futures. And the other thing is that so far I have not really thought of how to save that 'tree of possible futures' into a .pdf file.
The only thing I have thought of is that we could just save every child Node (that is every node which does not have any further children) as a seperate design.

Ok, i'll leave it at that for now, if you have any questions, if you want to see the source code i've written so far or anything, just ask, i'll most likely be looking more frequently into the forum the next few days.

[Karl DD]

Sounds great!

I think a GUI is a must, something like the screenshot I posted - or a horizontal equivalent might be more understandable.
One idea might be to have a sort of tab on the tool bar like this:

History.png (11.55 KB) Viewed 1000 times

That is a pretty rough knock up but you get the idea. It would be nice to keep the UI simple and avoid a lot of palettes like other applications.

Re PDF Saving, it might just be a matter of keeping the Session PDF as it is - associated with time.
That way you would get an idea of how the session evolved, going back and forward.
Additionally we could offer an Export History as PDF option to output everything.
PDF is not setup to read like a Tree really, so keeping it linear and time based is probably the only option.

My only other thought is that the history thing could get quite memory intensive as you draw more and more.
The last thing we want is for Alchemy to bog down.
A hard limit could be placed on the number of history states to remember or older history saved to a temp file to flush out the memory?
Some people draw with many many short strokes, so commitShapes will get called quite often I think.

Karl