This is another technical post, but will try to be as simple as possible.
NaroCAD did work hard to find a proper balance between extensibility and enforcing. For example you can add anything to any node as long as the code is enforced by generics when we talk about how data is stored in a document. When you work with geometric functions, you can add them with fairly short code but in the same time you can define fairly complex shapes (like Cut one). On the other hand, if you do insert by code wrong data, an exception is thrown and the developer will be able to track the problem fairly easy.
This concept of enforcing is named: programming by contract if is used at the runtime level, or compiler-based checking. The compiler-based checking is much better as you cannot do mistakes by design. But compiler-based checking will make some areas of code impossible to be written.
One of those areas is the Actions framework. One of the key ideas of it is that when you click on an action from toolbar, the action can ask for anything, and the framework will provide. But on the other hand, as the action can get anything (to be as extensible), you will never know what you will get. As a proper direction of developing NaroCAD will get that some areas can be interchanged, some hidden problems may appear, that are hard to debug, because someone that does not understand NaroCAD completely, will not all cases right.
Here comes NaroAssert, which is a "programming by contract" class, that is done to improve bug prevention issues. You will write your checks, similar with NUnit conditions, and you will get an exception of the assertion will not fit your expectations.
I've also applied those assertions on the NaroCAD's Actions framework. Those checks were like: if an action asks for an input, should not be able to ask for it twice. This will enforce, by design that a people will know which resources will ask and why. Another area that is improved, is that is enforced to do hijacking of actions or inputs. At the code-level if someone will write its activation code for switching an action, as happen in the CommandLine view, this action should close nicely this action (found and fixed bugs in this area too).
What about users? Should they "pay" for those developer like checks, that even they will happen, they may not be that affected: for example, if by mistake the previous action is not cleaned up properly, if the user will press escape, NaroCAD will get back to a stage that things again work, Another case is that if a cautious developer will check anything that is right, the application may run slower, as those checks will get some CPU time. So, if an exception is thrown, the user will get a crashed NaroCAD. So for this reason, NaroAssert will work only on developers' builds.
Tuesday, August 31, 2010
Monday, August 30, 2010
Editing and Selection Code Separation
As NaroCAD internal changes are ongoing, they were targeting to minimize the relations between components. This simplify debugging as most components will be self-containing.
Selection code is smarter thanks to bxtrx changes but also is separated as an external component. This will mean mostly that selection information will be both better (the old code that you were able to detect the face under the "Solid selection mode" was buggy, and will work right now), and more bug-proof, as all actions (for example Fillet2D, which previously breaks the selection as this action does it by itself) will use an unified code. So less side effects and easier bug tracking and fixing in this area, if problems will arise.
An area that NaroCAD also will improve is the editing code that was "fragile". This was both because of selection code, a fairly complex case when more tools were mixed, like: floating toolbar, the inactive "none" action and the actual editing code.
As of today, the editing code will use the Selection component described above, and also will be separated from inactive action. So when you click on a shape to edit it, the "inactive mode" will become "editing mode" in code terms, so hopefully this harder to debug code will have less problems in future and will be also easier to maintain.
Those changes as a whole will slightly improve the quality of NaroCAD codebase, mostly in the more complex cases in our code-base. Also will make easier to export some actions/inputs to plugins as they have less dependencies and are easier to register.
Selection code is smarter thanks to bxtrx changes but also is separated as an external component. This will mean mostly that selection information will be both better (the old code that you were able to detect the face under the "Solid selection mode" was buggy, and will work right now), and more bug-proof, as all actions (for example Fillet2D, which previously breaks the selection as this action does it by itself) will use an unified code. So less side effects and easier bug tracking and fixing in this area, if problems will arise.
An area that NaroCAD also will improve is the editing code that was "fragile". This was both because of selection code, a fairly complex case when more tools were mixed, like: floating toolbar, the inactive "none" action and the actual editing code.
As of today, the editing code will use the Selection component described above, and also will be separated from inactive action. So when you click on a shape to edit it, the "inactive mode" will become "editing mode" in code terms, so hopefully this harder to debug code will have less problems in future and will be also easier to maintain.
Those changes as a whole will slightly improve the quality of NaroCAD codebase, mostly in the more complex cases in our code-base. Also will make easier to export some actions/inputs to plugins as they have less dependencies and are easier to register.
Friday, August 27, 2010
NaroCAD Updates
Thank you for people using NaroCAD and in case of crashes they report the problems on NaroCAD bug tracker automatically. We got it, NaroCAD have stability problems! And we try to address them.
NaroCAD did ongoing work to clean up the code in the most twisted areas and you will likely see a more stable NaroCAD and a much easier to have fixed its problems. Areas that will be improved will be the selection code (bxtrx is working on it) and better coverage by unit testing on basic functionality. Those changes will pay off in subsequent releases that will likely be more stable, or if a crash will occur to be covered by tests that are easier to be .
Another area that we want to improve is communication. Do you think that NaroCAD have to improve in an area, or you simply tried to build NaroCAD and fails on your machine? Do you want to make your icons, or to improve the help and you don't know how? Did you tried to make a shape and a bug, not necessarily a crash stopped you to finish your work? We want know kindly your opinion about it. You may write to email to mihaizzz @t yahoo_dot com or ciprian.mustiata @t gmail_dot com to say your concerns. Also, I will try, and depends on your time to be connected on IRC to irc.freenode.net on channel #narocad and to respond on more instant questions. This will hopefully make us to get better feedback and to you the application you will expect.
NaroCAD did ongoing work to clean up the code in the most twisted areas and you will likely see a more stable NaroCAD and a much easier to have fixed its problems. Areas that will be improved will be the selection code (bxtrx is working on it) and better coverage by unit testing on basic functionality. Those changes will pay off in subsequent releases that will likely be more stable, or if a crash will occur to be covered by tests that are easier to be .
Another area that we want to improve is communication. Do you think that NaroCAD have to improve in an area, or you simply tried to build NaroCAD and fails on your machine? Do you want to make your icons, or to improve the help and you don't know how? Did you tried to make a shape and a bug, not necessarily a crash stopped you to finish your work? We want know kindly your opinion about it. You may write to email to mihaizzz @t yahoo_dot com or ciprian.mustiata @t gmail_dot com to say your concerns. Also, I will try, and depends on your time to be connected on IRC to irc.freenode.net on channel #narocad and to respond on more instant questions. This will hopefully make us to get better feedback and to you the application you will expect.
Tuesday, August 24, 2010
Inputs and Actions Framework Updates
This blog is fairly technical but it presents an improvement that may be interesting for some.
In our quest to improve quality of NaroCAD default builds we want to be sure that every time we fix a part, to not break another. For achieving this we need to know that a component is fixed and at which level is achieved this.
NaroCAD have a good separation component that is named: Inputs and Modifiers (or Actions). As we add new components to NaroCAD we want to isolate them, but on the other hand we want to make easier the component finding. For this reason we have define at the action level which dependencies we need. After this, these dependencies will require if needed other dependencies.
One of the changes is that all those cascading dependencies were automatically added to the calling action's dependencies. Right now the calling action will be in contact just with the inputs it asks. Why this is important? Because we can make an action unit test to have less dependencies to setup.
Another change is that the creation of a "fake" dependency is much shorter. This will make easier to make a setup of an action concise. The same of a fake action if there is a need to test a real action input.
The inputs previously were of two kind: Inputs and Pipes. A pipe being an input that depends of another input. For example the Solver component get the mouse 3D coordinate and decide if this point is close(r) with another points or not. But in previous design was not possible to connect to more inputs (even they were needed). This make that at least Solver component to have hard-coded dependencies, that made harder to track some problems (like view flickering) as dependencies were not explicit, but hard-coded. Many of those cases, like meta-actions, were harder to define as they depend on many components of NaroCAD (view, command line, treeview, solver). The big count of dependencies was two fold: they were hard(er) to create unit-tests, but also they are hard to test: our meta-action testing covers just "NaroCAD does not crash" and "it really creates a shape".
The next step is to make possible to create a visual unit testing (that a tester can follow and see if something abnormal will appear) based on NaroCAD typical flows. Also it may make possible to test some components (command line parser for example, that convert your string inserted in command line as a 3D point coordinate, or switch the action) without having to setup a meta-action (that as was said previously, is hard to be made).
After some separation, this code will also remove most probably another limitation of NaroCAD: meta-actions and actions are different entities, and make that for example meta-actions to be accessible from command line, but actual commands to be inaccessible.
So, stay tuned!
In our quest to improve quality of NaroCAD default builds we want to be sure that every time we fix a part, to not break another. For achieving this we need to know that a component is fixed and at which level is achieved this.
NaroCAD have a good separation component that is named: Inputs and Modifiers (or Actions). As we add new components to NaroCAD we want to isolate them, but on the other hand we want to make easier the component finding. For this reason we have define at the action level which dependencies we need. After this, these dependencies will require if needed other dependencies.
One of the changes is that all those cascading dependencies were automatically added to the calling action's dependencies. Right now the calling action will be in contact just with the inputs it asks. Why this is important? Because we can make an action unit test to have less dependencies to setup.
Another change is that the creation of a "fake" dependency is much shorter. This will make easier to make a setup of an action concise. The same of a fake action if there is a need to test a real action input.
The inputs previously were of two kind: Inputs and Pipes. A pipe being an input that depends of another input. For example the Solver component get the mouse 3D coordinate and decide if this point is close(r) with another points or not. But in previous design was not possible to connect to more inputs (even they were needed). This make that at least Solver component to have hard-coded dependencies, that made harder to track some problems (like view flickering) as dependencies were not explicit, but hard-coded. Many of those cases, like meta-actions, were harder to define as they depend on many components of NaroCAD (view, command line, treeview, solver). The big count of dependencies was two fold: they were hard(er) to create unit-tests, but also they are hard to test: our meta-action testing covers just "NaroCAD does not crash" and "it really creates a shape".
The next step is to make possible to create a visual unit testing (that a tester can follow and see if something abnormal will appear) based on NaroCAD typical flows. Also it may make possible to test some components (command line parser for example, that convert your string inserted in command line as a 3D point coordinate, or switch the action) without having to setup a meta-action (that as was said previously, is hard to be made).
After some separation, this code will also remove most probably another limitation of NaroCAD: meta-actions and actions are different entities, and make that for example meta-actions to be accessible from command line, but actual commands to be inaccessible.
So, stay tuned!
Saturday, August 21, 2010
Visual Unit Testing Work
NaroCAD test suite cover basic functionality, that try to guarantee a crash free experience in most of simple cases (creating of basic tools, loading a file, save it, do an Undo/Redo, and so on). Still some issues may be there, but the future builds will be less crash proof, to say so.
Anyway, being more crash resistant (thank you for all users that did sent bug reports when NaroCAD crashes, they were great startup cases to us to see what was happening), will not necessarily mean that NaroCAD will bring a smooth experience.
So I will dedicate time to make a visual unit test that will try to reduce NaroCAD to "bare metal". Also, I will try to reduce the interactions that can get out of hand in NaroCAD code flow that make two problems to seem to be interrelated: is hard to make a unit-test in first hand, also is hard to get right all components relations to be workable.
Half of reason is that some parts of code (mostly meta-actions) they do connect to everything NaroCAD provides, and they interact all with all. This makes fairly hard to fix some bugs as some components fixes tend to break other components.
Another part of the problem is that some parts are interrelated by design, like a mouse coordinate have to get aligned with shapes around, but from unit test standpoint, it is hard to provide a big component as is the solver (which is a fairly big component) just to test if two click will create a line or not. So I will investigate and I will try to make the relations between components explicit and minimalistic and I will try a way to make creation of a fake (empty) solver component short code-wise.
At the end I want to make possible to make a script to be run in unit test, that will say: click, mouse down, coordinate that, component mouse-input, and also this test to run in a visual way, so the person which test this component, will be able to see if the line will be created. The steps should have a configurable speed (like 500 ms), but for certain to test a long test case, will be less annoying than to do it manually and to see that you did select a wrong component, instead the XOY rectangle, you clicked YOZ one, so you will have to redo the test. If you will have more than 5 steps, it will be really annoying to repeat a step that should work from scratch.
Also, but I will not guarantee this, I will try to make a "recording remote" from NaroCAD in the DEBUG (builds for developers) that can build those unit recording sessions automatically. This part may require changes at NaroCAD level that themselves yet may break the thing is wanted to be achieved: stability.
Anyway, being more crash resistant (thank you for all users that did sent bug reports when NaroCAD crashes, they were great startup cases to us to see what was happening), will not necessarily mean that NaroCAD will bring a smooth experience.
So I will dedicate time to make a visual unit test that will try to reduce NaroCAD to "bare metal". Also, I will try to reduce the interactions that can get out of hand in NaroCAD code flow that make two problems to seem to be interrelated: is hard to make a unit-test in first hand, also is hard to get right all components relations to be workable.
Half of reason is that some parts of code (mostly meta-actions) they do connect to everything NaroCAD provides, and they interact all with all. This makes fairly hard to fix some bugs as some components fixes tend to break other components.
Another part of the problem is that some parts are interrelated by design, like a mouse coordinate have to get aligned with shapes around, but from unit test standpoint, it is hard to provide a big component as is the solver (which is a fairly big component) just to test if two click will create a line or not. So I will investigate and I will try to make the relations between components explicit and minimalistic and I will try a way to make creation of a fake (empty) solver component short code-wise.
At the end I want to make possible to make a script to be run in unit test, that will say: click, mouse down, coordinate that, component mouse-input, and also this test to run in a visual way, so the person which test this component, will be able to see if the line will be created. The steps should have a configurable speed (like 500 ms), but for certain to test a long test case, will be less annoying than to do it manually and to see that you did select a wrong component, instead the XOY rectangle, you clicked YOZ one, so you will have to redo the test. If you will have more than 5 steps, it will be really annoying to repeat a step that should work from scratch.
Also, but I will not guarantee this, I will try to make a "recording remote" from NaroCAD in the DEBUG (builds for developers) that can build those unit recording sessions automatically. This part may require changes at NaroCAD level that themselves yet may break the thing is wanted to be achieved: stability.
Thursday, August 19, 2010
Bug Fixing and A Small Unit Test
We do want to not give to you a NaroCAD that crashes at least and also we want to make the usage experience (more) pleasant. This iteration did improve the testing but also another areas. As of today I've did fixed some small annoyances mostly on the area of selection, sometimes Undo works just if you clicked on the second time (in Boolean operations tools and Spline shapes). Also I found that a small change in the file format did broke some things (mostly New File operation) and I've created an unit test that will try at least to check if the file format changes that are not handled, will make at least NaroCAD to not crash.
A nice-to-have fix of an annoyance is that if you cannot select nicely your shape in boolean operations, or on pipe tool, you can select them from tree.
A nice-to-have fix of an annoyance is that if you cannot select nicely your shape in boolean operations, or on pipe tool, you can select them from tree.
Shape Analysis helpers
Rebuilt wrappers and added the shape analysis package. Implemented some shape dump
and topology investigation helpers methods in Naro. Used the helpers to investigate why extrude edge drawing displays some extra lines on the extrude faces.
It seems that the shapes that Naro creates are valid.
A rectangle shape sample dump analysis:
DEBUG2010-08-19 01:02:33 - --- Shape Info ---
DEBUG2010-08-19 01:02:33 - Extracted 8 vertexes
DEBUG2010-08-19 01:02:33 - vertex: 0,0,0
DEBUG2010-08-19 01:02:33 - vertex: 0,100,0
DEBUG2010-08-19 01:02:33 - vertex: 0,100,0
DEBUG2010-08-19 01:02:33 - vertex: 100,100,0
DEBUG2010-08-19 01:02:33 - vertex: 100,100,0
DEBUG2010-08-19 01:02:33 - vertex: 100,0,0
DEBUG2010-08-19 01:02:33 - vertex: 100,0,0
DEBUG2010-08-19 01:02:33 - vertex: 0,0,0
DEBUG2010-08-19 01:02:33 - Extracted 4 edges
DEBUG2010-08-19 01:02:33 - Extracted 1 wires
DEBUG2010-08-19 01:02:33 - Extracted 1 faces
DEBUG2010-08-19 01:02:33 - -------------------
DEBUG2010-08-19 01:02:33 - --- Shape Analysis results ---
DEBUG2010-08-19 01:02:33 - 4 EDGE (Oriented)
DEBUG2010-08-19 01:02:33 - 4 EDGE (Shared)
DEBUG2010-08-19 01:02:33 - 1 FACE
DEBUG2010-08-19 01:02:33 - 1 FACE (Free)
DEBUG2010-08-19 01:02:33 - 8 VERTEX (Oriented)
DEBUG2010-08-19 01:02:33 - 4 VERTEX (Shared)
DEBUG2010-08-19 01:02:33 - 1 WIRE
DEBUG2010-08-19 01:02:33 - -------------------
DEBUG2010-08-19 01:02:33 - --- NumShape Info ---
DEBUG2010-08-19 01:02:33 - 4 VERTEX
DEBUG2010-08-19 01:02:33 - 4 EDGE
DEBUG2010-08-19 01:02:33 - 1 WIRE
DEBUG2010-08-19 01:02:33 - 1 FACE
DEBUG2010-08-19 01:02:33 - 0 SHELL
DEBUG2010-08-19 01:02:33 - 0 SOLID
DEBUG2010-08-19 01:02:33 - 0 COMPSOLID
DEBUG2010-08-19 01:02:33 - 0 COMPOUND
DEBUG2010-08-19 01:02:33 - -------------------
DEBUG2010-08-19 01:02:33 - --- Check shape ---
DEBUG2010-08-19 01:02:33 - Valid Shape
DEBUG2010-08-19 01:02:33 - -------------------
and topology investigation helpers methods in Naro. Used the helpers to investigate why extrude edge drawing displays some extra lines on the extrude faces.
It seems that the shapes that Naro creates are valid.
A rectangle shape sample dump analysis:
DEBUG2010-08-19 01:02:33 - --- Shape Info ---
DEBUG2010-08-19 01:02:33 - Extracted 8 vertexes
DEBUG2010-08-19 01:02:33 - vertex: 0,0,0
DEBUG2010-08-19 01:02:33 - vertex: 0,100,0
DEBUG2010-08-19 01:02:33 - vertex: 0,100,0
DEBUG2010-08-19 01:02:33 - vertex: 100,100,0
DEBUG2010-08-19 01:02:33 - vertex: 100,100,0
DEBUG2010-08-19 01:02:33 - vertex: 100,0,0
DEBUG2010-08-19 01:02:33 - vertex: 100,0,0
DEBUG2010-08-19 01:02:33 - vertex: 0,0,0
DEBUG2010-08-19 01:02:33 - Extracted 4 edges
DEBUG2010-08-19 01:02:33 - Extracted 1 wires
DEBUG2010-08-19 01:02:33 - Extracted 1 faces
DEBUG2010-08-19 01:02:33 - -------------------
DEBUG2010-08-19 01:02:33 - --- Shape Analysis results ---
DEBUG2010-08-19 01:02:33 - 4 EDGE (Oriented)
DEBUG2010-08-19 01:02:33 - 4 EDGE (Shared)
DEBUG2010-08-19 01:02:33 - 1 FACE
DEBUG2010-08-19 01:02:33 - 1 FACE (Free)
DEBUG2010-08-19 01:02:33 - 8 VERTEX (Oriented)
DEBUG2010-08-19 01:02:33 - 4 VERTEX (Shared)
DEBUG2010-08-19 01:02:33 - 1 WIRE
DEBUG2010-08-19 01:02:33 - -------------------
DEBUG2010-08-19 01:02:33 - --- NumShape Info ---
DEBUG2010-08-19 01:02:33 - 4 VERTEX
DEBUG2010-08-19 01:02:33 - 4 EDGE
DEBUG2010-08-19 01:02:33 - 1 WIRE
DEBUG2010-08-19 01:02:33 - 1 FACE
DEBUG2010-08-19 01:02:33 - 0 SHELL
DEBUG2010-08-19 01:02:33 - 0 SOLID
DEBUG2010-08-19 01:02:33 - 0 COMPSOLID
DEBUG2010-08-19 01:02:33 - 0 COMPOUND
DEBUG2010-08-19 01:02:33 - -------------------
DEBUG2010-08-19 01:02:33 - --- Check shape ---
DEBUG2010-08-19 01:02:33 - Valid Shape
DEBUG2010-08-19 01:02:33 - -------------------
Wednesday, August 18, 2010
Shape drawing aspect
In order to improve the shape drawing visibility for the user studied the Aspect and Shading of drawings. Succeeded to change shape edge color to better differentiate the shapes in scene.
Edge drawing enabled shows some other problems, it seems that some generated shapes (like extrudes) have interior edges. I'll continue investigate the shape topology that we currently use. Maybe fixing this problem will solve other issues that we have on some cases when applying complex algos on complex shapes.
Edge drawing enabled shows some other problems, it seems that some generated shapes (like extrudes) have interior edges. I'll continue investigate the shape topology that we currently use. Maybe fixing this problem will solve other issues that we have on some cases when applying complex algos on complex shapes.
Tuesday, August 17, 2010
Working plane visual hint
From this iteration we implemented as feature a visual hint drawn as a circle shape, hint that shows the plane where the user draws.
Worked at improving the hint drawing and also added at DrawingInterpreter a property that allows the coder to disable selection on a drawn shape so that the hint is not detected as being a shape from scene. The code is finalized but there are some issues with OpenCascade selection disabling, it seems that it doesn't work well.
Worked at improving the hint drawing and also added at DrawingInterpreter a property that allows the coder to disable selection on a drawn shape so that the hint is not detected as being a shape from scene. The code is finalized but there are some issues with OpenCascade selection disabling, it seems that it doesn't work well.
Significant memory usage improvement
Allocated 1 day to add finalizer code at wrappers that Naro uses (around 20 new packages to the 14 packages previously improved). This modification improves a lot the NaroCAD memory usage: previously for 20-30 shapes in scene Naro could use up to 1G of memory, now it stays at around 200 Megabytes and that's great.
The modified wrappers were uploaded on SVN.
The modified wrappers were uploaded on SVN.
Sunday, August 15, 2010
Unit tests fixed
As I've said previously the site was attacked probably because I had a vulnerability in WordPress as I used a new version. Anyway I've removed from my site WordPress for now, and I've wanted to present a milestone that was done from yesterday, but I did not want to say because of the warning that is a dangerous site from Google: http://cipdevel.com/testreports/
All basic unit tests are working and hopefully will be added more and they will cover more of NaroCAD functionality.
All basic unit tests are working and hopefully will be added more and they will cover more of NaroCAD functionality.
Saturday, August 14, 2010
Vandalism On My Site
My site was vandalized (cipdevel.com). I've just deleted the WordPress installation but sadly for some time if you will download the nightly build you will get a warning from Firefox that is an attack site.
Sorry for inconvenience!
Sorry for inconvenience!
Friday, August 13, 2010
Automatic Face Construction Logic Fixed
Most unit tests were fixed and a new unit test was fixed. This unit test did try to show a bug that the automatic face detection was not working right. Most of other unit tests were fixed if were figured out the side effects. This change the pattern of executing unit test and previously the code was like: InitialSetup, Test1, ResetConfiguration, Test2, ResetConfiguration, Test3, etc. and the code right now is: InitialSetup, Test1, InitialSetup, Test2. This makes possible that the bugs of ResetConfiguraion to not happen. In this way also excluding two tests that try to extract invalid coordinates as those unit tests get no valid coordinates in the unit tests way, will give an exception on extracting plane under mouse (as the coordinate are invalid, the selection code is also invalid). There is a fake FacePicker code just for tests. So tests are mostly in place and working and they will also guarantee that as much as the battery of tests will grow that most of common failures that NaroCAD sometimes encounter because of a refactor or a new feature is in place, it will not affect basic functionality that is covered by all those unit tests.
Thursday, August 12, 2010
Command Line support in Polyline Drawing
Polyline was not supporting command line. Right now it does.
An improved logic was setup for parallel line logic match. In short, previously parallel lines computed all points combinations and try to see if they were parallel . Also this logic was bogus because some parallel lines were picked with wrong combinations a corner of one edge and a middle point of another edge. Right now just the corner points are picked in consideration and also they have to be consecutive on the edge count.
An improved logic was setup for parallel line logic match. In short, previously parallel lines computed all points combinations and try to see if they were parallel . Also this logic was bogus because some parallel lines were picked with wrong combinations a corner of one edge and a middle point of another edge. Right now just the corner points are picked in consideration and also they have to be consecutive on the edge count.
Wednesday, August 11, 2010
Automatic testing run and results; Test plans
I've managed to make a script which is running more test assemblies and generate a .xml file as a result; From that xml file, the dates are extracted and generated an html file which is also uploaded to our developer, Lordcip, website.
Also I've improved a lot the test plans, and in the future we hope to have more knowledge about the bugs that are present in NaroCAD and fix them more promptly.
Also I've improved a lot the test plans, and in the future we hope to have more knowledge about the bugs that are present in NaroCAD and fix them more promptly.
Monday, August 9, 2010
Fixes To Installer New Logic and Selection Code
The nightly builds did change the logic of updater step to be less annoying and less prone to crashes. Anyway it had some misses like that I've worked to be fixed:
- to ask you to save your before apply an update
- to apply the update at startup
- the nightly build will not require for nightly build creator to complete the installer form. But is still possible to complete it for stable builds.
- bad formatted links that did not end with .exe that are the installer will not break the updater routine
- assure that floating bar pick is got right
- the face picker feedback was done to be wireframe. This made a change that make that the files are incompatible with old naroxml files as it is added more information to shapes that is incompatible with old code
- to ask you to save your before apply an update
- to apply the update at startup
- the nightly build will not require for nightly build creator to complete the installer form. But is still possible to complete it for stable builds.
- bad formatted links that did not end with .exe that are the installer will not break the updater routine
- assure that floating bar pick is got right
- the face picker feedback was done to be wireframe. This made a change that make that the files are incompatible with old naroxml files as it is added more information to shapes that is incompatible with old code
Sunday, August 8, 2010
Plane Picker Feedback
For (metaaction) shapes that you pick a plane (like rectangle, circle or cone), before you will do the first click, you will have a preview circle that will show clearly the plane you draw.
Dragging points in editing mode will update the coordinates and also will preview it nicely.
NodeBuilder class which is responsible for a shorter code (and also guarantees correct creation of shapes) have a shorthand to use it's dependencies, so the old code was:
var builder = new NodeBuilder(...);
builder.Dependency[0].Point3D = v1;
and the new code is:
var builder = new NodeBuilder(...);
builder[0].Point3D = v1;
which also makes sense in builder's context and it's code usage.
Dragging points in editing mode will update the coordinates and also will preview it nicely.
NodeBuilder class which is responsible for a shorter code (and also guarantees correct creation of shapes) have a shorthand to use it's dependencies, so the old code was:
var builder = new NodeBuilder(...);
builder.Dependency[0].Point3D = v1;
and the new code is:
var builder = new NodeBuilder(...);
builder[0].Point3D = v1;
which also makes sense in builder's context and it's code usage.
Friday, August 6, 2010
Multiple Level Selection Information, Updater and Solver Flickering
Code was cleaned to handle selections at multiple levels (like when you click on a shape, the internals of NaroCAD will know that you selected both an extrude and it's face with it's index 3). Previously this code was handled manually, but right now there is logic that a tool can get all information about selection. This also solves an issue that in the last nightly build(s) that clicking on a line will make the floating toolbar to not appear (because it expected at least a face-based shape, if not a volume based one).
This code is also aware of the current selection mode the user picks.
The updater will be less intrusive by downloading in background the next version and will apply next time on startup the downloaded install package. When the background downloaded is finished, it will show to you just a notification icon.
Of course if you don't updating at all, you still have the option to not download the new versions if you will go to Options page.
A lot of flickering when updating solver points/lines was removed. This may solve some slow performance issues. Also the solver previously did display just one point/line or whatever appear as first shape to be drawn. Right now all shapes are drawn (like if you have a Point match and a Edge Continuation match), but even all shapes are displayed, the rules apply in the old priority order (like: Point match is picked before Edge Continuation match).
This code is also aware of the current selection mode the user picks.
The updater will be less intrusive by downloading in background the next version and will apply next time on startup the downloaded install package. When the background downloaded is finished, it will show to you just a notification icon.
Of course if you don't updating at all, you still have the option to not download the new versions if you will go to Options page.
A lot of flickering when updating solver points/lines was removed. This may solve some slow performance issues. Also the solver previously did display just one point/line or whatever appear as first shape to be drawn. Right now all shapes are drawn (like if you have a Point match and a Edge Continuation match), but even all shapes are displayed, the rules apply in the old priority order (like: Point match is picked before Edge Continuation match).
Draft Angle Tool started
Started working at an angle draft tool. This tool will allow the user to modify face and vertex positions by dragging them with the mouse. For the moment implemented the algorithm that detects if the user drags a vertex or an edge and then calculates for each face the new angle where they should be relative to the previous position and where the material should be removed or added.
Tomorrow will work at finalizing this tool to see how it works on complex cases by putting this function to work.
This code will be used in future to modify solids from scene by simply dragging their corners or edges.
Tomorrow will work at finalizing this tool to see how it works on complex cases by putting this function to work.
This code will be used in future to modify solids from scene by simply dragging their corners or edges.
Thursday, August 5, 2010
Latest improvements added to NaroCAD
We did a lot of improvements to NaroCAD after we released 1.5.0. Once with design performance improvements you will see improvements on UI:
- the property grid styles was changed a little;
- changed the appearance order of the splash, narocad and tips window;
- also added custom cursors for all the 2D shapes;
And for our contributors or just the ones who download NaroCAD sources we fixed the project building errors(now it works on the first build), and we fixed most of the NUnit tests.
This improvements will be available on the Nightly Build;
- the property grid styles was changed a little;
- changed the appearance order of the splash, narocad and tips window;
- also added custom cursors for all the 2D shapes;
And for our contributors or just the ones who download NaroCAD sources we fixed the project building errors(now it works on the first build), and we fixed most of the NUnit tests.
This improvements will be available on the Nightly Build;
Sunday, August 1, 2010
Improving Design Performance (part II)
After doing first optimizations, I've looked to code inefficiencies (like some shapes are built twice: once in preview mode and another time as final mode, but they rebuild the very same shape). in the code flow in events passing to get the "last 10%" from speed improvements. With those changes, the code works with an order of magnitude faster, if you will work with a medium/large shape number. The single two slow things are the OpenCascade code (which may not be that slow, but it have it's contribution) and the autosave option if is enabled.
Some other issues will be fixed and if regression will be found, they will be also be fixed. But at large, you will like to work with NaroCAD with many shapes as it will feel instant, even much faster than older Windows Forms versions.
Some other issues will be fixed and if regression will be found, they will be also be fixed. But at large, you will like to work with NaroCAD with many shapes as it will feel instant, even much faster than older Windows Forms versions.
Subscribe to:
Posts (Atom)
