Blokart todo.txt
================
Current
-------
Next
----
Bugs
----
Some Undo/Redo implementations are untested.
The shapes' position (or the diagram's position) get out of sync somehow.
Not sure what causes it though.
The control points display in the wrong place, and shape-at-point is off too???
Soon
----
When saving, check if the file has changed since it was loaded
Otherwise code changes may be lost.
Or watch the directory for changes, and offer to re-load when the file is modified outside Blokart.
Later
-----
Edit labels in-place rather than in a TextField
This will offer a better solution for multi-line too.
Dashed lines using alternating end-cap characters???
Line which cross have an option to NOT form a crossroads.
Don't use "merge".
If the existing char != ' ', then check if all-lines { it.isTouching && !waypoints.contains(row,column) }
When growing the diagram from the top in SelectBehaviour, scroll the TextArea down, and don't update currentRow.
If that works, we could also allow control points to be dragged beyond the start too.
Split label across 2 (or more) lines.
A toggle button in EditDiagramLabel, which hides the TextField, and replaces it with a TextArea.
Ideally, we'd introduce a SplitPane, so that the titleBar could be resized.
We could have two different selectionToolbars, the existing one becomes invisible for multi-line,
and another in a SplitPane
Merge labels within the parser as we find them.
Labels at the bottom edge of a Box move in Y when the box is resized.
Also, when just above the bottom edge, and the box height > 3
Bad Code Style
--------------
Shapes have no "interface", and concrete Impl class.
Diagram and Document do, however.
Therefore, it is all too easy to modify a Shape without using History.
There aew no public methods to create private Impl classes, instead they are created directly.
BlockMetaData and related classes are a bit of a mess.
We are using Char as unique keys for Variation, which doesn't work well.
Also, there's a lot of near-duplication of code for each character combination.
A better approach would probably involve combining BasicBlock, rather than Char???
Much Later
----------
There is a flaw in the way lines are rendered, due to the lack of double-walled end-cap glyphs.
When we draw a line segment, we end up drawing :
╺════╸
Note that the end caps are the thick (single walled glyph), as there is no double walled end-cap.
When the end cap is merged with an existing vertical line, it cannot form the "correct" result :
╠════╸
Instead, we get this :
╟════╸
Templates
A set of files/strings which are pictures of a set of Shapes which can be dragged into a diagram.
e.g. A titled Box, or a 3 part box, a Dialog Box (with window decorations and a button bar)
Each Diagram within a file could be a template, with the name being the text on the previous line.
A button to add/remove left/right padding to a label (instead of typing/deleting spaces).
Verification Dock
A rules-based approach which tests for known issues, which would prevent the document from being reloaded intact.
Displays a ListView of problems.
Click one to highlight the problem.
Errors.
Lines touching (unfilled) Box corners
Any (unfilled) Box Corners, which are T or Crossroads.
Labels obscured by other labels
Warnings.
Connection corners hidden by labels
Connections ending at another Connection's corner.
Could also re-parse the document and report :
Missing Boxes
Missing Labels (need to be "clever", so that labels with left/right padding still match).
Check the document before saving and warn if there will be problems reloading it.
Either reparse the plain-text, and check if it roughly the same.
This seems simplest.
We could offer a split view, with the re-parsed version using a different color scheme.
Maybe red for problem areas.
Or use a rules-based approach. e.g. check if box corners are obscured.
DiagramLabel aligned within a box.
Resizing a box which contains it also moves the label appropriately.
Note. Move with moveLabelsWithBox == true would also need to set the labels it contains to centered=false.
Centered would be tricky, because resizing by 1 unit would need to move the label by 1/2 :-(
Could test if new/old width is a even???