Some Stuff

So, there was a question on the cdk-devel mailing list about bounding boxes, reactions, and text. An unfortunate consequence of the new design is that the renderer will not calculate bounding boxes that can fully contain the text. Concretely, this is what it would look like (not made in JCP!) The blue box is the bounds that would be created, which is minimal with respect to the atom centers. The black box is the bounds that should be created, if we respected the text size. The problem is, the size of text is not known until the point it is drawn. Or, more precisely, until we have some sort of GraphicsContext to ask about the width in a particular font. So, a two-pass system was suggested. When this was mentioned before, I was dismissive - perhaps even rude. Sorry about that Egon, Sam. I still think it is better avoided; in the case of transparency, I don't know why alpha values can't be used for fill colours. I understand there was some SWT problems..? Anyway, here is a sketch...

Just a small, informal diagram of how the new rendering system works, to balance out all the speculative UML sketches I made... I have not shown the elements inside the element groups, but they are things like line elements, oval elements, and so on.

I wanted to show something that hints at the things that the new architecture can afford us: This is using a Java2D graphics Paint object to make it look like chalk...kindof. It's a very simplistic way of doing it by making a small image with a random number of white, gray, lightgray, and black pixels. edit: it doesn't look so good at small scales some tweaking of stroke widths and so on is essential.

Comes from too much screen-time: although refactoring often seems like running on the spot (you get nowhere fast), things happen behind the scenes.. A short code snippet.

I have made attempts over the years to draw triangles and circles like, for example, this: (in fact, this was drawn by David Westhead's code). There is a small design decision to be made between representing drawing elements as basic geometry or as symbols . A symbol may be the same as a geometric element (like a circle), but it might be a combination of them. Consider the 'N' and 'C' in boxes, above. Or this image: where the mass number and charge are separate text elements on the left, and part of the whole symbol on the right. Neither is a 'better' way of doing things; they each have their advantages - and disadvantages. It can be a lot clearer to use symbols, as each model object (atom, bond, helix, gene, cell) has a corresponding representation, and then a diagram composes the symbols into a manageable whole. On the other hand, you can re-use elements in different combinations for diagrams. A general vector drawing package would have Line, Text, Rectang...

So, I'm now partly sold on the power of a Visitor approach to rendering. Consider this snippet: if (clicked) diagram.accept(new DropShadowVisitor(g, 5, -5); else         diagram.accept(new DrawVisitor(g)); What this is doing is drawing a diagram normally unless the mouse is clicked, when it draws with a drop shadow. I see that the beauty of this is the ability to manipulate functionality as a block (just as in languages where you can pass around functions...). However, I should point out that the approach has its tricky rapids as well as such smooth sailing. The image below is a spot-the-difference (click for bigger): On the left is the version drawn by a naive first try at the drop visitor. Its methods look like this, the visitText(Text text) method: g.setColor(Color.LIGHT_GRAY); g.drawString(text.text, text.x, text.y); g.setColor(Color.BLACK); g.drawString(text.text, text.x + dx, text.y + dy); The problem with this code is subtle - the elements ar...

This is a sketch of my understanding of Arvid's renderer design: I say 'my understanding' with good reason - a diagram can be biased, even a formal(ish) one like this, so I don't claim that this is definitive! It is interesting, anyway, as it seems to be a combination of a Composite and a Visitor pattern. The RenderingModel implements IRenderingElement (and Iterable of IRenderingElements), which is Composite. The Modules are Elements in the Visitor pattern, and the Elements are Visitors. edit: What nonsense I talk! The IRenderingElements are Elements and the  IRenderingModules are Visitors. That's better.

Fonts and text are always a pain when drawing vector graphics! After hitting myself over the head over a stupid bug in my zoom tests (like this:) JButton inButton = new JButton("IN"); inButton.setActionCommand("IN"); JButton outButton = new JButton("OUT"); inButton.setActionCommand("OUT"); I got center scaling implemented in my branch. Which lets me test a different approach to managing fonts. I had tried to be clever and do something like: GlyphVector glyphs = font.createGlyphVector("N"); ArrayList shapes = new ArrayList (); for (int i = 0; i < glyphs.getNumberOfGlyphs(); i++) { shapes.add(affineTransform.getTransformedShape(glyphs.get(i))); } but letter shapes fill horribly with lots of missing pixels. Anyway, I eventually settled on just storing the Glyphs themselves. Less pure, but it works, and it allows the size of TextSymbols to be computed and used by the class in between drawing. So, for fonts there had to be a way in my a...

Sorry, but some more opaque UML diagram from the cdk.controller package. First, the Controller2DModules: Which is very simple, although the names are a bit clumsy. I would favour using a sub-package called "module" and then having "AddAtomModule", "ChangeFormalChargeModule", and so on. Doesn't really matter, as they will likely not be used very often. The other image is more complex; it shows the class that implements IChemModelRelay and how it interacts with the two current Swing event handlers. The circles represent interfaces. The MouseListener and MouseMotionListener are, of course, the interfaces from the java.awt package that are normally used by java programs. Now to figure out how to actually use all this!

One way to understand a piece of software architecture is to make a diagram out of it: Also, it's an excuse to make another diagram... Oh, and here's the version with packages:

I knocked up a small program to analyse the various options that the Renderer2DModel supports. It uses reflection to get the set methods and create controls, then calls the appropriate get method when the control changes. Another aspect of the Java2DRenderer it shows is that many of the options do nothing as they are not wired in. Finally, it is clear that there are certain options that probably shouldn't be there, such as the selection box, or are quite mysterious, such as the ClipboardContent...

Thorsten's patch here: https://sourceforge.net/tracker/index.php?func=detail&aid=2128802&group_id=20024&atid=320024 makes things much better. I don't yet know exactly why, but better: (ignore the "in" and "out", they were an experiment and not relevant.