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.
Sunday, October 31, 2010
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.
Subscribe to:
Posts (Atom)