Friday, April 30, 2010
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.
- 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.
You may test it using Nightly build from the right.
Wednesday, April 28, 2010
Monday, April 26, 2010
Saturday, April 24, 2010
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.
Thursday, April 22, 2010
Those fixes did happen just after release, so you may see them in the nightly build.
- 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.
Wednesday, April 21, 2010
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.
Tuesday, April 20, 2010
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.
Monday, April 19, 2010
Will focus from now on repairing the crash bugs, fix tools, enabling back tool functionality.
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.
Sunday, April 18, 2010
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.
Saturday, April 17, 2010
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.
Friday, April 16, 2010
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.
Thursday, April 15, 2010
Wednesday, April 14, 2010
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.
Tuesday, April 13, 2010
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).
Sunday, April 11, 2010
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;
found = false;
context.MoveTo(mouseX, mouseY, view);
var current = context.SelectedInteractive();
var shape = GeomUtils.ExtractShapeFromAis(current);
if (shape != null)
var node = IdentifyNode(root, shape).Node;
var builder = new NodeBuilder(node);
builder.Visibility = ObjectVisibility.Hidden;
found = true;
foreach (var removedObject in shapeList)
removedObject.Visibility = ObjectVisibility.ToBeDisplayed;
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.
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.
Friday, April 9, 2010
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.
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.
Thursday, April 8, 2010
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?
Pick from explorer the option of clone repository, and put as source address
for "devel" branch and
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.
Wednesday, April 7, 2010
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.
Tuesday, April 6, 2010
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.
Monday, April 5, 2010
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.
Sunday, April 4, 2010
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.
Saturday, April 3, 2010
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.
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.