3 points rectangle tool

Made a 3 points rectangle tool. This tools offers more powerful rectangle drawing possibilities enabling user to specify any 3 points in space while drawing it.

Performance Issues Solved

If you did make big scenes and you felt that NaroCAD went slow, or worse, some notifications did not happen after save/load cycle, fixes were landed in this area. Another area that things were slow, are in area that some duplicate solver points were generated slow. This make cases with a lot of points generated in scenes, when solver step will happen (mostly in every finishing of building a shape) will be much shorter.
So wait for the new version to be able to have a more responsive NaroCAD.

Changes In The Last Days

As our contributor CyberDev was diving in our source to write his plugin, he did found with his sharp eyes some code issues that were fixed in unit testing area. Also he did basic unit testing to plugins (and not only).
Layout is possible to be restored and to do so, you will have under Ribbon main menu (on the Ribbon "bubble") the option to Import restore default layout. This is also good to you if you break your layout. Anyway, you can override the DefaultNaroLayout.xml, so you can define your custom layout. This custom layout is saved when you close NaroCAD as: NaroLayout.xml. In future may be probably a management of layouts (but as far as I'm concerned, I would make a plugin frontend to not need to edit auto_plugin.naro, than to do a layout manager, anyway, contributions are welcome).
As transformations were fixed, one constraint (Edge on Edge) was disabled for some time and it is right now commited back. As for now it has some bugs (but they were were never found as transformations hide their bugs). Anyway, Most probably this tool will be fixed in all cases before the next released version, .
Staying on transformations, we found that Rectangle was working on scale/translate but had problems when a rotation is implied (the reason is that our rectangle keeps two points to define it, making easier to be drawn, for NaroCAD veterans, the rectangle sketch shape worked previously as a parallelogram, not as a rectangle, so there is a rectangle tool right now (if it will be fixed will also enter in the next release) that asks two points but store correctly three points internally.

WPF Docking Layout saves again

From Windows Forms times, NaroCAD was used to save it's layout, but moving to WPF made us to depend on components that become source incompatible (I say about AvalonDock from SharpDevelop project) as it compiles with .Net 4.0 (and NaroCAD uses .Net 3.5 SP1). But as it does not use many C# 4.0 features in this codebase (no dynamic and just here and there some default parameters), was easy to be "ported" to C# 3.0/.Net 3.5
When we used the version that compiles still with C# 3.0, we had no layout and crashes here and there. As for now they seem to be mostly gone. Also as the AvalonDock is (L)GPL!? we put the source-tree and changes under Lib folder in our source-tree, but is good if you need a good WPF docking library, and which also provides layouting save/restore, you may take this up-to-date version from our repository.

Layers Big Bugs Fixed

Layers were implemented for some time, but it appear that they have some dormant issues: sometimes the layers do not update properly, the solver does ignore the layer visibility information, deleting a layer will not delete all shapes from that layer, and so on.
Boo scripting was crashing because it does get a reference to the application based context, not document context. Fixing Boo problems I fix also future problems that will appear when moving to multiple documents as it gets a pointer to current running document.

Singleton Hidden and Some Implications

Some factories were exposed to user as singleton instances. This had two fold implications: first of them is: you did not know without diving in NaroCAD codebase what you can do and what you can't. Also from plugin writers, it was needed to keep a strict namespace to them (root one) to make easier at level of codebase to not interfer with all kind of factories that are used (here was about Options intems and FunctionFactory, where you register your custom functions.
Also they were singletons, which at one level it is an antipattern. Even they are sigletons, they are likely better to be exposed to this interface, as you can query a plugin. This also solves the possibility when NaroCAD APIs will change and you will make assumptions about code without being so.
The last implication is that for now there is just one class to you to register your plugins. From there you will get an ActionsGraph instance and you're good to go. Want to extend the Options's dialog with one OptionsItem? Get from actionsGraph your OptionsSetupInput and take the factory instance that is contained. The same for functions.
This will reduce once more coupling and problems around code. Another area that was shown, it was just that code was fragile on File->New that was not verifying that the file loaded is consistent, so breakage of it, will make future (1.5.4) version to crash. The unit test was done to verify consistency, but also the attribute saving/loading was also "fixed" (will throw exceptions so programmer will know if you will save invalid data that you have to do something!). So, if you will try the TwoPointLine plugin you will likely see some slight changes, but this refactor will mean a more stable NaroCAD and for developper view a more "complaining" unit test suite.
Another small change is that plugins will just need to add an attribute (NaroRegister) and you're ready to go, with less conventions and easier to organize your code.
So, as a conclusion, plugins will be easier to write and less problematic.
Update: one crash that was fixed regarding plugins was to register your plugin, write something to a file that depends on plugin and second time, load the file but don't load the plugin. It ws hard to fix because when a file is loaded it simply fill in memory objects and broke the internal model. By throwing an exception and "try-catching it", will let the data tree broken. So I fixed the code in two ways: try to not crash areas like TreeView using wrong data, and when loading wrong data file, will catch the exception and revert to a previous state (before loading the file).

NaroCAD 1.5.3 Is Released

New version of NaroCAD is out!
But we cannot get forward without doing improvements and fixes. So gizmos did improve greately and work as expected: Rotate Gizmo works as easy as an iPod, similarly the scale gizmo is here as your friend. To pick the gizmo you want to operate, just go to the toolbar and the corresponding gizmo will do the expected operation to you. Transformations (mostly scale and rotate) will work as expected, and will use a .Net equivalent instead using OpenCascade one.

This code is easier to debug, and this also fixes bugs in this area (of combined transformations).
This release were done like a heart transplant: SCSF was removed meaning less dependencies and easier to handle codebase. Also in future you may expect that NaroCAD will work with multiple documents and fixes will be all around. Profiling was done to make sure that excluding the time of loading the referenced assemblies, you will not wait too long time doing your operations. The single speed limiter is mostly the OpenCascade code we depend on, but we have to make our code to run correctly, so we cannot improve that much. We will constantly profile NaroCAD to make sure that will not run too slow. Just to start, NaroCAD needs 75M of RAM, so you may run it with a low spec machine (XP SP3 with 256M or 512 M of RAM), so if you have a netbook, you may give it a try.

The code is cleaner also, as we use static checking and we track code-violations and not only. One contributor (Cyberdev) wants also to make sure that unit testing will cover the plugin area (and not only), so quality may improve even more in this area. The TwoPointsLinePlugin project is much more complete and some changes like possibility that a custom function defined from a plugin to be accessed from other places is possible from Boo scripting.

Our contributor Sami did show some hidden power of NaroCAD

So why not give it a try? More info and it from here...

Finalized Scale Gizmo

Finalized the Scale Gizmo. Now it works properly.

Started bug fixing editing handles.
At rectangle, after rotation transformations applied, the editing handles are not displayed correctly. The information we hold on rectangle Node (two points and a normal on the rectangle plane) seems not to be enough to calculate properly the editing handle rotation matrix. Also today remembered that our 2 point rectangle tool has a restriction: it is drawn only having edges parallel with XOY, XOZ, YOZ planes. A solution to solve all these would be to implement a more powerful 3 point rectangle tool or at least enhance the 2 point rectangle to hold more info internally.

TwoPointLinePlugin Small Update

As one cotributor noticed, there was practically no way to change the icon in tree-view for given plugin also there was not added a property grid item to show how it works to extend property grid. A small refactor was done in this area to make those parts possible.

Finalized Rotate Gizmo

Improved the rotate Gizmo to "understand" circular gestures made by the user while rotating shapes:

Fixes On Layers/Plugins/Input

Layers had pending some updating errors. They were mostly pinned down. There was also that the change make that TestingPlugin was not starting. Unit tests start again (they would not start on Windows 64 machines as wrappers are 32 bit).
The installer will fail with SCSF changes because NaroStarter, the watchdog program that starts and monitor the NaroCAD main process it was working with some SCSF specific files. This part of code was removed and everything is just fine.
Another part of code that was largely improved was that code with multiple switches will be
I've also did performance profiling and I've seen that most of time regarding operations may be propagation time, mostly when is involving boolean operations or cut, which appear to be slow on Opencascade level, so I did not found a very good way to improve it.
Talking about code again, I've did work also in those days in code improvement based on reporting of a tool (Resharper as presented here) As the project starts. the error count starts with around 5000. Before weekend it was like 850 to 900 errors Right now we have 595 issues based on this source reporter, from which 393 are unused symbols. This unused symbols may be just areas with code that is disabled or not finished or events that may be false positive (because they are solved using reflection) or UI fields that in old code were directly used and after some refactors are not used by name anymore. So as code goes with around 200 coding errors or missusages, is really a much better code base than was just 6 month ago.
The Fillet/Chamfer dialogs have some tweaks to look with a NaroCAD theme, which is good for eye, even is not necesary that useful.
I will focus more on bug fixing and performance issues, and there are some OpenCascade updating issues (I'm not sure which area of code cause them, but I want to work at least as it was before SCSF was removed).

Code Separation (Step Three)

SCSF was fully removed from NaroCAD codebase. This may not sound much, but will likely simplify a lot of codebase interactions.
Some may ask why SCSF was used in first place, and why was removed? SCSF is a a framework that makes easy to solve use-cases. Even the specifics may be fairly hard to describe just in some lines, an use-case was an instance that activates in cascade other use-cases defined as a dependency and so on. Also it have a powerful dependency injection mechanism and also modules, that they behave as plugins.
SCSF is fairly complex, as the big is its featureset. This maked that usage in NaroCAD to be used as message passing framework, but to send a message, in most instances was sent a message globally (to the root of use-cases) and was hard to get an overview. Another issue with it was that integration with anything else was fairly hard. Even the events (the message passing) was done with adnotations, at the end, the code were translated eventually in NaroCAD actions.
Why NaroCAD have actions instead of using SCSF use-cases? Because SCSF was harder to track and debug and also it's dependency solving of the things that were needed was not that trivial. As the codebase was done, mostly the person that wanted to add for example a circle, started with OpenCascade code, tried to add it to OpenCascade view, and after this the code was separated and refactored to an unit named action. As an action was depending for mouse for example, the code was a big mix in the SCSF's controller class to make that action to get that mouse.
So NaroCAD Actions evolved to use pipes and filters and an pipes "solver" that will give the requested dependencies to that action. This gives for developper a bottom-up view, which is easier to aproach as you don't have to dwelve in the NaroCAD framework too deep: you copy/paste an action and its registering code and you're ready to go. Also this maked possible to add unit testing to them.
What about the plugins? The plugins of SCSF were nice, but the perceived advantages were really hard to setup in practice, as we would have to create an Xml parser and editor and insert nodes at specific points in the "ProfileCatalog.xml". Even this was done, with testing and bug fixing would take longer than setting up an auto_plugin.naro file where anyone can simply add plugins dinamically with much less tooling. Another good thing is that you mostly don't have to understand two conventions: SCSF ones and NaroCAD ones.
Pipes&Filters (as the internal NaroCAD actions framework behavior) are known to solve complexi problems even with multiple foreign frameworks and some of the most known are multimedia frameworks as DirectShow (or GStreamer) but also to launch custom eterogene tools: the Unix shells.
Today I've made that behavior to match the previos behavior and also I've removed all SCSF related libraries. You as an user may notice that future installations will be a bit smaller and also NaroCAD will start (a bit, but visible) faster as will not load and make some scanning of modules for attributes as SCSF did.
One last note: SCSF is really powerful, the problem is that from complex codebases, with virtually no design architect or a similar position, is fairly hard to be mapped as a top/down design, because most of the coding in specific tools is setup down.

Scale Gizmo

Finalized the first version of scale Gizmo. Tomorrow will improve its usability then finalize the Rotate Gizmo.

Code Separation (Step Two)

Right now NaroCAD in my branch (lordcip) have separated code as two sections: application based components and document based inputs.
This will make possible in close future to have support for multiple documents. Tomorrow anyway I will focus as code restructuring was fairly big big change in more than 100 files.
The multi-document setup initially will be as multi-tab but some changes may need to be done like: mostly testing the document over actions like copy/paste, auto-save handling and so on (as for now it connect to just one document change), but as those bugs will be pinned down, it will make possible to make the multi-document experience smooth.

Update: I will make later the multi-document coding. This code separation also (mostly) removed SCSF (a Microsoft componentization framework) and uses only NaroCAD frameworks internally. Also those changes will make code less complex in event handling (previously a button event was sent to another SCSF code and after this was translated in an action/meta-action. This would make impossible to register (if future UI mapping will be done) without writing in previous code two level mapping (SCSF and ActionGraph one). Right now is possible just to launch the action.

Code Separation And About Unit Testing

The unit testing was separated in multiple projeccts. Also I've undergone some code separation (yet not finished) to make possible in future to work with multiple documents. I've also made an analysis about what it takes, and some of the issues are also needed to be addressed: copy/paste may need to be reimplemented, importing should depend on metric system used, and more dependencies that are wired in a wrong way like property grid is created part of a document creation, when it should be application wide.
The unit testing right now can be made easier for individual modules and the idea of separating it is from our user Cyberdev.

New build: NaroCAD 1.5.2

Today made the NaroCAD 1.5.2 build.

Among the features of the new version are:

- 51 bugs fixed. More stable than previous versions,
- Plugin support implemented. Sample plugin provided,
- Added translate Gizmo,
- Improved editing Gizmos,
- Improved Fillet tool,
- Improved visual appearance.

The 1.5.2 version can be downloaded from here.

Some nice model made by our contributor Sami with the 1.5.2 version:

Gizmos

Implemented 3 Gizmo Types. Translate Gizmo works well. The Scale and Rotate need polishing, also they are affected by transformation bugs. Decided for the tomorrow release to enable only the Translate Gizmo.

Translate:


Rotate:



Scale:

Gradient flickering patch

Until the OpenCascade 6.4 version appears in order to use a gradient background applied a patch on OpenCascade engine: http://www.opencascade.org/org/forum/thread_16172/
The patch improved with 80% the flickering but there are still problems. It doesn't solve all the flickering.

Nightly Build

Made a nightly build including the latest fixes and features. At gizmos only the Translate Gizmo is active. You can download it from here.

Live Preview for Fillet, Fillet2D, Chamfer and Chamfer2D

The Cut preview makes easier to define your Cut. So the next logical step was to add a preview for other tools, and it was done nicely: four tools (they are very similar also) are getting a preview dialog. Also the dialog that you can input the value have a slider to not be forced to switch to keyboard. This slider will go from 1/10 of the original value (by default 1) to 10 times the same value.
Also bug fixing was done and I've almost finished a tutorial about how to create a simple shape via a plugin: