Start to work to Point to Point Constraint

Did you ever want to do get better constraints? One may be that you want to enforce that the distance between two points of two shapes to remain constrained and fixed. For this cause a new constraint was added as a separate action. It does not work fully stable yet, but I will hope to get it better in the days that follows.
Also I will try to look for a consistency problem that sometimes happen (like you cannot extrude a shape if is a line, or a curved surface) and I will try to make an enforcement code for this.
Also some wrong working properties in the nighly build were largely fixed, including filtering that was broken.

Meta Action Unit Tests

A tool like the line tool has two main parts:
- a Function that knows how to build the shape from its dependencies (like building a line from 2 points given as dependencies),
- a Meta Action that collects data from mouse and command line, sets the function dependencies and executes it to build the shape.

To improve the code quality and detect bugs as soon as possible we implemented Lua scripts that execute all Functions from all tools to see if they are broken or not.

Now started developing unit tests that check the Meta Actions. Finalized the code that configures and sets all elements (stubs for views, pipes through which mouse points are transmitted, etc) needed for tests. Will continue with implementing for the point tool the actual tests that checks if it is ok.

WPF Property Grid (Mostly) Done

WPF Property Grid porting is complete (some bugs may still be there, or one or two non default properties to not be there) but all shapes have a very close behavior with was before. Because you have filtering, your work may work even more convenient with the new WPF property dialog.

You may test it using Nightly build from the right.

WPF grid control

First version of WPF property grid started working. It supports general shape properties and it has also full support for the line shape. The first step of this prototipe task is finished.

WPF Property Grid Progress

WPF property dialog did got some attention too. This will mostly mean that all properties can be added with custom dialogs from WPF and some filtering is also done. When all shapes will be moved to the new code, will mean to you that you can get a consistent look & feel with the rest of WPF theme that NaroCAD have.

New WPF Grid Infrastructure

Property Grid component is fairly old in our code-base and is one component that was not ported to WPF when the rest of NaroCAD was moved. In fact slow but sure was also moved the Tree View and some nice changes were added to the WPF version of TreeView just in the last version released.
What changes are here in which will consist this change?
Firstly the controls will respect the MVC and the view will be separated from code that setup the model. This will may mean a lot of good things like: if under the same model shape can be picked three kind of controls (for example parallel line), right now is possible.
Another good thing is that code was nicely changed to not use a ViewGuard class, but simply to use: BeginUpdate(); ... EndVisualUpdate() or EndUpdate() depending if OpenCascade's view need to be updated or not.
So soon (in the next version that will be in around two weeks and a half) may be expected custom controls to be done for property grid.
A screenshot will follow as soon a more complete control is done.

Editing Logic Improved

Editing was somehow broken before but some fixes in logic were landed. Also the code in the editing handlers code was also cleaned up.This will mostly mean that will happen to not get deselecting operations when you edit a (2D) shape.
Those fixes did happen just after release, so you may see them in the nightly build.

NaroCAD 1.4.3 Released

NaroCAD 1.4.3. is released.

- This includes the first build changing the build environment from a central one (Subversion) to a distributed one (Mercurial),
- Lua shapes are drawn as a part of unit testing before installer is made, this means more stable builds,
- Output Debug Dialog gives meaningful information (that if you will want to develop on Naro framework),
- Tree-View gives more information and in a more meaningful way following references,
- Torus gets property grid description and not only,
- constraints for rectangle, circle and edge length are accessible in a separate Constraints tab,
- Box logic was made using rectangle as a base, instead the old NaroCAD rectangle,
- auto-face will get better working with arc of circle and not only,
- face split was disabled to make things more clear,
- bug fixing in more areas, including crashes found in older versions, crashes on updater and when activating auto-save for shapes that did not work right.

You may download this release from here.

Two Arcs Autoface and Other Fixes

There are some problems that NaroCAD had for a longer time and one of the most common one is that if you created two arcs that have an internal area, they were not auto-intersecting. That was fixed.
Also a bug that appears when some shapes did get a wrong reference list (like a circular reference), they can lead to make the tree populate as right now goes as many levels in depth, to get a stack overflow. This was also fixed on more levels: firstly it was fixed the case of invalid references. Secondly there is a custom logic to block reversed reference order. If this happens, tree will not display it. The last level of protection (the naive one) is that if the tree will go as deep as 5 levels, it will not expand anymore.
The latest fix is on deleting shapes. It may happen that some shapes to reference others when you delete. The old code did not remove them for more reasons (like auto-face), and sometimes even it hides them, it was note remove them effectively from tree. Right now the code works like a mark and sweep GC meaning that all unreachable shapes from user point of view are removed. If at least one shape will reference your shape, this deletion will be blocked.
Sometimes if you fast click on a tree and you delete items, it may happen that selection to not be active and pressing delete, to give a crash in tree. This was also fixed. Tomorrow a release preview will be done.
Just if you want to test if everything works as expected, you may try the nighly build link from the right.

Bug fixing(2)

Today continued bug fixing and application stabilization. Many crashes were removed, fixed problems related to spline, circle, selection, magic points.

Will continue with reviewing the edit mode for 2D shapes as the code wasn't updated for a while and there are many bugs related to it.

Bug fixing

Started fixing newer and older bugs also closed the bugs that were already fixed in the latest version of code from devel. Reduced number of bugs with about 30 bugs, around 75 more bugs remained to close.
Will focus from now on repairing the crash bugs, fix tools, enabling back tool functionality.

Merge window closed

Closed merge window. All finalized functionality is pushed on the devel repository.

Until the end of the week bug fixing will be made on devel repository then at the end of the week everything will be moved on stable repository.
The iteration will close with a review meeting and a retrospective meeting.

Entering in Bug Fixing Mode

As we added various fixes in Tree View or in constraints to make possible simple, yet effective constraints to setup, some things may not work as expected as they are new and practically untested. For this reason, this week we try to fix this found problems. Also, for this reason the nightly build will not be updated at least till tomorrow, as this stage may have some crashes.
Just as of today the concentric circle and sphere made NaroCAD to crash (right now is fixed). Also one fix was needed to add some small functionality (Torus should be editable in property grid) but expect that from nightly build quality will increase a bit in the following bug fixing days.
Just if you will want to play with code, you will need to get the devel branch and compile by hand for now.

Why Commenting Code Is Evil...

If you never read books about good coding, I recommend warmly one of them: Clean Code. This book emphasis a lot on practices you should follow on writing your code readable.

Some of those practices may appear for some as shortsighted like the part of not commenting code. We know that commenting code is an issue of understand fairly big code bases. From my point of view NaroCAD is mostly medium code-base so can be taken (at least most of it) in mind of one developer (NaroCAD have close of 1000 classes but as you remove some "infrastructure classes", you will remain simply with much fewer classes and you can get an full overview about it).

So why is better to not comment your code? There are opinion that might be a lot of reasons why to comment your code: for example you want to know what does a function. But this can simply show simply other problems in your code like: does the function name is really right named? why does it needs an explanation of what it process (or about its arguments..). If your function name does not give an enough explanation of what it does, you should write a longer definition.

Also, some comments may be fully redundant so there is no use to get them. If you supposedly have a property: IsVisible that can be set, and can get a boolean value, what can bring your comment to make you to understand it better? 

Another point is that writing comments can take a lot of time, and as you use refactoring tools, this documentation may simply get out of context, as most refactoring tools do not propagate the documentation's comments with even very simple refactors. What is the point to get an documentation that LIE about your code?

At the end, write their comments in their understanding of the flow, or have notes about it, but largely the documentation may be not that detailed or that coherent for other reader (when do you know that your comments are reviewed by someone just to be sure that they are not only up-to-date, but to be enough conclusive to get the value of writing them!?)

There are comments really necessary? Sometimes they are. They firstly can write under which is your license which may be mandatory for some projects. Other part that I find them really useful are with associated tags: TODO, FIXME, BUG, etc. that they add value that you can follow your code flow and get real comments that are enough explanatory for someone even new in your code. 

At the end, at least for NaroCAD case (this book is about Java language but most of principles apply unchanged on C#/.NET side), splitting code in regions may create a huge difference on reading code (and works like comments but are just for separating code). C# permits automatic properties and automatic detection of the expression type (using var keyword) and using them wisely will clean up a bit your codebase. Those changes may improve on a greater margin your code clarity than commenting your code.

The bottom line of this post is just that redundancy and even worse, discrepancy of what is expected by what is actual in code can create your code longer, hard(er) to maintain and time waster. Redundancy in comments may not be an issue, if you are a lazy programmer, but sometimes you can avoid also duplicate code and useless branches by using programming by contract.

Merge window started

Today and tomorrow all finalized functionality will be merged and pushed to the devel repository. There will stay for one week for bug fixing and at the end of next week will move it to stable repository for release.

From yesterday pushed the constraint on circle radius, constraints on line, rectangle width and height constraints. Pushed also updated box tool and bug fixes at it.

TreeView was fixed

TreeView did had some changes in it's code and they were mostly to overcome some design issues regarding face splitter in general and making hard to select some shapes to access their property grid in particular. After this changes, actual code permits to show the invisible shapes with a custom color and also show them as many levels as possible. The fixed do make that filtering to work again as it was before the refactor, the nodes that are over at the level 2 of depth of tree are collapsed, and the populate tree logic was moved out from the tree widget handling.

Constraints bug fixing

Worked at updating the box tool to use the latest rectangle code that has two points and a direction, updated also the Lua code for it.

Pulled the constraints functionality code (circle fixed radius, line fixed length, rectangle fixed width and height), reviewed code and merged to devel repository code.
Fixed the extrude broken tool after merging. This functionality is ready for merge window.

Will continue with making a function that knows how to keep an edge to point constraint to have it for the merge window from Friday. Also will prepare the box tool code for merging.

TreeView Improvements

TreeView did get a big overhaul. The reason of doing it is more than philosophical, you had previously (and in actual release) to chose between features (as face-split) and functionality.
Those changes are mainly two: the shapes are shown as many levels as a shape have dependencies. Also invisible faces are shown with blue.
I think that are still bugs as there are some custom rules (like the passing over references and subshapes are jumped automatically). But I hope that tomorrow in the first part of day I will fix the remaining ones (mostly the single bugs that are remaining are linked with filtering text and that even the level is there, there is no collapsing code for level bigger than let's say 2).

Get List of All Shapes in OpenCascade

OpenCascade have an interesting design regarding separating between the scene and the visualization (is a Model-View-Controller design). In short the visualization happens in View (and less in Viewer) code, the scene is done in an OpenCascade context. Another good part is that OpenCascade separate the selection from highlighting shapes. The selected shapes are named Current shapes, the selected shapes (that you click on) are named named Selected shapes.
Sometimes it may happen that you will want to select a shape that is under another face, or a bug in OpenCascade visualization will make the selection blinking so you will be hit that you cannot make your shape later. To overcome this, I did tried to make a way to make that pressing a key (exactly Control) and clicking in a place, if there are more objects under mouse, you should get a list of that shapes and you will be able to select the expected one.

This code makes a list will all the selected shapes. As NaroCAD have a persistent way to store the TopoDS_Shapes as the source that generates them, this code will do as following: it will check under the mouse if there is a shape, it identify the node that is the selection one, it hides the shape, and go forward until it will not find nothing under mouse. At the end, it will reshow the hidden shapes. As the shapes are decorated by the NodeBuilder the revisualization is done automatically by NaroCAD framework, but if you will want to do similar code, you just have to show the into OpenCascade's context, the correspond AIS_Shape(s) that you just removed.

public static List<NodeBuilder> GetAllHighlightedShapes(Node root, OCAIS_InteractiveContext context, OCV3d_View view, int mouseX, int mouseY)
{
var shapeList = new List<NodeBuilder>();

// Try to see if anything selected in the local context
bool found = true;
while (found)
{
found = false;
context.MoveTo(mouseX, mouseY, view);
context.Select(false);
context.InitSelected();
if (context.MoreSelected())
{
var current = context.SelectedInteractive();
var shape = GeomUtils.ExtractShapeFromAis(current);
if (shape != null)
{
var node = IdentifyNode(root, shape).Node;
var builder = new NodeBuilder(node);
shapeList.Add(builder);
builder.Visibility = ObjectVisibility.Hidden;
found = true;
}
context.CloseAllContexts(false);
context.ClearSelected(false);
}
}

foreach (var removedObject in shapeList)
{
removedObject.Visibility = ObjectVisibility.ToBeDisplayed;
}

return shapeList;
}

I hope that this trick is interesting and you will enjoy the new functionality if you will have a complex shape setup. Also this code works only with MetaActions.

Line Length Constraint and Property Grid Editing

Line length constraint was added in the constraint tab.
Also was created property grid editing code for all constraints (meaning: line's length, circle's range, rectangle's width and height). Also I've fixed a bug that did not permit to select lines in MetaActions. This bug was because our selection of shapes was done in "face pick" code, and not on any mouse movement.
Based on this work, the single part that is missing are the icons or fixing unexpected bugs that may appear.

Circle Range Constraint, Rectangle Width and Rectangle Height Constraints

NaroCAD improves a bit more from constraint point of view. NaroCAD in the initial design have a function based constraint (meaning that other shape observe the current shape), but also have an interpreter based constraint (that was the main change in the constraints fixes done in the previous weeks).
The biggest problem with function based constraints was that they are a bit harder to work and their interface that they were exposed was not that helpful. One of the reasons was that these shape constraints were based on internal node structure which may mean nothing to an user. Making "high level" constraints that based on the internal representation, will create the corresponding constraint will make things easier. So as for now the range of a circle can be constrained, also the width and the height of the rectangles.
Those constraints are also available from command line invocation namely: circle_constraint, rectangle_width_constraint and rectangle_height_constraint, and after this you will have to pick the shape you want to work on and the constrained value you want to use for it.
Some work is still needed to be shown in a visual way at the OpenCascade level (to show a dimension like representation), but the rest of code will work (meaning that fixed values cannot be changed in property grid, as after you change, your value will go back to previous constrained value).
This work is submitted in my branch (lordcip) for now but will be available after some testing in the devel branch and in short time in the next version. Also I've made the nightly build to reflect the same branch. and I will sync this branch with others (mostly with devel branch) so you will may get the most "blog-enable" builds. Please take in account that those builds are highly unstable but are a good preview for fulfill your curiosity and give feedback of how those features work.

Debug View Improvements

There are a lot of things that work transparently in the back of the scene in NaroCAD and things things may pin down lot of problems much easier.
The core component that should work flawless and to expose things that developers work is the Document tree. This should store the right data in the right way. Sometimes it may happen just to not do it. The constraints work in the previous week show some flaws that some constraints override the values of other constraints. NaroCAD from old times have some code to show and debug internal structures named by developers as "Output Debug". This code was fairly old but did work nicely in most cases, and it need some love. It does expose some problems like the crashing Dimension as it store in a wrong way some data. (Don't play with dimension, the actual version does crash for this reason and please wait the future version to get those fixes).
This tree can be playable for a 3 shape test, (NaroCAD did create sometimes lot of shapes, some of them invisible) but it will not work nice from developer standpoint when are more than 5 shapes as you need scrollong. Why? Look on the photo. On the left the OutputDebug form shows the the initial rectangles that NaroCAD starts and what is it's full representation.
This code was vastly cleaned up and things are much cleaner and you can see this on the right.
What it does better? It will trim the attributes that have no extra arguments and compact the view with that. Also write the shorter name that have more meaning that full reflected name. (like: Naro.Infrastructure.Interface.IntegerInterpreter instead of Integer). Also for shapes is exposed its relevant information instead of exposing its attributes that describe it.

More Than One Central Repository Enabled

NaroCAD works with more repositories at once. This means mostly that final changes will be done in two repositories mostly: the "devel" one and the "stable" one and "stable" will reflect once at 2 of development weeks the content of "devel" after "devel" branch will reach the level of stability needed for preparing for making a release. After that the "stable" repository will get fixes for around a week and will make a release available. After this week of stabilizing work, the "stable" will be a start point for development for the next 3 weeks iteration.
Anyway, you are encouraged to take the devel branch as we as developers we will not work (that much) directly on it. We will also synchronize the devel branch only when we think that our feature is mostly complete or fully complete.
How you can get the source code on devel branch?
Install TurtoiseHg.
Pick from explorer the option of clone repository, and put as source address
http://narocad.hg.sourceforge.net:8000/hgroot/narocad/devel
for "devel" branch and
http://narocad.hg.sourceforge.net:8000/hgroot/narocad/stable
for "stable" branch.

After downloading the source you will have a working source code that will make to you to have a good starting point to understand how NaroCAD works.
There are also branches specially for development, as lordcip (mine, the most unstable), bxtrx and cristian (for our hard worker and ferocious QA and programmer). They are reflecting mostly up-to-date blog post when a feature is (said that is) implemented and you will want to get the "bleeding edge" of the NaroCAD development.

Migration from SVN to HG and what means to you

NaroCAD decided to go from SVN (Subversion) to HG (Mercurial) for some time. The first attempt was done around 3 months ago to see if is possible.

Mercurial is distributed versioning system and that means that developers work only on their branch and merge back their changes to the repositories as the "central" Sourceforge one. This will mostly mean that developers (as myself) will make their changes locally and when "the feature is ready", it will be submitted to the global repository.

Why is that important this to you? This will be great in matter of testing in general as committing in the central repository means a lot of times a lot of crashes that are not wanted. Some of them are done just in the last moment. Also will make developers to not spend too much time in balance how much will do refactors/rewrites that may be disruptive. If I will want to make a thing that may break things, it will be in my repository, on my machine, but it will not even enter as a part of nightly build.

In this way I will try to write an updated link how to build NaroCAD using HG that will be similar (but updated) from the previous build instructions from SVN.

NaroCAD 1.4.2 released

If this release should have a name, should be "Constraint". It was a big change in the internals of the constraints that are applied live, per every attribute, automatically to make life easier.

Also other features you might want to use:
- rectangle is vastly improved to work as expected and there are horizontal and vertical line.
- face split feature (that you pick "islands" from multiple face drawn intersections) ca be disabled as it may make hard to find your original shape if is hidden under another face. Can be enabled under Options/Solver/
- there are geometric helpers under line: horizontal and vertical line that are more precise and also work as constraint geometry. Those lines can be also used for mirror line operations
- constraints are tested to work in multiple combination so may work that your point that is the source for a center of a circle to be both on a specific horizontal and a specific vertical line on the same moment. Also propagation count regenerates were tried to be reduced. bxtrx did a patch to regenerate using OCC (OpenCascade) regenerate AIS Shapes to OCC Context, instead of deleting and regenerating the shape again which may be felt as faster for some.

Hope you will enjoy it and you will wait to see more progress in usability and design tooling.

Download it from here.

Constraints Build Preview

Nightly build is the recommended build to preview the build that will be made tomorrow. There is only one fix that did not get in todays' build: the preview of the points. Also this build have the Face-Splitter component disabled as it is not fully useful by constraint design (and for testing purposes at least) with constraints as the split faces hides the shapes you worked on.

Today's fixes were mostly the "most hidden" crashes that happened when you work with multiple constraints and conflicting ones will make that some data to be invalid.

So please take a look for the preview build that is in the right side (Download Nightly Build). Wish to you a happy testing.

Rectangle2p code is gone and more fixes

Constraints are working with propagation and seems to work right away as many on a point. Also I fixed a infinite recursive case when a constraint were setup for another constraint a value and the second one setups for the first one. Most probably as Monday (tomorrow) it will be the preview version or Tuesday in the morning. The last four days were really great from stability point of view.

There was also a possible crash that was fixed if you did mirror line against a horizontal line (or vertical line) as the axis extraction was done by scanning internal line structure which differs from the former default line shape (that has two points) and the horizontal/vertical lines (which have only one point). So expect tomorrow to download a preview build with constraints enabled and in the following day (Tuesday) to get a full build with the latest problems found.

Rectangle2p code was removed as Rectangle do not work as of a parallelogram (as worked previously). So wait a bit more for downloading this new release.

Turtoise is dead, long live Turtoise (preparing to move SVN to HG)

One of the part that the Solver refactor and improvements was the stability. One of the reason was that the internals of the solver were more integrated with NaroCAD modelling part.

The current way to change the design shows some problems of one repository. The solver changes make that the stability of NaroCAD to change the release day so we hope to do it Tuesday. bxtrx did rectangle to behave like rectangle2p and constraints gets more love. There is only a remaining big bug: as many constraints apply to one point, make that one or more (I see that none) to not apply to that point. I will have to investigate and reduce the cases of that bug.

Updates: most crashes are gone, and vertical and horizontal constraints should work with SVN version. So the release may be done Monday also.

Also NaroCAD is preparing to change from SVN to HG (Mercurial). The motivation change is that is more suited for opensource/free software way but more details will follow.

Bug fixing

Fixed the translate tool.
Fixed extrude bugs: fixed extrude reference disappearing shape at Escape, fixed a bug that sometimes the reference shape is not hidden.
Finalized the orthogonal rectangle drawing tool including the property grid, editing container and constraint.
Added an improvement that when the Sketcher tool is launched on a surface and the shape is rotated parallel with the screen also the drawing is blocked on that plane. Simulates a kind of 2D sketching.

Bug fixing

Fixed the duplicate nodes that appeared in tree view at spline. Enabled some of the tools that were not working: offset, line normal to plane, line parallel to plane.
Translate tool is still broken, needs fixing.