Last changes so far

All actions will be moved to a state-machine as presented before. All simple actions that require an axis, Point3d or a double value (like a circle require an axis that's the plane is on and the center and a range) will work. The actions that do use face/shape picking mostly crash. The reason is that there is not a simple step way to decide which shape/face is selected in current's Naro framework.
Those states will be exposed as command line with a similar with Lua scripting.

So for now are tested to work the next actions: Circle, Line, Rectangle. Working but crashing randomly are: Boolean operations, Cylinder, Cone. And with not (known) reason: Extrude.

Anyway: those actions are not exposed yet in a easy way for user so you will not be affected. Just if you want to enable the actions for now you have to explicitly activate via Control-Space.

Modifiers new infrastructure

Do you remember NewShapeModifier? NaroCAD's View framework is created around Modifiers (also named Actions) like: View Actions (Top, Left, Reset), Shape(circle, rectangle), Tools (Extrude, Cut, Boolean operations). NewShapeModifier was an action which starting from a specific function, creates an already made action. But because it tried to solve too many problems in a generic way, the code always was need some patching and was hard to use. The big advantage was also that it starts from the shape's definition (like a line will require two points, so the action will query first point, second point, and that's all).

Some of it's ideas were really nice, but they could not work nice as it was either: too generic or either too specific. Also, in the quest of solving a command line completion, the actions have no exposed granularity to be used interleaved command line values and mouse clicks.

For now there is an action that can be started with Control+Space and can be used just to test this actions.

Those actions are named for now MetaActions (I did not found another proper name).

Which are the big differences from the NewShapeModifer (NSM)?

- NSM creates a build action only from function names and are fixed. MetaActions (MA) are getting a dependency object to be filled in by action. If the action will want to use the function's name, it can do it right away. But after this it can customize the dependency like it can remove some unused steps.

-NSM do not let customize the draw step, intermediary solve of dependencies. MA let you change dependencies (remove/add if you want), setup some values as defaults, let you customize even the final shape that is drawn. MA also uses the previous document refactorings, so it will be a smaller chance to remain artifacts by persons that draw custom code.

- NSM because was a monolith that cannot be changed, some operations like: AutoFace (when lines create a profile, a face is generated), CalculateIntersections (compute local areas on face shapes), could not be customized to not be computed when do not make sense (like: a sphere do not expose any face so why to calculate intersections on the same plane). AutoReset: if true will mean that action will continue to draw the same shape that was doing initially. (like when you draw a sphere, to continue to draw spheres with the subsequent clicks). Right now those are properties can be setup right away.

The code is subject of change but the code gets really better and is as follows:

public class LineMetaAction: MetaActionBase

{

public override void FillUiDependencies (MetaActionDependencies dependency)

{

dependency.FunctionName = FunctionNames.Line;

dependency.CalculateIntersections = true;

dependency.AutoFace = true;

dependency.AutoReset = true;

}

}

To define a custom field you can do it like this:

class BooleanFuseMetaAction: MetaActionBase

{

public override void FillUiDependencies(MetaActionDependencies dependency)

{

dependency.FunctionName = FunctionNames.Boolean;

dependency.Steps[2].Integer = 0;

dependency.Steps[2].IsDefaultValue = true;

dependency.AutoReset = true;

}

}

The code is reduced for those shapes by 5-6 times also, because the modifiers' code is not exposed to those actions.

The following shapes work right now: all that are dependent of Point3D, Axis3D, Real (which can be computed as a distance of the last clicked point and the current click point). For now do not work Reference shapes and custom cases of Reference shapes (like Extrude) which should froze the plane.

I will try to continue porting and find issues of porting code of the actions to become metaactions, and at the end if there are no big issues, will wrap the steps to a command line interface.

WPF Layout

Sketched a new layout for NaroCad with WPF that also supports docking. On the top it contains the Ribbon control. The project is made in parallel with the actual Windows Forms project, the current functionality is not affected by the GUI changes.
The next steps will be to map OpenCascade to render on the WPF areas, then wire the events, put the grid and tree view list as controls and if not working replace them with WPF versions of them.

GUI restructuring

Didn't advance too much on the GUI restructuring.
Decided to replace the main Form with a WPF one, for now the WPF form is built in parallel with the current form. Succeeded also to integrate the Weifen Luo docking control on it. Evaluating if there is any point on keeping the docking control and windows or to replace them with WPF versions together with the main form.
After integrating all these elements the next step will be to map OpenCascade to render on the forms and also wire the toolbar events.

Lua and Non Related Changes

Lua will need some improvements and I hope that today I've made a half of image what changes will be needed. I'm still not 100% sure what changes will be but at least I know what are the most facing problems I will encounter.

The other change done this days is about how attributes worked to be identified and what can be the problems that persons might get using the old code. The tree of nodes can get attributes of any given type as long as they are registered. In fact that can make to appear a class of problems. One of the problem is that the conflicting names. NaroCAD used Integer, Real and Color names for storing specific values that may be too generic. This is really great as long as other person wanting to add their custom type will not colide with already defined types. Right now, because we did not write in C++, but in C#, there is a very simple way to create a type that do not collide: use the Reflection .NET API and picking the name and hashing from there. In the past there was a probability (very small, but it could) make that even you had different strings, the generated hashes may collide.

Right now, Type.GetHashCode() have no coliding value as is unique for type IDs. Also is really great because the code will not make you define a custom constant and to write some "magic code".
So to define in past your interpreter the code was like:
public RealInterpreter() : base(nameId) { }
static int nameId = AttributeInterpreterFactory.Register(InterpreterNames.Real);

Right now the code is:
public RealInterpreter() : base() { }
And the registering can be done anywhere else just in case of using deserialize/save to disk and no associated string constant (InterpreterNames.Real) needed.

Looking still for improving the Lua integration

Lua integration is not straight simple. Based on this, I've review again the code. By this I've did cleanup a bit a function's code. This change will mostly merge function shape dependencies code with function code. Also, the old name of OCAF was completely removed as we have for more of 6 months than we replaced the OCAF code with a C# implementation using the same principles.

Note: I'm on irc://irc.freenode.net at #narocad room for persons that wants to talk lively and don't use Skype or want for simple topics like install fails on your machine or setup the build environment. I will not be all time online but when I will be I will respond :)

GUI improvements

Started working at improving the GUI.
Analyzed WPF with SCSF integration and also started evaluating the Ribbon control for a possible integration on the interface.

Looking for improving the Lua integration

NaroCAD have two level frameworks: model ones (high level functions to define shapes, tree of data interpreters/attributes, a document live-cycle with undo-redo) and a view one that is defined as a set of inputs/modifiers.
Lua right now works at the model level, so to make better integration it should be made as a modifier. For this there are two options: make a Lua only action that is defined, or one more intrusive that all actions will give descriptions to Lua working. The second approach is tricky for actions like: extrude that at their selves depends on other shapes, or for shapes that are not right defined restrictions. An extrude in itself right now it asks for a shape to be extruded, but the modifier creates an face that was clicked. I will have to think more for a proper design/solution.

NaroCAD 1.2.1 RC released

We did create an 1.2.1RC in which we include fixes that appears over the last iteration and we uploaded to a local page.

If this release will show no major/blocker bugs, will become 1.2.1.

One note: I'm are really glad that on sourceforge page it shows positive thumbs. If you know something that do not make you happy, please point it out. We will be glad to get really positive reviews. So: if something goes great, say to anyone, if does not, say it (only) to us :)

Note: It may take some time until is uploaded as the uploaded archive did seem to not work. When I will upload it (again) this notice will be removed.

Bug fixing

This week worked at stabilizing the application. It is not as stable as 1.2 version but the new tools added should compensate in value.

35 more bugs remained to be solved. The most important one that would be good to be solved on this week is Delete on intersected shapes. Currently after Delete the intersection is regenerated so the shape doesn't disappear.

Async UI and automatically applicable UI

Creating good user interfaces there is really a science in itself. The reason is that many programmmers (as myself) are focused on the engineer part and less on how things are accessible for user.

If you know Joel Spolsky, he presents very good reasons why user interfaces are complex. The quote that is the most important in my oppinion from all topic is this: "A bunch of tiny frustrations, and a bunch of tiny successes. But they added up. Even something which seems like a tiny, inconsequential frustration affects your mood. Your emotions don't seem to care about the magnitude of the event, only the quality."

Using various interfaces, I am likely attracted with Mac OS X/GNOME interfaces: they stride to be minimalist at first and try to hide to user most of options. Also, they emphatize with automatically apply UI and the buttons are tend to be "reversed" compared with older applications on Windows. The reason that most persons are right-handed persons and they will more likely hit the right-most button if they will not look at what is it.

Some reasons of being minimalist as interface is to not overwhelm the user from one side, and picking defaults that (almost) always work on the other side. The reason of applying automatically the interface is great that you will mostly change your options and you will save a step by clicking again on OK (if you not click wrong on cancel and have a frustration). Another reason in NaroCAD at least is that some options are really frustrating when you pick a wrong checkbox and close. You will have to open again options, to go back to that specific Options' page, and uncheck your options. If you click a wrong option and you see the results right away, you don't lose the "context" by closing the dialog and move back.

So based with tha good faith and following the giants in UI design, I've applied most of that knowledge on NaroCAD. Today I've just finished an automatically applying non-modal Options dialog. In this way you can test if your Solver options (the component that is used for autoaligning your mouse point to various references like corner points, paralel lines, paralel planes) without going back and forth. Also the dialog have in bottom-left corner an Undo/Redo arrows pair, so if you get wrong some arguments and you just found that the defaults are better, you may use the defaults right away applying the Undo. Also the Undo will say which page was changed when the undo is applied.

The dialog of Cut Preview was also changed to be asynchronous also, so you can rotate right now the scene as much as you preview the cut.

You may download the latest build from here.

Lua wrong arguments crash fixed

Lua in case there was an incorrect command, even as simple as missing an argument, you the user was facing a Naro crash. This was addressed. Also there is a help button that is mapped over help() method in Lua which gives to you online help about which arguments you should provide for command line you want to execute.

Fixing Regressions

Latest developments did make some shapes/tools to not work. Hopefully that problems were addressed today. Some testing may be still needed, but the code is really close to previous exposed functionality.

To speedup launching of visual tools, I've made a dialog to launch visual modifiers. To launch them, you should press Control + Space from the SVN version (or wait for the next version).

Also, it was setup a Mercurial source tree for NaroCAD project in parallel with SVN. Using Mercurial may in future simplify cases like working in experimental features and branching. Mercurial is a distributed VCS which means that you can commit in your separate branch without depending on sourceforge for some time. To understand Mercurial, you may look to a very similar (but a bit more complex) system (Git) .

Closed Iteration 1.11

Closed Iteration 1.11 and will enter into the bug fixing week.

Among the new features added in the iteration 1.11:
- AutoSave functionality - restoring in the case of a crash,
- AutoUpdate functionality,
- Added Torus solid,
- Implemented a Direction tool - shows the direction of a Face,
- Add/Remove nodes to spline tools,
- Copy/Paste with Reference, the duplicated shapes are influenced by changes to original shapes,
- Drawing of line parallel to face, Drawing of line normal to face,
- Lua automatic tests, increased the number of commands exported,
- Offset 2D and Offset 3D features,
- Cleaned up and improved the Save/Open/Export/Import functionality,
- Improved bug tracker to send more than one file at a time.

Extrude Preview

When Cut Preview was shown as a usability feature, the first comment was to make Extrude previewable. So as the refactor of yesterday had some issues, going to address the extrude's ones, I found really easy to add preview code (with the same color theme). Right now it miss Dimension but it will be addressed in a day or two.

C# compiling note: To include various classes over the project, you can do it by "using" keyword and a namespace. Removing unused "using" in most files of the NaroCAD project reduces fairly significant the compiling time from around 8 seconds to 7 seconds in a 2.13 GHz dual-core machine (that may depend on your CPU speed, disk drive, cache sizes, how your sourcecode is organized, etc.) but in fact an improvement say just this: if you use Visual C# newer than 2005, always do a "Sort and Remove" refactor option as it will save later some of your time.

Refactorings... and again Refactorings

Yesterday I've started a refactor to try to resolve a class of problems. Firstly, how is organized Naro code, and what is the relation with OpenCascade?

NaroCAD is built as MVC, in multiple levels, but in short, the primitives are stored persistently in a structure named Document. This document have a tree which is somehow similar with XML DOM (but indexed a bit differenly to have better access time), and livecycle (like Undo, Redo). The tree nodes can store arbitrary data, or as needed it can store shapes that based on that data, to builds visual OpenCascade shapes. Those high level shapes are stored in two ways: as model with specific OpenCascade code named Functions and as OpenCascade View, if a document have an attached OpenCascade Context the view show/hide, color, etc. is done automatically (using a custom attribute) based on propagation, changing in attributes that are on the node. So making those lines short, A document attached to OpenCascade, it will wrap it with high level primitives and tools (like Extrude, Circle, etc.)

To make them appear in the final document, users expect a preview, so for this there is a separate component that do only visual work (that at the end will create to you a shape like circle you wanted). This component describe actions that users do click that are named Modifiers. A modifier starts from the moment you click the button in toolbar and continues until user press escape or click on other toolbar button.

For some shapes it simply work as to create the shape in-place and to simply update the dependent data lively. For older code or for cases when the code was not thought as that way, the OpenCascade code was done by hand. So by this, some actions did use a AIS_Interactive visual shape that was updated as Circle first, Cylinder after and added/removed manually to OpenCascade's cotnext.

The refactor did start from observation that is much easier to use NaroCAD's framework to add a circle in Document (and document will do by itself the circle live-cycle) than to write it's OpenCascade code. Also we remove the copy/paste code of creating circle. In case that circle code will have a small issue, the fix should be done wherever the code was the same in preview. Want to clean your scene from when your action starts? Document.Revert(); is just enough in all cases. No if(TemporaryShape!=null){ Context.Remove(TemporaryShape, true); }

How many shapes are affected by this refactor? The code affects around 30 modifiers in code, but this new model in all cases reduce the code line count, make all code to not be OCC like but more C#/NaroCAD framework like. The other advantage is that if your final shape is not right defined, it can be reveted the code without having the possibility that by mistake some temporary shapes are remaining in OCC context.

Badly Understood Freedom ...

Do you know that Internet Explorer is much more popular because is the default browser?This is said and is accepted as a fact. So persons took this as a way to justify that Microsoft should offer for alternate implementations in their operating system. This is for me unprecendented but for some (that have browsers) is a good thing. This piece of news is here.

I do agree that persons are not well educated and if I will say to someone: use Firefox (my choice) because is the best, and that person do not have as first concern which browser run on it's machine, will install Firefox regardless if is safer or not than IE.

The issue I want to talk at large is why NaroCAD do not support alternate OSes like Linux. Firstly NaroCAD as a project with a small team so only supporting the install script for any new platform will mean spend time without any result in a short term. Because of this, if we will want contributions Linux will be as good as we will get a win lately in our free time that we spend developing every new feature you met. If Linux in itself is good for servers, have a fairly good toolset for developping applications, including Mono (a free .NET implementation) and OpenCascade version of it, integrating all is not as a free lunch.

- First drawback are the wrappers, which we decide for shortening the time we will generate them (wrappers are a bridge between C++ world - where OpenCascade stands - and .NET world where NaroCAD is implemented). They use over 1000 classes and compilation of them take some time. We pick C++.NET for having only one wrapper. I've tried to spend some time developing a C++/C/C# wrapper but time spent on it do not result on a new wrapper and the time I have is not justifiable.

- The second problem is Windows.Forms GUI toolkit that we use. Mono's Windows Forms implementation is fairly good, but integrates bad with OpenGL at large and our bridge as we will use OpenCascade wrappers will need to get the Windows' X11 handle at the end or to create a separate package just for that. Or To use Qyoto wrappers of Qt (.NET wrappers) and to try to make a blackbox implementation of it. Which is not trivial again as we will have to reimplement all Windows.Forms in Qt.

The good part is that NaroCAD had separated OpenCascade code and probably if a company will want Naro ported to another GUI toolkit, excluding the OpenGL talked part, it can simply change some source-data classes that expose the same for Naro's framework.

Wrappers have still issues to the day (even we use C++.NET) but are much easier to address those than to create a completely new one. Also, the OS price is not relevant (excluding for a very poor country, but students get Windows for free from their university, or pirate it anyway).

We did try to optimize a lot of NaroCAD's code (or I personally did), so it should run on a netbook that do not cost more than 300 dollars in US, which includes Windows XP which runs Naro.

The easiest solution to make things working with Naro, is just to fix a small piece of code, or even contribute fixing the installer experience. If you have no PC experience, is also easy to submit a bug report, and your feedback can give for us cases when NaroCAD just did not work as you wish and when we have time, we will address those.

Bug submit working again

With some advices from my brother and with some fuzzy work, bug submiting was fixed. So by this we highly encourage you to use the latest nightly version from here. Is not a perfect version but at least your annoyances can be submited, reviewed and fixed.

Note: today I also reviewed and fixed an annoyance of deselecting on editing component. Cleanup a bit (I will try to do more tomorrow) on modifiers. This cleanup mostly reduce bigger code and OCC code like with NaroCAD version. At the end the same OpenCascade is runned but the code of OpenCascade should be removed (as much as possible) from modifiers (to be easier to be done the fixing). Lua was enriched with some extra commands that were not wrapped (like pipe and revolve).
For example code in Arc action like:
var centerCoord = new OCgp_Ax2();
centerCoord.SetAxis(_axis);
var circle = new OCgp_Circ(centerCoord, radius);
var edge = new OCBRepBuilderAPI_MakeEdge(circle).Edge();
OCTopoDS_Wire circleWire = new OCBRepBuilderAPI_MakeWire(edge).Wire();
TemporaryShape = new OCAIS_Shape(circleWire);
TemporaryShape.SetColor(OCQuantity_NameOfColor.Quantity_NOC_RED);

Context.Display(TemporaryShape, true);

Becomes:
Document.Revert();
Document.Transact();
_temporary = new NodeBuilder(Document.Root, FunctionNames.Circle);
_temporary.Dependency[0].Axis3D = _axis;
_temporary.Dependency[1].Real = radius;
_temporary.Color = Color.Red;
_temporary.ExecuteFunction();

I will cleanup tomorrow more of modifiers code and I will prepare for bug fixing in the next week.

Line parallel to face

Implemented a tool that draws a line parallel to a selected face.

Will continue with implementing a snap to grid in sketching mode to improve the sketching capabilities.

Lua improvements

Lua have been improved and crash unit'tests can be written completely in Lua without any C# specific code. Also an execute method is exposed that can run other lua scripts. It can be handy to create a specific setup in unit-tests but also in your NaroCAD test-drive.

Nightly build created

Today I tried to upload and make it enable the upload code. This code is enabled but still experimental (it do not get last bxtrx changes but tomorrow's updates will go in as an update if everything will work right). Please download this update-enabled build from here.

Offset 3D

Implemented offset on solids. There were at least two possibilities to offset solids one using BRepOffset_MakeOffset and one using BRepPrimAPI_MakeThickSolid. The implemented tool is using the first API and generates an offset duplicate after the selected solid. On next iterations will schedule also some offsetting that creates shells and other shelling tools (that wold be using the second API).
The offset shape is parametrically influenced by the modifications on source objects. Implemented also descriptor for offset so that the offset can be changed in the property grid.