Some changes will be specially made to explicitly show side effects in code. As most of .Net developers (or C++ or Java on that matter) know that they create references by default, this have nice properties, mostly that avoid to make too many copies, but sometimes is hard to find where you did modified your content. Also for helper classes, like for example decorators (classes that simply call for you one API that is harder to use and will expose a simpler one) can be really convenient to be created but on the same time they can have side effects are even harder to find for the internal code.
So for this reason, an utility class that was used to work as a reference class, namely NodeBuilder, will become a struct type. This will make errors to be more strict and error handling much clear: is not possible to have null values, and the copies are explicit.
A small good side-effect of this change is that if theoretically a developper will want to make all shapes colored red, in the past will do like:
foreach shapesNode in scene do new NodeBuilder(shape).Color =Color.Red
The new code will be the same, but will not create garbage objects.
Another good change is that if you have a shape, is really easy to see which shapes are referenced, but is really hard to find the shapes that are referring your one.
For example: there are a rectangle, an extrude on top of it, and it's height is constrained.
If you have a reference to extrude, you can check by looking to extrude's shape content (for example using a NodeBuilder) which shape is built on, but to find which shapes are are constraining your extrude height, you have to literally look to entire scene.
For now I've did the change that at every shape change, when is computed the Solver step, in the same passing and having guaranteed O(n) (where n = number of shapes) time, a graph list is copmputed. This will make possible (is not yet made the migration) to accelerate and clean the code in constraints area (that will iterate over all nodes to see which is the shape is applying), delete code and in general will make less computationally looking backward in your internal referencing graph.
I made this structure anyway for wanting to make a chaing-based shape where the shape is made of a chain of small shapes (more of this will follow), so when you will click on an item, you will automatically want to know which are the list of shapes that make the full shape.
Thursday, December 30, 2010
Wednesday, December 29, 2010
Visual Hints Solver Related
Solver hints will be displayed based on shape. This is done using OpenCascade based drawing. They are bugs but they appear to be OCC based related, or at least missunderstanding the layer 2D API code.Anyway the Layer2D code is separated and will be possibly to be used as texts in other areas of code.
Tuesday, December 28, 2010
Solver Visualization Document Logic
Solver's visualization had a half heart transplant: firstly, as infrastructure was already done, all solver code was made as a document based drawing, limitations appear easily.
In short the design of Solver is like this:
- for all scene a intermediary representation named corresponding to geometry is stores like: Solver Point, Solver Edge, and so on
- a set of rules is processing the current mouse position (and sometimes the previous one) and returns a SolverPoint structure that stores all information that visualization need like: the plane, the point (that is the result of the applying the rule, for example to align to the a continuation of an line), a direction (for parallel lines) and a display logic, named marker
- if points are drawn, they did add interactive shapes to opencascade scene
How logic was changed?
- extraction remains the same, just that Solver Point, Solver Edge will store just the point, the edge and so on
- applying of rules will generate a SolverPreview instance. This will not make that SolverPoint to store the plane!? or direction!? Also if a rule will need to put extra data in visualization, will simply create a custom data that implements mostly a simple class that gives the new mouse position and a custom visualization routine based on NaroCAD's shapes
- before any visualization, the previous solver helper geometry will be cleared (_solverDocument.Revert() call),
- if a SolverPreview instance exists, will be called to execute it's preview code and will update the mouse coordinate.
The code behaves the same from user point of view, just by separating the extracting shapes by preview will make much simpler extending and fixing errors on Solver area. Stay tuned for changes!
In short the design of Solver is like this:
- for all scene a intermediary representation named corresponding to geometry is stores like: Solver Point, Solver Edge, and so on
- a set of rules is processing the current mouse position (and sometimes the previous one) and returns a SolverPoint structure that stores all information that visualization need like: the plane, the point (that is the result of the applying the rule, for example to align to the a continuation of an line), a direction (for parallel lines) and a display logic, named marker
- if points are drawn, they did add interactive shapes to opencascade scene
How logic was changed?
- extraction remains the same, just that Solver Point, Solver Edge will store just the point, the edge and so on
- applying of rules will generate a SolverPreview instance. This will not make that SolverPoint to store the plane!? or direction!? Also if a rule will need to put extra data in visualization, will simply create a custom data that implements mostly a simple class that gives the new mouse position and a custom visualization routine based on NaroCAD's shapes
- before any visualization, the previous solver helper geometry will be cleared (_solverDocument.Revert() call),
- if a SolverPreview instance exists, will be called to execute it's preview code and will update the mouse coordinate.
The code behaves the same from user point of view, just by separating the extracting shapes by preview will make much simpler extending and fixing errors on Solver area. Stay tuned for changes!
Monday, December 27, 2010
WebGL and HTML5, Can They Replace Desktop Applications?
In short the answer is yes. They can replace a lot of Flash usages, Flex.
Can you rewrite a NaroCAD-like application? The main blocks appear to be there: GWT is a Java framework that makes possible to create your own controls in your browser.
Also, WebGL is enabled by default in nightly builds of the recent browsers (excluding IE9 line and Opera for now). You can see a nice demo here.
But the hardest problems are things that NaroCAD do for free: fast undo/redo logic: we depend on reflection for it, even the logic can be simplified based on VM reflection. Another problem is tooling: we have from time to time performance problems as bugs occur, but we do have tools for it, I tend to use the great visual profiler of SharpDevelop, if you don't want to use a commercial one.
Another reason is just how WebGL demo shows: 10 year old graphics, performance is good, still a bit too slow (on my fairly powerful machine: i5 CPU, 330M graphics, some G of RAM and 1G VRAM). So if you will want responsive for more than just validating forms, it will be hard to spot: you have to test with almost all rutimes.
At the end the problem is on the big picture: developing with GWT, you will have like slow disk, slow performance for anything that your JS engine will excel (FF for mathematical loops, Chrome for OOP object).
So in short the answer for NaroCAD to be implemented in a web technology: changing logic to do some dispatch type logic, changing shape creation (the entire OpenCascade logic) to use JavaScript, will create a slow version of what is NaroCAD (or any other CAD on market). Can we seee something more in time? Probably as Silverlight plugins, or as web applets, without them, I'm not sure will be ever something possible.
In fact NaroCAD uses Generics in a way that even porting to Java or to C++ is fairly hard, as is combined with reflection, and C++ have better generics (templates) but no reflection, when Java have great reflection but bad generics.
So what are options to extend NaroCAD using more "open" languages. a language similar with Python we use already (Boo) which can be used to do scripting, but you can write an entire plugin if needed using SharpDevelop. I also found a lot of paradigms like functional one (F#), IronPython or IronRuby can be used with a small wrapper, UnityScript for people that like JS syntax.
Which is the main advantage of using .Net at the end? You will get a responsive application from top to bottom, and if you still have bottlenecks that you find that .Net does not generate a code as good as you want, you can call your C/C++ optimized code using P/Invoke. If you want to do the same for a web application, you're stuck with the version of your JavaScript machine implementation.
Can you rewrite a NaroCAD-like application? The main blocks appear to be there: GWT is a Java framework that makes possible to create your own controls in your browser.
Also, WebGL is enabled by default in nightly builds of the recent browsers (excluding IE9 line and Opera for now). You can see a nice demo here.
But the hardest problems are things that NaroCAD do for free: fast undo/redo logic: we depend on reflection for it, even the logic can be simplified based on VM reflection. Another problem is tooling: we have from time to time performance problems as bugs occur, but we do have tools for it, I tend to use the great visual profiler of SharpDevelop, if you don't want to use a commercial one.
Another reason is just how WebGL demo shows: 10 year old graphics, performance is good, still a bit too slow (on my fairly powerful machine: i5 CPU, 330M graphics, some G of RAM and 1G VRAM). So if you will want responsive for more than just validating forms, it will be hard to spot: you have to test with almost all rutimes.
At the end the problem is on the big picture: developing with GWT, you will have like slow disk, slow performance for anything that your JS engine will excel (FF for mathematical loops, Chrome for OOP object).
So in short the answer for NaroCAD to be implemented in a web technology: changing logic to do some dispatch type logic, changing shape creation (the entire OpenCascade logic) to use JavaScript, will create a slow version of what is NaroCAD (or any other CAD on market). Can we seee something more in time? Probably as Silverlight plugins, or as web applets, without them, I'm not sure will be ever something possible.
In fact NaroCAD uses Generics in a way that even porting to Java or to C++ is fairly hard, as is combined with reflection, and C++ have better generics (templates) but no reflection, when Java have great reflection but bad generics.
So what are options to extend NaroCAD using more "open" languages. a language similar with Python we use already (Boo) which can be used to do scripting, but you can write an entire plugin if needed using SharpDevelop. I also found a lot of paradigms like functional one (F#), IronPython or IronRuby can be used with a small wrapper, UnityScript for people that like JS syntax.
Which is the main advantage of using .Net at the end? You will get a responsive application from top to bottom, and if you still have bottlenecks that you find that .Net does not generate a code as good as you want, you can call your C/C++ optimized code using P/Invoke. If you want to do the same for a web application, you're stuck with the version of your JavaScript machine implementation.
Notification Tree - a Sneak Peak
As work continues on Solver displaying (I have a problem on displaying the same behavior using document based drawing), I've did another small gift for external developers: NotificationTree.
What is it useful?
The idea comes from using D-Bus (where you register and notify based on paths). We picked this extra input for cases that NaroCAD cannot solve. I am talking aloud some cases that NaroCAD will not be able to solve with it's actual design: supposedly there is an operation over the network, or running in an external process, and you switch your working action in the meantime as you wait for result in design mode. How can you get back notified? You want to notify a component that is not defined nicely in your design in NaroCAD framework and integration is too hard to be done: NaroCAD integrates click tree with selection, which is great for users, but if you will want to extend, change the code as it goes with mouse clicks, or you want your ribbon state to change on solver changes, you did had no methods to do it as you mostly can get only life-cycle notifications and you will have to be too hacky in our code-base to do your work.
Just if you have those cases, and you looked to NaroCAD code-base and you did not know where to start, right now is fairly easy:
- try to make a plugin, start from TwoPointLine plugin that is provided with NaroCAD
- try to instantiate inputs. Try to get the NotificationTreeInput instance and use the GetValue to get a document from it
- try to register a notification using: Document. Root. Set<NotificationInterpreter>(). RegisterPath("MyComponent/OnMyEvent", OnMyEventHandler) where
void OnMyEventHandler(Node pathNode)
{
(...) //your code
}
To call this code, you can call it like this:
Document. Root. Set<NotificationInterpreter>(). NotifyPath("MyComponent/OnMyEvent");
This code will mainly mean to you that you will be able to extend NaroCAD with all events that are given.
As events are called, there is internal propagation logic that you can use it to monitor subpaths, this will not be wrapped as it appear to me to be also a hacky way to do it, but anyway, the main idea is that if you feel that are limitations on NaroCAD level, it may be easier as of today to overcome them.
What is it useful?
The idea comes from using D-Bus (where you register and notify based on paths). We picked this extra input for cases that NaroCAD cannot solve. I am talking aloud some cases that NaroCAD will not be able to solve with it's actual design: supposedly there is an operation over the network, or running in an external process, and you switch your working action in the meantime as you wait for result in design mode. How can you get back notified? You want to notify a component that is not defined nicely in your design in NaroCAD framework and integration is too hard to be done: NaroCAD integrates click tree with selection, which is great for users, but if you will want to extend, change the code as it goes with mouse clicks, or you want your ribbon state to change on solver changes, you did had no methods to do it as you mostly can get only life-cycle notifications and you will have to be too hacky in our code-base to do your work.
Just if you have those cases, and you looked to NaroCAD code-base and you did not know where to start, right now is fairly easy:
- try to make a plugin, start from TwoPointLine plugin that is provided with NaroCAD
- try to instantiate inputs. Try to get the NotificationTreeInput instance and use the GetValue to get a document from it
- try to register a notification using: Document. Root. Set<NotificationInterpreter>(). RegisterPath("MyComponent/OnMyEvent", OnMyEventHandler) where
void OnMyEventHandler(Node pathNode)
{
(...) //your code
}
To call this code, you can call it like this:
Document. Root. Set<NotificationInterpreter>(). NotifyPath("MyComponent/OnMyEvent");
This code will mainly mean to you that you will be able to extend NaroCAD with all events that are given.
As events are called, there is internal propagation logic that you can use it to monitor subpaths, this will not be wrapped as it appear to me to be also a hacky way to do it, but anyway, the main idea is that if you feel that are limitations on NaroCAD level, it may be easier as of today to overcome them.
Sunday, December 26, 2010
Document Based Solver Drawing
NaroCAD is on top of OpenCascade, anyway some parts of code use(d) OpenCascade directly. The advantage is flexibility, the biggest disadvantage is of course all things that are for free like, but not limited to: document lifecycle, easier to made in a consistent way shape definition.
As Solver shape updating code was a bit old, I think at the same time when Document class was created historically, So the code in this area is replaced to use a document. The biggest change will likely be the capability to draw as many and as complex shapes as NaroCAD offers from one side, combined with code simplicity on the other side.
As Solver shape updating code was a bit old, I think at the same time when Document class was created historically, So the code in this area is replaced to use a document. The biggest change will likely be the capability to draw as many and as complex shapes as NaroCAD offers from one side, combined with code simplicity on the other side.
Saturday, December 25, 2010
Easier to Write Interpreters
This is like a Christmas gift for some, mostly for plugin writers. In short is just this: if you subclass (derive) from the new class: NaroDataInterpreter instead of AttributeDataInterpreter and you have just integer and double properties, they will be serialized/deserialized automatically via Reflection. Probably more automatic types will come but in case you had somelike simple like an store class for integers you will just have to do like this code:
public class IntegerInterpreter : NaroDataInterpreter
{
public int Value
{
get { return _value; }
set
{
_value = value;
OnModified();
}
}
private int _value;
}
Compared with (old code):
public class IntegerInterpreter : AttributeInterpreterBase
{
#region Properties
public int Value
{
get { return _value; }
set
{
_value = value;
OnModified();
}
}
public override void Serialize(AttributeData data)
{
data.WriteAttribute("Value", _value);
}
public override void Deserialize(AttributeData data)
{
Value = data.ReadAttributeInteger("Value");
}
private int _value;
}
Of course you can have other types/extra logic on serialize/deserialize and in those cases you will be able to override and to use the basic code for properties that you want and to add your custom code right in the same very place. This will benefit mostly the plugin writers that will be able to define custom elements inside of NaroCAD's document tree data.
public class IntegerInterpreter : NaroDataInterpreter
{
public int Value
{
get { return _value; }
set
{
_value = value;
OnModified();
}
}
private int _value;
}
Compared with (old code):
public class IntegerInterpreter : AttributeInterpreterBase
{
#region Properties
public int Value
{
get { return _value; }
set
{
_value = value;
OnModified();
}
}
public override void Serialize(AttributeData data)
{
data.WriteAttribute("Value", _value);
}
public override void Deserialize(AttributeData data)
{
Value = data.ReadAttributeInteger("Value");
}
private int _value;
}
Of course you can have other types/extra logic on serialize/deserialize and in those cases you will be able to override and to use the basic code for properties that you want and to add your custom code right in the same very place. This will benefit mostly the plugin writers that will be able to define custom elements inside of NaroCAD's document tree data.
Friday, December 24, 2010
Happy Winter Holidays 2011
NaroCAD team wish to our contributors, users and anyone involved to our project (and not only!) to enjoy happy holidays and a good time close to persons dear and to share the spirit of those days!
Also we are really pleased to notice that in our fairly short existence to get great usage and we will work to improve it.
So Happy Winter Holidays and look to our blog for more updates to come!
Also we are really pleased to notice that in our fairly short existence to get great usage and we will work to improve it.
So Happy Winter Holidays and look to our blog for more updates to come!
Wednesday, December 22, 2010
Unification Of Display Code for Interactives/TopoDS
OpenCascade works visually with AIS_InteractiveObject instances that are added in a scene (AIS_InteractiveContext). Anyway, most objects do represent themselves in topological form (TopoDS_Shape) and based on them we build the AIS_Shape (an implementation of interactives). Anyway, other parts of code do not have access to TopoDS_Shape objects. The most used tool that is interactive, is Dimension.
So for that we used another code path that handles interactives and this shows, mostly in bugs: you cannot switch color for interactives, you cannot select them as our code depends on detecting the underlying TopoDS from one side and the code is explicitly around that logic, not around interactives. This make (and is still true) to be impossible not just selecting (that is theoretically possible with this change), but also changing color (this is possible if Dimension is setup visible in tree, and I've did that, but you can change for example for any length constraints that display a dimension).
The latest advantage of this change is the way was done it: it manages a list of AIS_Interactive all the time, so navigating through them is much more compact code with no two code paths, so adding possibility to select dimension like shapes (and any future AIS_Interactive code) to be possible and easier to be done (in fact a prototype code is there, and with help of bxtrx, this code may be really here fairly soon ;) ).
So for that we used another code path that handles interactives and this shows, mostly in bugs: you cannot switch color for interactives, you cannot select them as our code depends on detecting the underlying TopoDS from one side and the code is explicitly around that logic, not around interactives. This make (and is still true) to be impossible not just selecting (that is theoretically possible with this change), but also changing color (this is possible if Dimension is setup visible in tree, and I've did that, but you can change for example for any length constraints that display a dimension).
The latest advantage of this change is the way was done it: it manages a list of AIS_Interactive all the time, so navigating through them is much more compact code with no two code paths, so adding possibility to select dimension like shapes (and any future AIS_Interactive code) to be possible and easier to be done (in fact a prototype code is there, and with help of bxtrx, this code may be really here fairly soon ;) ).
Tuesday, December 21, 2010
BRepExtrema wrappers
Wrapped the BRepExtrema package and uploaded the sources on SVN.
Rebuilt the wrappers that Naro uses amd added there the BRepExtrema classes. These are used within solver to calculate edge intersections. Added also the GeomAPI_ExtremaCC, CS and SS on the wrappers for more advanced curve intersections.
Rebuilt the wrappers that Naro uses amd added there the BRepExtrema classes. These are used within solver to calculate edge intersections. Added also the GeomAPI_ExtremaCC, CS and SS on the wrappers for more advanced curve intersections.
Zoom to mouse cursor position
Improved the zoom in and out.
It zooms where the mouse cursor is. When zooming out, the distance between the mouse cursor and the center of the created view increases.
The current viewing shortcuts are:
- press and hold shift and scroll wheel: pan,
- press and hold mouse wheel: dynamic rotate,
- mouse wheel: zoom in/out at mouse position,
- press and hold right mouse button: pan.
It zooms where the mouse cursor is. When zooming out, the distance between the mouse cursor and the center of the created view increases.
The current viewing shortcuts are:
- press and hold shift and scroll wheel: pan,
- press and hold mouse wheel: dynamic rotate,
- mouse wheel: zoom in/out at mouse position,
- press and hold right mouse button: pan.
Ege intersection magic points
Added a new feature: the solver detects edge intersection points. It works for all curves including splines, 2D shapes that have intersecting edges and solids that have intersecting edges.
Monday, December 20, 2010
Parallel Line Mouse Hinter Performance Improvements
Parallel Line historically was a problematic area. Excluding the parallel with axis code, the rest of code was at best problematic performance and correctness wise.
Why?
In the past we know how to test if your line was parallel with other line, but when we did extract the geometry of the shape was around the point of the shapes. In very old implementations we did match all points with all points, in pairs of two, which was the biggest section on profiling solver. So for a rectangle we would compare like 6 edges (four edges and diagonals). And for a box, eh, somelike 38 edges, having included all edges, internal and external diagonals. As around one month ago, parallelism computing was improved by just taking consecutive points on a shape (0,1), (1,2) (n-1, 0), so for a rectangle will compare with just 4 edges, and for a box, even some edges were erroneous, were just 8 to compare.
Today's change was two fold: correctness: we extract just edges, and not any edge, but edges that are straight, so a spline will not give to you parallel line to align with. In a similar manner, we also improve performance for sane cases: a rectangle and a parallelogram will have some edges that are parallel with each other (in our case two), so why not remove duplicates before are tested over and over again. Going back to a box shape, the comparison will be just for 3 axis, not 38. Another part is that the parallel data is specially prepared to not make any extra computation (in special creation of gp_Vec objects) that will improve the real time behavior.
Still not impressed? The initial "Lua gear", actually the Boo gear, will work with 20 instead of 160 edges to compare, this is done for 20 teeths (so close to 8x duplicates, in part easy to predict 4x, as 2x come from extrude and 2x from symmetrical OY shape). In general, is to be expected an improvement at least of 2x for 3D extruded shapes, but typically you will care more about design and less about time that a hinter may compute wrong parallel lines.
Why?
In the past we know how to test if your line was parallel with other line, but when we did extract the geometry of the shape was around the point of the shapes. In very old implementations we did match all points with all points, in pairs of two, which was the biggest section on profiling solver. So for a rectangle we would compare like 6 edges (four edges and diagonals). And for a box, eh, somelike 38 edges, having included all edges, internal and external diagonals. As around one month ago, parallelism computing was improved by just taking consecutive points on a shape (0,1), (1,2) (n-1, 0), so for a rectangle will compare with just 4 edges, and for a box, even some edges were erroneous, were just 8 to compare.
Today's change was two fold: correctness: we extract just edges, and not any edge, but edges that are straight, so a spline will not give to you parallel line to align with. In a similar manner, we also improve performance for sane cases: a rectangle and a parallelogram will have some edges that are parallel with each other (in our case two), so why not remove duplicates before are tested over and over again. Going back to a box shape, the comparison will be just for 3 axis, not 38. Another part is that the parallel data is specially prepared to not make any extra computation (in special creation of gp_Vec objects) that will improve the real time behavior.
Still not impressed? The initial "Lua gear", actually the Boo gear, will work with 20 instead of 160 edges to compare, this is done for 20 teeths (so close to 8x duplicates, in part easy to predict 4x, as 2x come from extrude and 2x from symmetrical OY shape). In general, is to be expected an improvement at least of 2x for 3D extruded shapes, but typically you will care more about design and less about time that a hinter may compute wrong parallel lines.
Plugin Manager Tool
As I work on other areas (mostly on hinter), a visual tool for editing plugins was made. Why this tool is important? Because it makes more clear (even still need some polish) to you to write extensions and to register them just with some clicks. To be fair, you will need 4 clicks to enable 1 plugin you already have in the NaroCAD's exe folder: double click to start the application, a click to add in the plugin list and the final click to close the dialog. If is in another folder, it will be copied for you in the current folder so you can enable it right away.As in this screenshot, there are 5 accessible plugins, the first three are in the default config, but one is disabled (NaroCAD.Plugin.Structural.Design), and the other two are fully out of config.
So as you will have an easier plugin registering, and less looking for config (auto_plugin.naro file) as you (for certain) try to write your plugin, you will have soon news on solver side.
Sunday, December 19, 2010
Quality of Service Solver Changes
Probably this is a more confusing change than others, but will make a great deal when things work wrong. So what is it about: the point hinter (we name it solver) have sometimes a bad scalability performance, and the areas that are more sensible are: parallel line hinter, and the point hinter, but at any time, any of them can be expensive.
So internally NaroCAD will check frame per frame, when you move mouse around if the time to take is bigger than a time range (150 ms) threshold and if yes, will notify (kindly, will do it just once) you if you want to disable this component. This will make a great deal for people that do not know why NaroCAD works slow, and will solve at least for users that do designs where our hinter works too slow, to have to know why and to be able at the end to be able to have an easy fix for it.
So internally NaroCAD will check frame per frame, when you move mouse around if the time to take is bigger than a time range (150 ms) threshold and if yes, will notify (kindly, will do it just once) you if you want to disable this component. This will make a great deal for people that do not know why NaroCAD works slow, and will solve at least for users that do designs where our hinter works too slow, to have to know why and to be able at the end to be able to have an easy fix for it.
Friday, December 17, 2010
Spline editing handler
Added editing handlers at spline. That would allow user to modify the drawn spline by dragging its points.
Thursday, December 16, 2010
Import/Export From NaroXml and What It Use? (Part II)
Importing was fixed to a good degree of confidence.
Sometimes the build give an error just from command line because of WPF related issues. The cause is that MSBuild have a different behavior on building solution compared with building from Visual Studio IDE. The fixes makes that nightly build to run (most likely) from first step. But if not, the errors may be solved using a similar pattern:
The error says like: cannot find 'Command' as property in base class. And the code is like: CustomControl subclasses (derives) a RibbonMappingControl which in itself inherits a RibbonButton. The CustomControl class should write RibbonMappingControl.Command instead of RibbonButton.Command.
So probably a nightly build will follow soon to test the blogs entries that are up-to-date and you may enjoy using those features.
Sometimes the build give an error just from command line because of WPF related issues. The cause is that MSBuild have a different behavior on building solution compared with building from Visual Studio IDE. The fixes makes that nightly build to run (most likely) from first step. But if not, the errors may be solved using a similar pattern:
The error says like: cannot find 'Command' as property in base class. And the code is like: CustomControl subclasses (derives) a RibbonMappingControl which in itself inherits a RibbonButton. The CustomControl class should write RibbonMappingControl.Command instead of RibbonButton.Command.
So probably a nightly build will follow soon to test the blogs entries that are up-to-date and you may enjoy using those features.
Magic point improvement
Improved the solver to detect magic points under mouse even if they are not on the current drawing plane.
On the picture below I started drawing a line on the base plane and could catch the cone top although I am not on that plane. This feature will also help at drawing "up" without helper geometry like the 3 initial planes.
On the picture below I started drawing a line on the base plane and could catch the cone top although I am not on that plane. This feature will also help at drawing "up" without helper geometry like the 3 initial planes.
Wednesday, December 15, 2010
Import/Export From NaroXml and What It Use?
Sometimes you did work to design a car, and you just did hardly a wheel. What can you do? You will copy/paste it and you will be ready to go. What if someone else did a car frame, you did the engine, and you want to combine your work?
NaroCAD had previously no way to do it. Right now two tools are ready to help you: Import from NaroXml which basically will do rebuild the shapes with re-based indices, and an export tool, which will save just the selected shapes.
Probably this will make easier sharing and will improve the way you design shapes by splitting your design in parts.
NaroCAD had previously no way to do it. Right now two tools are ready to help you: Import from NaroXml which basically will do rebuild the shapes with re-based indices, and an export tool, which will save just the selected shapes.
Probably this will make easier sharing and will improve the way you design shapes by splitting your design in parts.
Tuesday, December 14, 2010
Version 1.5.4 Is Released
Version 1.5.4 was released. It make review a lot of older issues and functionality that will make NaroCAD to run smoother, so more tools will work better:- Added AngleDraft Tool: to make possible to chose the angle between two faces
- Added Rotate Around Axis Tool: you can have a more precise rotation than gizmos. Also gizmos are showing your shape transparent as you drag it. A dialog will point to you to write precise angle values.
- Added helper tools: copy and synchronizing tools between shapes: this will make easier to design repetitive designs or you want to make more tools to have consistent values all along.
- Added Rectangle with 3 points tool and added parallelogram tool: you will want a free hand rectangle? On any plane? A rectangle defined by three points is there. Also rectangle is kept internally as a parallelogram, making less prone to errors in case of transformations.
- Added Layout Saving Support: this will make easier to work with your custom layouts
- Added Edge on Edge constraint: based on fixes that were landed from previous iteration on transformations, we were able to spot and eventually enable a fixed Edge on Edge constraint
- Fixed Solver Bugs, enhanced its speed: when you iterate more shapes, OpenCascade will generate sometimes duplicate points. This consolidation was done because we wanted to trade the pre-compute time to real-time mouse movement, when moving mouse around should not be a slow operation as we check all scene points. We do consolidate them even from previous versions, but this algorithm was a bit slow as it checks all already existing points. This anyway had a big performance impact when you define a shape with many (more than hundreds) of points, the interface may freeze for minutes. Right now for very big point counts still some overhead is noticeable, but is two order of magnitude less for one thousand or more of points (like seconds, not minutes)
- Fixed unit tests: based on work of our contributor CyberDev our code is better tested mostly in plugin area. He works for his plugin and hopefully we will see more in his area.
- It was improved parametric modeling performance at File Load: we did change the way File Load is handled internally to reduce to minimum the loading of files: we clean the scene before we do our shape building, so it will also reduce the propagation cascade that happen for very similar scene changes
- Fixed propagation issues: opening files may make sometimes that for some tools that propagation to not work anymore
- Added center magic points at basic geometry (circle center, cone center, etc): you will have more magic points, in special on center of circle based shapes (both for sketch or solids)
- Gizmos can be selected from tree: so if you have an inaccessible shape, to drag it, you may use tree-view to select it, after it, you can see the gizmo to modify it. Also the shapes that you drag are transparent as you drag them.
- Property grid fixes: new handler code were done for the new tools of Rectangle/Parallelogram and fixes were also done.
Download from here.
NaroCAD Parametric Modeling Sample
Made a tutorial sample on how to use the parametric modeling features of NaroCAD together with Gizmos.
On the sample movie I selected from tree the rectangle on which an extrude is made or the circle used to make a cut. The shapes are invisible on scene but they can be selected in tree and Gizmos activate on them:
On the sample movie I selected from tree the rectangle on which an extrude is made or the circle used to make a cut. The shapes are invisible on scene but they can be selected in tree and Gizmos activate on them:
Angle Draft Tool
AngleDraft tool started working in most cases. From here we can start improving its usability.
A sample video:
A sample video:
Friday, December 10, 2010
NaroCAD 1.5.4 release plan
Last week worked at fixing and stabilizing the new functionality.
Currently NaroCAD 1.5.4 is almost at the stability level of the 1.5.3 version. In order to keep the quality at the level from 1.5.2 and 1.5.3 versions we'll continue testing and bug fixing for 2-3 more days. Planning to release the new version around Tuesday.
Currently NaroCAD 1.5.4 is almost at the stability level of the 1.5.3 version. In order to keep the quality at the level from 1.5.2 and 1.5.3 versions we'll continue testing and bug fixing for 2-3 more days. Planning to release the new version around Tuesday.
Angle Draft tool
Implemented the Angle Draft feature to demonstrate its usability. The feature is still very sensitive at the faces selected and also at their selection order, in many cases it doesn't work. Will be included in the next release version for demonstration purposes.
AngleDraft working case:
For the moment used a dialog box to set the angle as this was simpler to implement. After the feature will work well in most cases, will think on how to improve it as usability.
AngleDraft working case:
For the moment used a dialog box to set the angle as this was simpler to implement. After the feature will work well in most cases, will think on how to improve it as usability.
Improved rectangle dragging handles
The latest improvements at the rectangle tool allowed dragging handlers to be fixed and work well also when complex transformations are applied on it.
Editing a rectangle with several rotations applied on it:
Editing a rectangle with several rotations applied on it:
Monday, December 6, 2010
New Synchronize Tools
As was already told, you can synchronize two tools values. Another handy tool is the Copy Deep Tool: you will use it to define a chain of tools from one shape on top of other shape.A smaller version of it is just to apply one copy tool to another shape.
This will reduce property grid accesses and will reuse long and boring design works.
So enjoy using those tools.
Sunday, December 5, 2010
Syncronize Tool
A new tool was added to make easier modelling with various tools. The idea of it is simple: pick two extrudes and make sure that they share the same values. Another tool that will be done soon will be the one that you pick a source shape, and a destination shape, and all tools applied on the source tool will be set on the destination shape.
So stay tuned for updates!
So stay tuned for updates!
Friday, December 3, 2010
NaroCAD Team At Its Glory
NaroCAD team is together in Timisoara/Romania where most of developers and contributors are here.From left to right are: Samy, Mihai, Cristi and Ciprian (myself)
Thursday, December 2, 2010
Solver Extra Points, Rectangle Usage Improvments
Solver will generate center of circle, ellipse, arc, torus, cone and cylinder will offer extra points in center. Another improvement (with work from me and bxtrx) is that are two rectangle tools: the default two points defined, a ¨free¨ three points rectangle and a parallelogram.
Tuesday, November 30, 2010
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.
So wait for the new version to be able to have a more responsive NaroCAD.
Sunday, November 28, 2010
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.
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.
Wednesday, November 24, 2010
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.5When 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.
Tuesday, November 23, 2010
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.
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.
Monday, November 22, 2010
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).
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).
Friday, November 19, 2010
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...
Tuesday, November 16, 2010
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.
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.
Monday, November 15, 2010
Finalized Rotate Gizmo
Improved the rotate Gizmo to "understand" circular gestures made by the user while rotating shapes:
Sunday, November 14, 2010
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).
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).
Wednesday, November 10, 2010
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.
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.
Tuesday, November 9, 2010
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.
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.
Sunday, November 7, 2010
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.
The unit testing right now can be made easier for individual modules and the idea of separating it is from our user Cyberdev.
Friday, November 5, 2010
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:
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:
Thursday, November 4, 2010
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:
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.
The patch improved with 80% the flickering but there are still problems. It doesn't solve all the flickering.
Wednesday, November 3, 2010
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.
Tuesday, November 2, 2010
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:
Also bug fixing was done and I've almost finished a tutorial about how to create a simple shape via a plugin:
Sunday, October 31, 2010
Some Other Bug Fixes
As delete operations did get some fixing, an annoying part of unit tests was that MessageBox calls are blocking UI, so you have to manually advance some unit tests, mostly in cases that they report an error. Right now will exist a NaroMessage class that will permit that makes message boxes to not block the UI in unit tests case, but still to block the UI in using NaroCAD.
Another change was separation at code level in PartModelling code in three: Controller code (the old PartModelling project), the UI code (like custom controls that are called from actions) and the Logic code, with the actions code. So developer can navigate more punctually to area that is interested, without navigating in the biggest assembly that was in NaroCAD project. This, combined with the separating the UI (mostly the ribbon) from the action code, will likely mean that you will easier spot problems in a specific smaller code.
All inputs that have big switches (mostly to handle notifications and to handle the data that was send from inputs), were also cleaned up and the selection of data is done internally by a SortedDictonary class.
Solver visibilitity works also over layers, so if you work with some layers and you hide them, the shapes attached to a specific layer will not show to you. More layer related fixes were done in the last days.
A performance related bug (that after you draw a complex shape, switching actions will be slow, as shape will regenerate) was also fixed. This took longer to be solved as I've got not an easy test to solve it. An unit test was added, so probably will be no performance regression in future. At least with this specific shape.
Cutting and selection from tree sometimes used to work wrong, and those problems were of the handling code around tree view. I've fixed both the way the tree selection was handled and the actions that were calling it to avoid caching values from the previous selections, so to appear that selection works, and also to make code to read late the selection from tree, this making not synchronized extrudes/cuts to happen. Hopefully those will fix problems in this area, but some extra testing may be done.
If you input in property grid values that makes your construction invalid (for example you will write a negative range for a circle), property grid will restore the previous value. This will mostly fix a lot of issues when trying to work with Fillet like operations where values may get invalid.
Unit testing is also green again. Was also fixed Solver related testing.
Another change was separation at code level in PartModelling code in three: Controller code (the old PartModelling project), the UI code (like custom controls that are called from actions) and the Logic code, with the actions code. So developer can navigate more punctually to area that is interested, without navigating in the biggest assembly that was in NaroCAD project. This, combined with the separating the UI (mostly the ribbon) from the action code, will likely mean that you will easier spot problems in a specific smaller code.
All inputs that have big switches (mostly to handle notifications and to handle the data that was send from inputs), were also cleaned up and the selection of data is done internally by a SortedDictonary class.
Solver visibilitity works also over layers, so if you work with some layers and you hide them, the shapes attached to a specific layer will not show to you. More layer related fixes were done in the last days.
A performance related bug (that after you draw a complex shape, switching actions will be slow, as shape will regenerate) was also fixed. This took longer to be solved as I've got not an easy test to solve it. An unit test was added, so probably will be no performance regression in future. At least with this specific shape.
Cutting and selection from tree sometimes used to work wrong, and those problems were of the handling code around tree view. I've fixed both the way the tree selection was handled and the actions that were calling it to avoid caching values from the previous selections, so to appear that selection works, and also to make code to read late the selection from tree, this making not synchronized extrudes/cuts to happen. Hopefully those will fix problems in this area, but some extra testing may be done.
If you input in property grid values that makes your construction invalid (for example you will write a negative range for a circle), property grid will restore the previous value. This will mostly fix a lot of issues when trying to work with Fillet like operations where values may get invalid.
Unit testing is also green again. Was also fixed Solver related testing.
Delete Behavior Updated
As said previously, NaroCAD changed slightly the delete behavior. The old behavior was like following: any shape you delete, it will delete itself and all impacted, shapes. For example if you removed a sphere that is a part of the result of a Boolean operation, both sphere and the Boolean shapes were removed.
The new behavior will be two steps operation: hide from tree and from scene and if is not reachable, will be removed and with all related shapes that may also become unreachable. So in this way, if you remove the sphere from the previous Boolean operation, nothing happen.
This change of behavior makes easier to you to create helper shapes and remove them, without being afraid that the result may impact your final shape.
Anyway, this will not make possible all combinations, because some operations have side effects: if you do an extrude on a rectangle, and you will delete the extrude, the rectangle referenced by your rectangle is hidden, so when the delete logic will hide extrude, both extrude and rectangle are unreachable, and both will be removed from scene.
Probably in future shapes can register with custom delete code, to restore the side effects, if you don't want to do an Undo, but this need some changes in architecture and will make an overhead for someone implementing a new tool to add this extra code, so things may be thought in advance.
The new behavior will be two steps operation: hide from tree and from scene and if is not reachable, will be removed and with all related shapes that may also become unreachable. So in this way, if you remove the sphere from the previous Boolean operation, nothing happen.
This change of behavior makes easier to you to create helper shapes and remove them, without being afraid that the result may impact your final shape.
Anyway, this will not make possible all combinations, because some operations have side effects: if you do an extrude on a rectangle, and you will delete the extrude, the rectangle referenced by your rectangle is hidden, so when the delete logic will hide extrude, both extrude and rectangle are unreachable, and both will be removed from scene.
Probably in future shapes can register with custom delete code, to restore the side effects, if you don't want to do an Undo, but this need some changes in architecture and will make an overhead for someone implementing a new tool to add this extra code, so things may be thought in advance.
Friday, October 29, 2010
New feature: Translate Gizmo
Finalized implementing a first version of translate Gizmo that applies to all shapes from scene. The Translate Gizmo is displayed on the mass center of the shape. While Gizmos and editing handlers are displayed the shape transparency is set to 50% so that editing handles and gizmos can be dragged even if they are located inside the solid.
As functionality it allows users to translate a shape on one of the X, Y or Z axis or on the XOY, ZOX, YOZ planes.
Fixed the big bugs existing at editing handles and translate Gizmos.
A preview movie of the feature:
As functionality it allows users to translate a shape on one of the X, Y or Z axis or on the XOY, ZOX, YOZ planes.
Fixed the big bugs existing at editing handles and translate Gizmos.
A preview movie of the feature:
Tuesday, October 26, 2010
Pinning Down Bugs and Cleaning Plugin Interfaces
The first part is more clear from title: a crash that happen to be in this simple case:
var document = new Document();
document.Commit("A point was added");
did crash NaroCAD. This happen for a wrong usage of NaroCAD framework, but as right now this case was solved.
Also unit testing was added in this area, to not make it crash again.
An area that was fixed was to reduce dependencies when you implement a plugin.
So as you write a plugin you will be able to extend starting from 3 points:
- interpreters: adding persistent data (custom data) in the data tree that is storing information as colors and so on
- functions: adding your custom shape (like circle, line, box, tools)
- ActionGraph one: as action graph you will have already access to extend Inputs and Actions. The good part is that this ActionGraph will offer as Inputs some factories that are less used or are defined related with actions. This change will reduce all dependencies needed to extend NaroCAD to just one dependency: ActionGraph, and also gives possibility to add later new factories (for example ways to add custom hinting rules).
I will focus to fix bugs that are annoying and I will polish documentation how to make plugins.
Also a small good side effect is that the inputs were split in three categories:
- Infrastructure - like basic controls for opening/save files, the document context, OpenCascade view
- Factories - like already told PropertGrid factories to extend the sections of it, UIBuilder to add to Ribbon or other UI elements some other functionality
- Pipes: that combine Inputs functionality and give high level functionality. As examples are: Face picker pipe, or Selection Container, that provides for people that extend NaroCAD an easy to use form of using selection.
This will mean that NaroCAD can have just the first two sets: Infrastructure and Factories inputs, and almost all NaroCAD can be split in plugins, not just only actions. This also makes for someone looking what those inputs consists in, to navigate easier to them.
var document = new Document();
document.Commit("A point was added");
did crash NaroCAD. This happen for a wrong usage of NaroCAD framework, but as right now this case was solved.
Also unit testing was added in this area, to not make it crash again.
An area that was fixed was to reduce dependencies when you implement a plugin.
So as you write a plugin you will be able to extend starting from 3 points:
- interpreters: adding persistent data (custom data) in the data tree that is storing information as colors and so on
- functions: adding your custom shape (like circle, line, box, tools)
- ActionGraph one: as action graph you will have already access to extend Inputs and Actions. The good part is that this ActionGraph will offer as Inputs some factories that are less used or are defined related with actions. This change will reduce all dependencies needed to extend NaroCAD to just one dependency: ActionGraph, and also gives possibility to add later new factories (for example ways to add custom hinting rules).
I will focus to fix bugs that are annoying and I will polish documentation how to make plugins.
Also a small good side effect is that the inputs were split in three categories:
- Infrastructure - like basic controls for opening/save files, the document context, OpenCascade view
- Factories - like already told PropertGrid factories to extend the sections of it, UIBuilder to add to Ribbon or other UI elements some other functionality
- Pipes: that combine Inputs functionality and give high level functionality. As examples are: Face picker pipe, or Selection Container, that provides for people that extend NaroCAD an easy to use form of using selection.
This will mean that NaroCAD can have just the first two sets: Infrastructure and Factories inputs, and almost all NaroCAD can be split in plugins, not just only actions. This also makes for someone looking what those inputs consists in, to navigate easier to them.
Monday, October 25, 2010
Gizmo progress
Refactored the editing handle dragging functionality to use actions. This assures a better code separation. There are still bugs to solve at this code.
Implemented the Gizmo infrastructure and implemented a first version of the translate Gizmo. The translation Gizmo will have 3 arrows allowing the user to drag the shape on the 3 axis and 3 planes that will allow the user to move the shape on the 3 planes: XOY, XOZ, YOZ. It is not working properly yet.
Implemented the Gizmo infrastructure and implemented a first version of the translate Gizmo. The translation Gizmo will have 3 arrows allowing the user to drag the shape on the 3 axis and 3 planes that will allow the user to move the shape on the 3 planes: XOY, XOZ, YOZ. It is not working properly yet.
Friday, October 22, 2010
Bug Fixing
If you used NaroCAD in developer versions you may notice that the release builds give at exit an error dialog that popup because a crash was found. The good part is that it is a false positive because at exit, the logic that ask you to save the work you are doing will not cleanup NaroCAD nicely, even does not give any crash.
Another fix and improvement is that deleting shapes have a fairly complex unit test: a boolean operation is done, after this a mirror of this boolean is done, and at the end the first boolean is deleted. This triggers a chain deletion because the first shape deletes the shapes that is built on, without "noticing" that will make the mirrored boolean invalid, and makes both to be deleted. The logic is changed that deletion will work by the principle of garbage collector (we used previously this algorithm, and we have to cover the other test cases that will bring problems, mostly if you use shift+delete and the dialog that appears you will delete some shapes that are base for other shapes). The algorithm today will make impossible (or even possibly will crash) to remove those nodes. Anyway, this will be improved and if you will want to delete shapes that are referenced by other shapes, is easier just to delete the visible shapes, and all invisible shapes will disappear by themselves).
One another small fix is just that you cannot create a layer with the same name of an existing one. This will avoid confusion for you and make you use layers efficiently.
Another fix and improvement is that deleting shapes have a fairly complex unit test: a boolean operation is done, after this a mirror of this boolean is done, and at the end the first boolean is deleted. This triggers a chain deletion because the first shape deletes the shapes that is built on, without "noticing" that will make the mirrored boolean invalid, and makes both to be deleted. The logic is changed that deletion will work by the principle of garbage collector (we used previously this algorithm, and we have to cover the other test cases that will bring problems, mostly if you use shift+delete and the dialog that appears you will delete some shapes that are base for other shapes). The algorithm today will make impossible (or even possibly will crash) to remove those nodes. Anyway, this will be improved and if you will want to delete shapes that are referenced by other shapes, is easier just to delete the visible shapes, and all invisible shapes will disappear by themselves).
One another small fix is just that you cannot create a layer with the same name of an existing one. This will avoid confusion for you and make you use layers efficiently.
Plugin-ing UI (Part II)
All Ribbon was ported to new UI. Also the UI was fixed (some big icons in Solid group). This will mean that in future some other UI can be added/removed (for example if you want in future versions of NaroCAD to remove the View and Constrant tabs because you don't use them, you can go to: auto_plugin.naro and comment using # character (or remove) the line with: ViewInterfacePlugin
In future other parts will be moved to plugins (like: the logic of existing shapes) and I will improve documentation in this area also.
In future other parts will be moved to plugins (like: the logic of existing shapes) and I will improve documentation in this area also.
Tuesday, October 19, 2010
Plugin-ing UI
Two days ago I've reported that parts of UI can be generated. The idea was to define a hierarchical UI that the programmer can define any node in a tree as a generator node for child controls. For now the single wrapped part is the Ribbon's tabs UI. As for now it looks just like in screenshot.The cool part of this code is that is not only generated, but is setup as a part of an UI plugin. This simply means that at least in case of extending/changing NaroCAD UI regardless of underlying implementation. Also it is hierarchically, but also permit to inline your own UI objects (WPF/XAML defined).Shape editing handles
Implemented shape dragging handles for rectangle, circle, line and box.
Beside vertex dragging and side arrow dragging added also a handle in the center that allows the user to drag the shape.
Will continue with adding some translate Gizmo on these shapes.
One big usability problem still exists: if I click on the top face of the box (like in the screenshot above) top face is selected as drawing/sketching plane (also floating toolbar appears for this face) and the 3D mouse coordinates are generated on the top face. Because handles are on bottom face they can't be picked with the mouse points generated on top face, they only work when the user picks the bottom face. Will have to add some code where shapes like handles, datum geometry are detected anywhere in space not being related with the 3D mouse coordinates.
With the problem above our selection container has the following problems:
- due to OpenCascade local contexts opening closing for subshape selection makes some flickering effect,
- the same flickering effect appears for gradient background when local contexts are opened closed,
- Shape picking is made in 3D coordinates after the 2D mouse is projected on the 3D picked face.
It seems that we have to implement a smarter selection algorithm and if possible avoid Local Contexts or at least use them in a mode that doesn't affect the Neutral Point.
Beside vertex dragging and side arrow dragging added also a handle in the center that allows the user to drag the shape.
Will continue with adding some translate Gizmo on these shapes.
One big usability problem still exists: if I click on the top face of the box (like in the screenshot above) top face is selected as drawing/sketching plane (also floating toolbar appears for this face) and the 3D mouse coordinates are generated on the top face. Because handles are on bottom face they can't be picked with the mouse points generated on top face, they only work when the user picks the bottom face. Will have to add some code where shapes like handles, datum geometry are detected anywhere in space not being related with the 3D mouse coordinates.
With the problem above our selection container has the following problems:
- due to OpenCascade local contexts opening closing for subshape selection makes some flickering effect,
- the same flickering effect appears for gradient background when local contexts are opened closed,
- Shape picking is made in 3D coordinates after the 2D mouse is projected on the 3D picked face.
It seems that we have to implement a smarter selection algorithm and if possible avoid Local Contexts or at least use them in a mode that doesn't affect the Neutral Point.
Monday, October 18, 2010
Rectangle editing
Finally succeeded to make some working version of rectangle editing code. It's not finalized but it almost works, there's only one problem: the code started to look ugly. Will think how can this be simplified.
Made a video with current functionality status:
Made a video with current functionality status:
Generating Shapes Tab Dynamically
The prototype of generating tab dynamically is getting closer to finish. It can generate to a close resemblance to original ribbon tab but without being generated in designer. Also it permit to add other generated controls as much as it can add designer made controls. To register a specific control, it just have to define a path, and if wanted, to assign a factory (for dynamically generated controls) to that path, or full controls elsewhere.
Saturday, October 16, 2010
Gradient background problem
Added code to draw a gradient background. It looks good but encountered a problem: when opening a local context to select a subshape (like in the case of an extrude) something happens at the OpenCascade view level so that the displayed background color changes between gradient and background color creating a flickering effect. Will try to find an workaround for this issue.
Improved dragging hande
Searched a 3D mathematics solution to calculate the rotation matrix for a rotation between two coordinate systems used to display properly the dragging handles of a shape. Couldn't make it.
Almost succeeded to draw properly the dragging handles by using the following solution: for the case of rectangle the RectangleEditingClass calculates the position of each visual handle as an gp_Ax2, axis that holds location information but also axis direction information. Using this information at each mouse dragging the handling shape is redrawn in space according to gp_Ax2 information. Seems to work smoothly.
Next steps would be to make edge handlrs to work properly then start adding the translate Gizmo.
Almost succeeded to draw properly the dragging handles by using the following solution: for the case of rectangle the RectangleEditingClass calculates the position of each visual handle as an gp_Ax2, axis that holds location information but also axis direction information. Using this information at each mouse dragging the handling shape is redrawn in space according to gp_Ax2 information. Seems to work smoothly.
Next steps would be to make edge handlrs to work properly then start adding the translate Gizmo.
Thursday, October 14, 2010
Dragging handles
Made a few small steps toward implementing some gizmos. For the moment refactored the shape editing code so that it allows adding custom dragging handlers.
Made the shape editing work for several shapes. At line and rectangle improved the editing so that when dragging by the first shape handle is it changing the shape, previously it was moving the shape.
Drawn extra handles at shapes as triangle handler shapes. With these the problem is that the correct drawing is more complex because shapes are not symmetric so that for correct drawing they need to know the shape plane, the arrows should point "outside" the shape. Refactored all class infrastructure to use instead of 3D points information related to the location and normal to plane where they should operate on. Next step is to make shapes draw correctly relative to the edited shape.
Made the shape editing work for several shapes. At line and rectangle improved the editing so that when dragging by the first shape handle is it changing the shape, previously it was moving the shape.
Drawn extra handles at shapes as triangle handler shapes. With these the problem is that the correct drawing is more complex because shapes are not symmetric so that for correct drawing they need to know the shape plane, the arrows should point "outside" the shape. Refactored all class infrastructure to use instead of 3D points information related to the location and normal to plane where they should operate on. Next step is to make shapes draw correctly relative to the edited shape.
Tuesday, October 12, 2010
Fillet and Chamfer Size is Asked Before Creation
Title says it all, but before you will apply any of those tools will show to you a dialog to input your values. Is also great that this solves some of the problems because the default value may be too big for some shapes and make some tools to do nothing silently.
Some other fixes are still there.
Some other fixes are still there.
Monday, October 11, 2010
Locale fix
Fixed some problem we had when loading files made with one system locale on systems with other locale settings.
Modified the serialization and deserialization for interpreters, also fixed the property grid.
Now the default behavior is the following:
- the info is saved and loaded from file with CultureInfo.InvariantCulture,
- on the property grid the system locale is used. On US a decimal is like 12.38 on DE the decimal is 12,38.
Modified the serialization and deserialization for interpreters, also fixed the property grid.
Now the default behavior is the following:
- the info is saved and loaded from file with CultureInfo.InvariantCulture,
- on the property grid the system locale is used. On US a decimal is like 12.38 on DE the decimal is 12,38.
Sunday, October 10, 2010
Better Messages
When you will pick Pipe, Sew or other tools that work by selecting two shapes, you will get from command line the proper message to you to select the shape. There is also a bug in autogrouping (in polyline) that was mostly addressed but there is remaining a line that is created and creates extra complexity in algorithm and I did still not found what creates it, but I work on that.
In the meantime I will focus on plugin UI work which was stagnating as bug fixing was with bigger priority.
Update: polyline was fixed to work with as many lines without getting slower. The reason was that as the drawing goes some lines were drawn juxtraposed. This creates close to exponential combinations for auto-face algorithm searching.
In the meantime I will focus on plugin UI work which was stagnating as bug fixing was with bigger priority.
Update: polyline was fixed to work with as many lines without getting slower. The reason was that as the drawing goes some lines were drawn juxtraposed. This creates close to exponential combinations for auto-face algorithm searching.
Friday, October 8, 2010
Small Interface Tweak
Excluding bug fixing, today a new tweak will ask when you close the NaroCAD window about if you want to save your work.
Wednesday, October 6, 2010
Bug cleanup
Started looking at the reported bugs by closing the fixed bugs to see how stable the application is. Closed 7 bugs but found 7 new bugs.
Remained to fix 83 bugs open from which 29 critical.
Remained to fix 83 bugs open from which 29 critical.
Bug Fixing in Multiple Areas
In the last two days I've worked intensively on bug fixing.
Layers code did expose a problem of performance: the updating of layers visibility affected that some shapes (almost all scene, but they were affected all shapes that do have layer information attached) need to be (re)generated. As if you draw complex shapes (like boolean operations), they simply make NaroCAD to get slower and slower.
This problem was fixed, also some extra code that was running at switching actions was also moved. This exposed some other problems that were in code (like in a lot of cases that were involved overriding virtual methods, they don't call the base class methods, even those base class methods have some virtual classes).
Cut shape was also fixed in cases that selection was done from tree.
A small double delete key pressing leading to crash was also fixed.
Dimension on lines work as Dimension was restricted to work on shapes that do work with Dimension and for some reasons Line was not in them.
The last area that get some fixes was the arcs code that had some cases that do not work, and was fixed.
Layers code did expose a problem of performance: the updating of layers visibility affected that some shapes (almost all scene, but they were affected all shapes that do have layer information attached) need to be (re)generated. As if you draw complex shapes (like boolean operations), they simply make NaroCAD to get slower and slower.
This problem was fixed, also some extra code that was running at switching actions was also moved. This exposed some other problems that were in code (like in a lot of cases that were involved overriding virtual methods, they don't call the base class methods, even those base class methods have some virtual classes).
Cut shape was also fixed in cases that selection was done from tree.
A small double delete key pressing leading to crash was also fixed.
Dimension on lines work as Dimension was restricted to work on shapes that do work with Dimension and for some reasons Line was not in them.
The last area that get some fixes was the arcs code that had some cases that do not work, and was fixed.
Tuesday, October 5, 2010
Wrappers minor update
Added a small update at the wrappers that Naro uses. The Transient objects have a new method named IsSameTransient, method that returns true if two objects have the same underlying native Handle classes.
This new feature will be used in Naro to detect clicks on shapes from scene that have no underlying geometry (like Dimensions, Gizmos, Editing handles).
Kudos to our contributor Guido for this idea.
This new feature will be used in Naro to detect clicks on shapes from scene that have no underlying geometry (like Dimensions, Gizmos, Editing handles).
Kudos to our contributor Guido for this idea.
NaroCAD Options
NaroCAD options are back and alive :D. I've managed to fix all the problems(I think!) on the options dialog. Also I've made a nightly build with those changes.
Wednesday, September 29, 2010
Sewing, Spain's General Strike and Plugin Progress
There is a sewing option (in the same menu with pipe). Sewing will build one shape from incident faces. Anyway, the faces individually do not make a bigger face, to say as such, so it does not solve if you want to extrude more faces at once, but if you want to scale more faces uniformly, sewing may be a solution (this happen in the way that OpenCascade handles sewing).
A big interruption for me in those days was Spain's General Strike. Amazingly, things work randomly, but the hardest part was transportation issues, some violence here and there (I donot participate to those acts, but I'm still wondering). This strike was mostly bombarding media in all directions and at least regarding Madrid, the vandalism I found was really pointless.
I was working reviewing how I can handle the UI to be extensible. The single problem is that the solution I thought may duplicate most of the UI code and will render Xaml coding useless (as all Xaml code can be rewritten in C#) so I'm not sure if this is really the solution. Even it will be in this way, I will most likely have to make it hierarchically (like a folder path, where people adds things under: Ribbon/Shapes/Tools/Sewing) and per path node should be defined a factory creator. Anyway I will think more about it, and if I will be blocked I will likely get to look to other area for now.
A big interruption for me in those days was Spain's General Strike. Amazingly, things work randomly, but the hardest part was transportation issues, some violence here and there (I donot participate to those acts, but I'm still wondering). This strike was mostly bombarding media in all directions and at least regarding Madrid, the vandalism I found was really pointless.
I was working reviewing how I can handle the UI to be extensible. The single problem is that the solution I thought may duplicate most of the UI code and will render Xaml coding useless (as all Xaml code can be rewritten in C#) so I'm not sure if this is really the solution. Even it will be in this way, I will most likely have to make it hierarchically (like a folder path, where people adds things under: Ribbon/Shapes/Tools/Sewing) and per path node should be defined a factory creator. Anyway I will think more about it, and if I will be blocked I will likely get to look to other area for now.
Sunday, September 26, 2010
Options Fixed, Layer minimization
Options Dialog was fixed by hardcoding the layout with other values. Information on layers was minimized to be more compact (not in two rows but just in one)..
Options Dialog change
Options Dialog have right now Windows style of Options (means OK, Cancel & Apply). There are some layout problems and this is the reason that there is no screenshot attached.
Thursday, September 23, 2010
AvalonDock Up-To-Date
For drag&dropping and setting dock-able panels we use AvalonDock and the code was made in sync the last version of AvalonDock. For now the themes are not compatible so they need to be updated to look again shiny but this will be fixed soon.
I was reviewing the docking code too and soon the external component code will be able to add dockable content without creating by itself the dockable components, but just the control that wants to be docked.
A good to have feature is to save the docking configuration but so far I've did not found (I've did not look that deeply though) a solution.
Wednesday, September 22, 2010
Improved Options Notification
NaroCAD uses the setting setup similar with Mac OS X/GNOME applications, meaning that the settings apply automatically. To make this happen, we use a mechanism that options are written in a NaroCAD document, and when a setup option will change, a notification is sent and all listeners.
This design is fairly inefficient as if for example you change a setting that will adjust the solver sensibility, as side effects, the all options reapply, like but not limited to: update tree view, resetup the color of background shapes, and so on.
Right now to be sure that the old code is not changed, the global notification still exist, but I've made that at least for solver, tree view and OpenCascade parts, they will not listen to global notification, but to the "solver section" ones which corresponds specifically when you change punctually the corresponding pages.
The main benefit will be that options in general will be far more responsive and you will see the applying of options regardless of the size of the future options dialog that they will not get slower and slower.
A small change is that right now there is an Zoom speed option to adjust nicely to your flows. More advanced options may follow later, but if you wanted to do precise drawing, you were out of luck in your previous work.
This design is fairly inefficient as if for example you change a setting that will adjust the solver sensibility, as side effects, the all options reapply, like but not limited to: update tree view, resetup the color of background shapes, and so on.
Right now to be sure that the old code is not changed, the global notification still exist, but I've made that at least for solver, tree view and OpenCascade parts, they will not listen to global notification, but to the "solver section" ones which corresponds specifically when you change punctually the corresponding pages.
The main benefit will be that options in general will be far more responsive and you will see the applying of options regardless of the size of the future options dialog that they will not get slower and slower.
A small change is that right now there is an Zoom speed option to adjust nicely to your flows. More advanced options may follow later, but if you wanted to do precise drawing, you were out of luck in your previous work.
Tuesday, September 21, 2010
Layers, Layers, Layers
Layer work is mostly done (it may needs some testing and fixes of problems found). Right now have another view that you can setup your layers and for every shape you have the option to pick the layer by name. In the LayerView you will be able to manage layers, to override the scene colors if you want to pick by layer profile.Some nice tricks are in this dialog like: every time you pick Add Layer, a random color is generated, another part is that Remove button will be disabled for current layer, and so on.
So you may try this functionality via nightly build.
P.S. The color theme is on my machine, so don't feel attacked for it :)
NaroCAD website
We remind you of our website www.narocad.com. There you can find a forum where you can post messages about all the problems, suggestions, ideas or whatever you have in mind about NaroCAD.There you can find also tutorials, documentation, screenshots and others.
Saturday, September 18, 2010
Layers Prototype
Layers will work in a more conventional way than tags.The interface have still some way to go but the layers will have a selected layer, the current layer you draw on, the layer color, that you may pick if you want to override the shape color for visualization and of course you can hide/show.
Also this prototype will be more polished, but the reason is shown is just to see what is it about.
Add/Remove buttons will be likely down, and Add button will show a dialog where you can set the name and color.
How you define custom colors: every time is picked a random color
See more in the the next nighties for issues and how things will work.
Thursday, September 16, 2010
NaroCAD 1.5.1 Released
NaroCAD did improve on bottom line greatly and it is as its code goes the most stable and hopefully a great foundation for future improvements. Quality of the principal emphasis on this build and it was seen as following:
- New testing framework: testing of NaroCAD can be done with low level tests (NUnit unit tests), with visual low level tests, scripting tests that can be launched inside NaroCAD
- Many fixes and code refactoring: the internal relations between components were greatly improved. In many ways things give less dependencies and a shorter, more concise code. This will likely positively impact not only in this release, but also in future release cases when a break of a component will break another components. Also most of NaroCAD's logic can be setup out of NaroCAD's internal assemblies and future work will be to be extended as plugins
- New tool was added: mirror plane but also were fixed selection bugs in previous mirror tools
- Lua replaced with Boo: why not to take advantage of a powerful .NET language? You will get syntax highlighting, live compilation, you can even activate your automation scripting to make complex shapes and to import your custom assemblies
- Improved unit tests: we are covering all basic shape creation and action switching making that NaroCAD will not crash. Anytime the nightly time is running, tests are running and we can see if break something. As the battery of tests will grow, the crash/wrong behavior cases will be out of NaroCAD.
- Reimplemented selection container: this will mean that floating toolbar will get extra information to take in account the face you are on and will give the correct information any time. This will solve a lot of bugs in this area.
- Improved drawing on scene, visual feedback: faces are highlighted with a dark line to be more visible
- Fixed editing on shapes: as it was broken for some time. This is also combined with new selection container, will give less problems to work with. The code was separated and will make possible to add arbitrary tools in the same editing framework.
Download it from here.
- New testing framework: testing of NaroCAD can be done with low level tests (NUnit unit tests), with visual low level tests, scripting tests that can be launched inside NaroCAD
- Many fixes and code refactoring: the internal relations between components were greatly improved. In many ways things give less dependencies and a shorter, more concise code. This will likely positively impact not only in this release, but also in future release cases when a break of a component will break another components. Also most of NaroCAD's logic can be setup out of NaroCAD's internal assemblies and future work will be to be extended as plugins
- New tool was added: mirror plane but also were fixed selection bugs in previous mirror tools
- Lua replaced with Boo: why not to take advantage of a powerful .NET language? You will get syntax highlighting, live compilation, you can even activate your automation scripting to make complex shapes and to import your custom assemblies
- Improved unit tests: we are covering all basic shape creation and action switching making that NaroCAD will not crash. Anytime the nightly time is running, tests are running and we can see if break something. As the battery of tests will grow, the crash/wrong behavior cases will be out of NaroCAD.
- Reimplemented selection container: this will mean that floating toolbar will get extra information to take in account the face you are on and will give the correct information any time. This will solve a lot of bugs in this area.
- Improved drawing on scene, visual feedback: faces are highlighted with a dark line to be more visible
- Fixed editing on shapes: as it was broken for some time. This is also combined with new selection container, will give less problems to work with. The code was separated and will make possible to add arbitrary tools in the same editing framework.
Download it from here.
Wednesday, September 15, 2010
Added Boo View, Simpler Handling Code
Boo was added as default scripting engine in NaroCAD. It have equivalent features with Lua but it should be easier to use and as you have "live compiler", you will unlikely get very late errors when you run your code, but when you write it down. The testing suite scripts and some simple actions scripts are posted as samples. The action scripts may change in future, but most likely the script one, no.
As actions code goes, they have to consume data that the required input and pipes provides. Previously this consumption code was made with a big switch statement. Right now you have the possibility to write the inputs you want to handle and a handling function. This cleans up the code, but you can still override and make your custom handling. This custom handling can be used I think in cases with logging and at least for cases when code is not ported to the new way of cleaner code. On a similar note, the notification code have the same capabilities.
As actions code goes, they have to consume data that the required input and pipes provides. Previously this consumption code was made with a big switch statement. Right now you have the possibility to write the inputs you want to handle and a handling function. This cleans up the code, but you can still override and make your custom handling. This custom handling can be used I think in cases with logging and at least for cases when code is not ported to the new way of cleaner code. On a similar note, the notification code have the same capabilities.
Selection bug fixing
Finalized a first version of selection container located into a selection pipe component that works smoothly and doesn't give the flickering effect that appeared in the past. It seems to work well with tools that need to pick a solid or face. It also works well at detecting the face under mouse when a solid is clicked - this makes the floating toolbar populated properly and the tools from floating are completed correctly.
Ciplogic isolated the command line code by making it a container component.
Having all these refactorings and also the Boo changes Naro seems quite stable.
Will continue from now with bug fixing. Among the highest priority bugs that we'll solve these days: Shift select seems to not work properly in all situations, edge select for tools like Fillet3D not working yet, some shapes are disappearing and appearing back on scene.
Ciplogic isolated the command line code by making it a container component.
Having all these refactorings and also the Boo changes Naro seems quite stable.
Will continue from now with bug fixing. Among the highest priority bugs that we'll solve these days: Shift select seems to not work properly in all situations, edge select for tools like Fillet3D not working yet, some shapes are disappearing and appearing back on scene.
Component diagrams
Last few days worked at reviewing, separating and improving the Naro components implemented as pipes.
After filling half of a notebook with schemes and drawings decided to use OpenOffice Draw application to share the schemes with other developers of Naro. From now at all architecture related tasks will make drawings and upload them on SVN.
The Diagrams folder from SVN.
The Command Line Diagram from SVN.
After filling half of a notebook with schemes and drawings decided to use OpenOffice Draw application to share the schemes with other developers of Naro. From now at all architecture related tasks will make drawings and upload them on SVN.
The Diagrams folder from SVN.
The Command Line Diagram from SVN.
Tuesday, September 14, 2010
Visual Studio License Quirks
This is not necessarily related with NaroCAD but will help me to work with it. The reason may be explained in following lines.
As I've liked (and I still do, at least conceptually) the Delphi language (as an OOP Pascal dialect), I've bought a 1 year subscription license of Oxygene language, which is a .NET version of Delphi language. As the project was bought (relicensed) by Embarcadero, it gave to me a full Delphi Prism (first version) Edition which brings to me a VS Professional version setup just with Oxygene (now Delphi Prism) language.
Why this will helps me? As the dust was set, I just wanted to install it to make some toy coding. And I've discovered that my IDE which was just VS Standard edition, did achieve some Pro features, mostly the WPF/Xaml visual editing. As at that time the subscription of Oxygene costs me somelike 300 euros, and when I've bought the VS Standard with around the same price, it costs me much less than a VS Pro 2008 version which would cost me like 800 euros. In this money anyway I've bought a great tool (Resharper) which improves code quality by lively show code issues (which right now seem to be mostly from imported external components).
When NaroCAD will use VS 2010, and to not depend on SharpDevelop, I may have to look to other very limited Pro or Architect editions that will enable other low cost versions :)
As I've liked (and I still do, at least conceptually) the Delphi language (as an OOP Pascal dialect), I've bought a 1 year subscription license of Oxygene language, which is a .NET version of Delphi language. As the project was bought (relicensed) by Embarcadero, it gave to me a full Delphi Prism (first version) Edition which brings to me a VS Professional version setup just with Oxygene (now Delphi Prism) language.
Why this will helps me? As the dust was set, I just wanted to install it to make some toy coding. And I've discovered that my IDE which was just VS Standard edition, did achieve some Pro features, mostly the WPF/Xaml visual editing. As at that time the subscription of Oxygene costs me somelike 300 euros, and when I've bought the VS Standard with around the same price, it costs me much less than a VS Pro 2008 version which would cost me like 800 euros. In this money anyway I've bought a great tool (Resharper) which improves code quality by lively show code issues (which right now seem to be mostly from imported external components).
When NaroCAD will use VS 2010, and to not depend on SharpDevelop, I may have to look to other very limited Pro or Architect editions that will enable other low cost versions :)
Subscribe to:
Posts (Atom)
