Sewing, Spain's General Strike and Plugin Progress

There is a sewing option (in the same menu with pipe). Sewing will build one shape from incident faces. Anyway, the faces individually do not make a bigger face, to say as such, so it does not solve if you want to extrude more faces at once, but if you want to scale more faces uniformly, sewing may be a solution (this happen in the way that OpenCascade handles sewing).
A big interruption for me in those days was Spain's General Strike. Amazingly, things work randomly, but the hardest part was transportation issues, some violence here and there (I donot participate to those acts, but I'm still wondering). This strike was mostly bombarding media in all directions and at least regarding Madrid, the vandalism I found was really pointless.
I was working reviewing how I can handle the UI to be extensible. The single problem is that the solution I thought may duplicate most of the UI code and will render Xaml coding useless (as all Xaml code can be rewritten in C#) so I'm not sure if this is really the solution. Even it will be in this way, I will most likely have to make it hierarchically (like a folder path, where people adds things under: Ribbon/Shapes/Tools/Sewing) and per path node should be defined a factory creator. Anyway I will think more about it, and if I will be blocked I will likely get to look to other area for now.

Options Fixed, Layer minimization

Options Dialog was fixed by hardcoding the layout with other values. Information on layers was minimized to be more compact (not in two rows but just in one)..

Options Dialog change

Options Dialog have right now Windows style of Options (means OK, Cancel & Apply). There are some layout problems and this is the reason that there is no screenshot attached.

AvalonDock Up-To-Date

For drag&dropping and setting dock-able panels we use AvalonDock and the code was made in sync the last version of AvalonDock. For now the themes are not compatible so they need to be updated to look again shiny but this will be fixed soon. 

I was reviewing the docking code too and soon the external component code will be able to add dockable content without creating by itself the dockable components, but just the control that wants to be docked.

A good to have feature is to save the docking configuration but so far I've did not found (I've did not look that deeply though) a solution.

Improved Options Notification

NaroCAD uses the setting setup similar with Mac OS X/GNOME applications, meaning that the settings apply automatically. To make this happen, we use a mechanism that options are written in a NaroCAD document, and when a setup option will change, a notification is sent and all listeners.
This design is fairly inefficient as if for example you change a setting that will adjust the solver sensibility, as side effects, the all options reapply, like but not limited to: update tree view, resetup the color of background shapes, and so on.
Right now to be sure that the old code is not changed, the global notification still exist, but I've made that at least for solver, tree view and OpenCascade parts, they will not listen to global notification, but to the "solver section" ones which corresponds specifically when you change punctually the corresponding pages.
The main benefit will be that options in general will be far more responsive and you will see the applying of options regardless of the size of the future options dialog that they will not get slower and slower.
A small change is that right now there is an Zoom speed option to adjust nicely to your flows. More advanced options may follow later, but if you wanted to do precise drawing, you were out of luck in your previous work.

Layers, Layers, Layers

Layer work is mostly done (it may needs some testing and fixes of problems found). Right now have another view that you can setup your layers and for every shape you have the option to pick the layer by name. In the LayerView you will be able to manage layers, to override the scene colors if you want to pick by layer profile.

Some nice tricks are in this dialog like: every time you pick Add Layer, a random color is generated, another part is that Remove button will be disabled for current layer, and so on.

So you may try this functionality via nightly build.

P.S. The color theme is on my machine, so don't feel attacked for it :)

NaroCAD website

We remind you of our website www.narocad.com. There you can find a forum where you can post messages about all the problems, suggestions, ideas or whatever you have in mind about NaroCAD.There you can find also tutorials, documentation, screenshots and others.

Layers Prototype

Layers will work in a more conventional way than tags.
The interface have still some way to go but the layers will have a selected layer, the current layer you draw on, the layer color, that you may pick if you want to override the shape color for visualization and of course you can hide/show.
Also this prototype will be more polished, but the reason is shown is just to see what is it about.
Add/Remove buttons will be likely down, and Add button will show a dialog where you can set the name and color.
How you define custom colors: every time is picked a random color
See more in the the next nighties for issues and how things will work.

NaroCAD 1.5.1 Released

NaroCAD did improve on bottom line greatly and it is as its code goes the most stable and hopefully a great foundation for future improvements. Quality of the principal emphasis on this build and it was seen as following:
- New testing framework: testing of NaroCAD can be done with low level tests (NUnit unit tests), with visual low level tests, scripting tests that can be launched inside NaroCAD
- Many fixes and code refactoring: the internal relations between components were greatly improved. In many ways things give less dependencies and a shorter, more concise code. This will likely positively impact not only in this release, but also in future release cases when a break of a component will break another components. Also most of NaroCAD's logic can be setup out of NaroCAD's internal assemblies and future work will be to be extended as plugins
- New tool was added: mirror plane but also were fixed selection bugs in previous mirror tools
- Lua replaced with Boo: why not to take advantage of a powerful .NET language? You will get syntax highlighting, live compilation, you can even activate your automation scripting to make complex shapes and to import your custom assemblies
- Improved unit tests: we are covering all basic shape creation and action switching making that NaroCAD will not crash. Anytime the nightly time is running, tests are running and we can see if break something. As the battery of tests will grow, the crash/wrong behavior cases will be out of NaroCAD.
- Reimplemented selection container: this will mean that floating toolbar will get extra information to take in account the face you are on and will give the correct information any time. This will solve a lot of bugs in this area.
- Improved drawing on scene, visual feedback: faces are highlighted with a dark line to be more visible
- Fixed editing on shapes: as it was broken for some time. This is also combined with new selection container, will give less problems to work with. The code was separated and will make possible to add arbitrary tools in the same editing framework.

Download it from here.

Added Boo View, Simpler Handling Code

Boo was added as default scripting engine in NaroCAD. It have equivalent features with Lua but it should be easier to use and as you have "live compiler", you will unlikely get very late errors when you run your code, but when you write it down. The testing suite scripts and some simple actions scripts are posted as samples. The action scripts may change in future, but most likely the script one, no.
As actions code goes, they have to consume data that the required input and pipes provides. Previously this consumption code was made with a big switch statement. Right now you have the possibility to write the inputs you want to handle and a handling function. This cleans up the code, but you can still override and make your custom handling. This custom handling can be used I think in cases with logging and at least for cases when code is not ported to the new way of cleaner code. On a similar note, the notification code have the same capabilities.

Selection bug fixing

Finalized a first version of selection container located into a selection pipe component that works smoothly and doesn't give the flickering effect that appeared in the past. It seems to work well with tools that need to pick a solid or face. It also works well at detecting the face under mouse when a solid is clicked - this makes the floating toolbar populated properly and the tools from floating are completed correctly.
Ciplogic isolated the command line code by making it a container component.
Having all these refactorings and also the Boo changes Naro seems quite stable.

Will continue from now with bug fixing. Among the highest priority bugs that we'll solve these days: Shift select seems to not work properly in all situations, edge select for tools like Fillet3D not working yet, some shapes are disappearing and appearing back on scene.

Component diagrams

Last few days worked at reviewing, separating and improving the Naro components implemented as pipes.
After filling half of a notebook with schemes and drawings decided to use OpenOffice Draw application to share the schemes with other developers of Naro. From now at all architecture related tasks will make drawings and upload them on SVN.
The Diagrams folder from SVN.
The Command Line Diagram from SVN.

Visual Studio License Quirks

This is not necessarily related with NaroCAD but will help me to work with it. The reason may be explained in following lines.
As I've liked (and I still do, at least conceptually) the Delphi language (as an OOP Pascal dialect), I've bought a 1 year subscription license of Oxygene language, which is a .NET version of Delphi language. As the project was bought (relicensed) by Embarcadero, it gave to me a full Delphi Prism (first version) Edition which brings to me a VS Professional version setup just with Oxygene (now Delphi Prism) language.
Why this will helps me? As the dust was set, I just wanted to install it to make some toy coding. And I've discovered that my IDE which was just VS Standard edition, did achieve some Pro features, mostly the WPF/Xaml visual editing. As at that time the subscription of Oxygene costs me somelike 300 euros, and when I've bought the VS Standard with around the same price, it costs me much less than a VS Pro 2008 version which would cost me like 800 euros. In this money anyway I've bought a great tool (Resharper) which improves code quality by lively show code issues (which right now seem to be mostly from imported external components).
When NaroCAD will use VS 2010, and to not depend on SharpDevelop, I may have to look to other very limited Pro or Architect editions that will enable other low cost versions :)

Boo Editing and Tooling Improvments

Hi folks! Boo editing did get an overhaul over how editing is done mostly by:
- syntax highlighting and code folding as expected
- having background compilation as you type, if you stop typing, you will see down a notification with your first code error if is there
- you can write scripts instead of full classes. Scripts are equivalent with "old" Lua scripts, just you will have to use: "Line" instead of "line" and your scripts will work as a charm.
The directory iterative execution of scripts was updated to be able to change the execution speed by picking the interval (in milliseconds) between tests and is also possible to pick in between tests and full code.

Testing Infrastructure Expanded and Explained

Here is a visual description about where testing infrastructure was updated based on Boo power and not only.



The not so visible changes are visible in debug builds: the internal document visualization will not appear if not wanted. Another part is that all unit Lua unit tests were ported to Boo. This will mean richer error messages running the regular NUnit testing suite and will be checked before first line of tests will ever run. There was made a non blocking UI infrastructure, which makes that UI to not freeze and in future may have roles.

There are some bugs and wrong parts in dialogs. I want to make possible mostly that Editing Boo Scripts dialog to be able to write both full scripts (the single option available as for now) and regular scripts and to launch them accordingly. Also I want to make possible that the possible to launch full scripts as part of testing suite. This will make possible to run against NaroCAD complex cases, not just shape creation part, that Lua is capable.

Another small part, but this will be the smallest of all, I want to make a Pause/Resume unit testing and to adjust the speed. This will make sense from visual testing point of view: you will want an unit test suite to pass both as stability test and visually from NaroCAD's point of view.

Boo Scripting Concept

From unit testing standpoint, to add various classes that are called automatically in a testing framework makes sense. It will keep your functionality separated, and can add more logic as is needed.
For people that wants to create a shape, like the lua gear, to define your class, sometimes to derive your class code, to write methods with fixed names, and so on, will add complexity. So the work that was done is that the user can write a body of code, that just have drawing primitives (that have for now the same callback methods as Lua did use) and I will automatically wrap in a class and add all needed dependencies to code to work.
So a script like:
Line(0, 0, 0, 100, 100, 0)
will become internally:
import BooCoreScript from BooCoreScript
internal class BodyBooScript(BooScript):
public def Do():
Line(0, 0, 0, 100, 100, 0);
Also, if the code wrapper will see that you will define your own functions and classes, it will not make automatically indent.
Like:
Line (... )
class Point
X as double
Y as double

This class will become visible and can be callable from the scripting code. So generated class body code will simplify how people can write scripts and will be similar with simplicity of Lua, But for advanced users, they can separate their logic using more complex structures as needed.

Horizontal/Vertical Line fixed

Horizontal/Vertical lines are not now meta-actions and fixed to run with expected behavior. As Command Line stuff was removed, I've changed the code to be able to enable those actions and to launch those two helper lines from integrated command line (in future can be registered any action to be launched from CL).

Command Line Action removal

If you ever wanted to create a shape to the end, you will eventually have to write a visualization component named in NaroCAD's terms as Action or MetaAction. Actions are more lowlevel as they explicitly state the components (named inputs) of NaroCAD that you use and you should handle the data that those components give them to you. If you will want to make it a more straight forward action, mostly in cases you want to have full coverage of command line, tree view selection, and eventually want to start from your funciton of a shape, you should create a MetaAction.
MetaActions are as design a dependency list that was fulfilled by a generator action, named Command Line Action. That action will listen for you all dependencies and will fill dependencies of your meta-action. Eventually, when all dependencies are created, the shape is displayed, the tree view is updated, and so on.
So why was removed? And with what it was replaced? What happen to existing meta-actions code?
The CommandLineAction was removed and for every meta-action was created a corresponding container action named not imaginatively MetaActionContainer. This will have the same logic as CommandLineAction but will bring some advantages from QA standpoint: CLA was duplicating the action switching logic, because if you switch from Line to Circle, which happen that both are meta-actions, NaroCAD framework did not took it as a full switching of action, and CLA had to clean by itself all things that line meta-action does. Switching completely from a line container to a circle container, the bugs will not be related about bugs of switching meta-actions, but about more unlikely and easier to spot full action-switching bugs.
Another good part is that at code level (do you remember the _actionsGraph.SwitchMetaAction(ModifierNames.Line3D) from Boo coding?) there are no special treatment for actions and meta-actions. There were in some cases bugs in unit test suite that were become wrong (because an older action becomes a meta-action) and they will no longer trigger as the code evolve, switching from a meta-action to an action entry will be the same. Another very last thing, is that right now command line switching can be extended to switch in future to actions, not to meta-actions as it was previously as previously this logic was just in Command Line Action based meta-actions, and right now a command line switch may simply be just an action switch, which is a consistent practice.

Options Code Separation

The Options dialog was moved to another assembly and it was made to work application wide. This will simply mean that if in (a foreseeable) future NaroCAD will work with more documents, the Options code will not run more times to setup the options, but just once at startup.
In the next days I will investigate how to make meta-actions as actions, by this meta-actions will have smaller chance to impact one to another.

(Iron)Python is dead, long live the Boo

We use Lua for scripting for some time (for more than an year for now) and what's good about lua is that is easy to be embedded, is fast, have low memory requirements, and so on.
On the other hand, Lua have its own problems when is about unit testing. In fact we have testing that are written in Lua. They mostly test the shape creation with fixed arguments that scripting integration provides. So most probably, as if you create more scripts in Lua, you will have a stable NaroCAD at least on shape creation side.
Anyway, for some time, most of problems were in cases that shapes do not get right arguments, not the cases that they get good ones. For example: if an user inputs a zero value on sphere range, it may happen that Lua's corresponding function to not crash, the same about opencascade function that create this shape, but property grid, solver component may crash as they extract themselves (in cascade) the very same (invalid) shape.
It would be great that some testing to be able to be done inside NaroCAD and to be high level testing, not low level one (that can be covered by Lua). So I've extended a bit the capabilities of importing plugins so they can run at startup. Another part is that I've removed from Debug builds a live debugging window and I've moved in this same plugin.
Also, I've integrated Boo console scripting in this plugin to be a remote to launch custom NaroCAD code.

Why Boo? Firstly, because is not a dead project, as are IronRuby and IronPython.
Another reason, is that have a documented way how to integrate both the compiler and interpreter. This makes to integrate with this code as a breeze. A very important part is that is a static typed .NET language implementation, like C# and VB.NET, meaning that if I give the right object, will have all methods working. This makes that after integration is done, I simply look to an object Test and I execute method RunTest directly.
But what about a person wanting to write his own test, he knows C#, but he doesn't know Boo or (Iron)Python to write this code? The very easy solution is to download SharpDevelop, and if you open NaroCAD in it, go to the a C# file where you have the code, under Tools > Convert Code To > Boo and voila, you have the coding.

I've made three small code samples: one that simply execute something without being NaroCAD related (Hello world sample), another that switch the view to Left view, the very last, shown below, will create a line (in NaroCAD framework) and will write text to command line that will build a line.



import NaroPipes.Actions from NaroPipes
import NaroPipes.Constrants
import Naro.Infrastructure.Interface.Constants from Infrastructure.Interface

class Test:
_actionsGraph as ActionsGraph

def SendCommandLineText(message as string):
commandLineInput = _actionsGraph.InputContainer.Inputs[InputNames.CommandLineView]
commandLineInput.AddData(message)

def RunTest(actionsGraph as ActionsGraph):
_actionsGraph = actionsGraph
_actionsGraph.SwitchMetaAction(ModifierNames.Line3D)
SendCommandLineText("100, 100, 0");
SendCommandLineText("100, 200, 0");

SelectionContainer tests

Added tests at SelectionContainer to automatically check basic cases. In order to make the tests for this class added Moq as mockup framework.

Because for the OpenCascade related functionality we implemented a GeomUtils library that mostly contains static functions I also had to implement an adapter to this to be able to mock GeomUtils functionality.

Setting up a mock is like the following:

var mock = new Mock();
mock.Setup(geomUtils =>
geomUtils.IdentifySelectedNodes(_document.Root)).Returns(selectedShapes);

then I can check if the selection container behaves correctly:

var selectionContainer = new SelectionContainer(mock.Object) {Document = _document};
selectionContainer.SwitchSelectionMode(OCTopAbs_ShapeEnum.TopAbs_SOLID);
selectionContainer.BuildSelections(new Mouse3DPosition(new Point3D(50, 0 , 50), new OCgp_Ax1(), true, false, false, 150, 150));
Assert.IsTrue(selectionContainer.Entities.Count == 1, "invalid number of solid detected shapes");
Assert.IsTrue(selectionContainer[OCTopAbs_ShapeEnum.TopAbs_SOLID].Count == 1, "invalid number of solid detected shapes");
Assert.IsTrue(selectionContainer[OCTopAbs_ShapeEnum.TopAbs_FACE].Count == 1, "invalid number of face detected shapes");

Sneak Peak of Release and Some Future Improvements

NaroCAD have right now a clearer separation to make inputs to be as less coupled as possible. This permit to have two kind of improvements: this release tend to be more stable as it will much rarely will happen that a case that Command Line changes will break Parser changes. In this way an action as polyline (that will draw many lines and have separate integration with command line than regular command line action) will work and will be less affected.
Other area that was improved is that is technically possible (there is a minimalist code to do this) to make a small visualization test that makes clear cases with bogus creation.
Unit testing, that was for some time, right now covers most tools and pass 100%. Does it mean that tools will work flawlessly? They will likely not. But on the other hand, big breakages in future will not make them too broken.
Another good part was Mirror actions: they were ported to be meta-actions. This means in short that they work with a small coding and they will work without having their custom coding.
Selection code, even does not covers all cases yet (bxtrx is working hard on fixing those cases) is much less prone to side effects like one tool did change one selection mode and blocks other tool to do it's selection. Even it will happen, is possible to debug those cases, because there is a single entity that have relations with selection code. So even probably may not be perfect for prime time, will be much more improved.
Which are the areas that will be improved in future?
- because there will be a cleaner house, and dependencies are both explicit, minimal and more sparse, we can in future separate this code out of NaroCAD core to plugins.
- editing is (much) better separated, and is possible technically without big changes to add gismos, and if they will not be ready to be released, they can simply be removed from editing action code
- a missing feature of NaroCAD is it's ability to select "Interactives" like: Dimensions, horizontal/vertical lines
- right now as dependencies are explicit and minimal, it may be possible to attempt at least a multi-document running NaroCAD. Probably Copy/Paste may not run. Many previous cases where things were using global code, right now are not using singletons that much and the cases that are still remaining, probably can be fixed in a timely manner.
- testing will be able to cover more cases. Probably making more complex cases as part of test suite will likely protect users to have more complex cases with broken. It would be nice to have a testing module in NaroCAD (I will like to run some automation against NaroCAD, not just to a minimal extend as is Lua, but to simulate actions changing, and so on). This will be able to cover at least crashes against release builds that do not appear in simple unit testing

Bug fixing and functionality separation

Last days worked at reviewing and separating the code to improve the Naro stability when different parts of his code are changed.

The separation between different components in Naro is made using the pipe and filters pattern. A pipe provides atomic functionality (like we have selection pipe, face picker pipe, mouse 3d pipe) by receiving some input data and generating some output data. Each pipe that implements some functionality is connected to different pipes that provide the functionality it needs as input to generate its output.

Last days worked at finalizing the selection pipe. This pipe receives mouse events and using a selection container class generates and stores selection related information (like selected shapes, faces under mouse click).
Reviewed, simplified, improved use cases and made cleanup on the face picker pipe, editing action, none action, face picker visual hint pipe, editing tools input.
After these changes worked at fixing the tools affected by these changes.

Naro is quite stable at the moment it starts to get ready for the 1.5.1 release version. In about 1-2 days the release should be ready.

Many of the annoying bugs were removed and hopefully the components that generated them isolated well enough not to propagate to other components. Drawing tools started working.

Among the big issues remained to fix for 1.5.1 are: problems related to selection container (when clicking on one solid face the generated info is not good enough for all cases making the floating toolbar not having all tools that can be applied on the mouse click area), some command line parsing problems, shape editing needs some review and fixing for the latest changes.

Better AutoFace Performance and Code Cleanup

There are some components in code that would like some improvements.

We use backtracking to do autoface. AutoFace is a feature of NaroCAD that when you draw lines, and you make a continuous shape, it will create a face automatically from it. This can be expensive operation as NaroCAD searched naively if shapes two by two are chained and there was a lot of back and forth bookkeeping. This part was not changed, because is needed to explore (allmost) all possible ways to combine.

The part was really improved was how candidates are searched: before backtracking was done the candidates combinations are precomputed. This improves greatly the solution searching space and in the gear shape creation the Auto-shape code from a 200 teethes gear will go down from 97 to 3 seconds. You will most likely not notice that great improvements, but if you will have more lines/splines/arcs in your scene, you will not get "delays" as you move mouse around because the Auto-Face code is trying to preview to you if you have combined a face there or not.

The (meta)actions with hidden side effects were fixed and they use corresponding code components.

Other Small Fixes

Some problems were found and fixed in the last nightly build:
- multiple flickering of floating toolbar when in edit mode you clicked on a shape
- sphere and extrude was not respecting code rules, and was possible to make some problematic side effects (probably other meta actions are affected, I will look for this). Those coding rules are about which entities are modified. Anyway, saying this, any of those actions that do "break" the side effects, they do their own side-effects similar with the original design. So even if those fixes are not in place, the code will not have problems as for current code. But the problems may appear if a future tool will extract some live information (like editing tool, but in the time of running the metaAction) and the respecting "creating entity" is not setup right, so that tool cannot extract that information. I've made a small tool that will compute the bounding box lively to the shapes are created (have to be enabled specially in code), and can be tested visually if the code will change the corresponding objects.
- invalid opening of options file will not show to you like four or more times some annoying message boxes in a chain for every invalid value that could not be read. Anyway, those errors are logged and if the application will crash (not wanted, but it could happen), and will show this developer friendly information.

Mirror Plane and fixes

The nightly build is about fixing most of found issues. Selection code works much better, tools are fixed one by one (property grid random deactivation, spline, linear pattern is now meta-action, making the code to be more concise and less bug prone - and some selection bugs that affected this action seem to be fixed).
Mirror plane/face was added to existing Mirror Point/Mirror Line and also shares the same behavior as the latter ones.
So for more courageous, you may try to get the nightly build.

Mirror Line and Mirror Point new logic

Mirror Line and Mirror Point behave right now similar with other CAD packages: when you mirror a shape against a line or a point, a mirror instance shape is created, but after this you can delete the reference mirror shape.
The downside is that you cannot propagate after you create mirror, but on the other hand, in real life is less probable that you will move your line and mirror. Also, as the shape is mirrored by it's transformation, you can afterward modify mirror's values in a consistent way, as the new shape is not a "MirrorLine" shape, but a real clone of the rectangle, box, sphere, and so on.
If for example you will think later that you want to move the reference mirror line/point, you move them and create mirror again. But if you just wanted to create this reference just as helper, right now you can delete it nicely, without making your mirrors to be deleted also.

NaroCAD Forum is now available

The NaroCAD website (www.narocad.com) has now support forum for users and possible contributors and you can start posting your NaroCAD related questions, suggestions and feedback on the forum.

Fixing Old Issues

As bxtrx works how selection is handled and it is in a sensible part of our code (selection), and I did not want to affect him with my changes, the work was done in other areas. Like circle's dimension was bad placed, color of wires cannot be setup (this bug was like from NaroCAD 1.0 times), ellipse minor and major radius can be now constrained, line's length can be setup with negative value.
So, if selection will be fixed, very likely you will get a better build all over the line.