Sunday, January 31, 2010
Command Line Parser
Command Line action evolves (slowly) but it still progress. I hope that soon some useful work will be seen very soon. In the meantime some progress was done on Extrude action by bxtrx. As those actions will work, they will be able to make more context sensitive actions to work in states.
Thursday, January 28, 2010
Rectangle with states
After reviewing the state pattern implementation from Naro made the first step toward making the tools interactive with command line: replaced the Rectangle tool with its equivalent code implemented using states and the tool works well. The states implementation enables the tools to receive input from command line and mouse.
When the command line parser will be finished it will be integrated with the tool so that coordinates can be send also from command line. The rectangle tool implemented with states works in the same time with the other tools not supporting states.
Will continue with looking at the Extrude tool to see how this can be implemented with states as its dependencies and requirements are very different from Rectangle.
When the command line parser will be finished it will be integrated with the tool so that coordinates can be send also from command line. The rectangle tool implemented with states works in the same time with the other tools not supporting states.
Will continue with looking at the Extrude tool to see how this can be implemented with states as its dependencies and requirements are very different from Rectangle.
Tuesday, January 26, 2010
Command Line Action status
The command line work is ongoing but it took some time but I did tried to advance in a way that right now I tried to create unit tests for commands.
Some bad cases that I need to address are cases like: one user paste a command like: left() and right after paste line(20, 30, | and the command line parser should cancel completely the latest command and switch to line. Also the line should need to be able to use relative coordinates. The right design is the problem.
For a straight command line, the actual design can cope easy with incremental coordinates or to input the values for coordinates from more shapes.
Also the command line do not know how to handle cases like: Axis 3D (which in OpenCascade meaning are just two points) or other shapes. I will have to think to a case. Probably a solution like: shape(shapeName) from NaroCAD's exposed Lua scripting may be appropriate for those cases.
Tomorrow I will be in a plane trip to see Vienna (Wien) Austria so probably a refreshing cold air will make me to have a better mind setup.
Some bad cases that I need to address are cases like: one user paste a command like: left() and right after paste line(20, 30, | and the command line parser should cancel completely the latest command and switch to line. Also the line should need to be able to use relative coordinates. The right design is the problem.
For a straight command line, the actual design can cope easy with incremental coordinates or to input the values for coordinates from more shapes.
Also the command line do not know how to handle cases like: Axis 3D (which in OpenCascade meaning are just two points) or other shapes. I will have to think to a case. Probably a solution like: shape(shapeName) from NaroCAD's exposed Lua scripting may be appropriate for those cases.
Tomorrow I will be in a plane trip to see Vienna (Wien) Austria so probably a refreshing cold air will make me to have a better mind setup.
New WPG GUI
Interactive command line
On this week the team started working at implementing an interactive command line that allows receiving inputs from mouse or written from keyboard. Finished the first step of implementing the feature: the Lua scripting window was moved into a new window implemented with WPF. The command line was ported to WPF and will integrate into this the functionality to write commands with auto complete and hints (this functionality is also almost finished). When this will be finished the next step will be to implement a tool with State pattern so that it can receive inputs from mouse or command line.
NaroCAD has now also a theme library in the project where the gradients and GUI elements are specified. This will allow us to easily change the interface design.
The new Lua scripting window and command line:
NaroCAD has now also a theme library in the project where the gradients and GUI elements are specified. This will allow us to easily change the interface design.
The new Lua scripting window and command line:
Friday, January 22, 2010
Interactive command line
From next week will start implementing tools with states and make the command line to be interactive. By the end of next week planned to have a complete interactive command line working for one tool and the other week planning to port all tools to the state implementation. In order to complete the next week's functionality, identified the following tasks:
Review the current State code implementation,
Move Lua into a separate Tab,
Implement a WPF control for command line,
Implement the command line control, parser and hint display,
Implement Extrude tool with State,
Implement a complete prototype tool working fully with interactive command line and mouse clicks by putting together all the above.
Review the current State code implementation,
Move Lua into a separate Tab,
Implement a WPF control for command line,
Implement the command line control, parser and hint display,
Implement Extrude tool with State,
Implement a complete prototype tool working fully with interactive command line and mouse clicks by putting together all the above.
Thursday, January 21, 2010
NaroCAD 1.3RC
Made NaroCAD1.3RC version. It can be downloaded from here.
Fixed around 20 bugs at the beta version among which:
- Undo Redo bugs on Cut and Extrude were fixed,
- fixed Revolve and Pipe tools,
- fixed some WPF on XP bugs,
- fixed Fillet tools,
- fixed some reported crashes,
- the Translation fields enabled in Property Grid,
- fixed some open save issues.
Fixed around 20 bugs at the beta version among which:
- Undo Redo bugs on Cut and Extrude were fixed,
- fixed Revolve and Pipe tools,
- fixed some WPF on XP bugs,
- fixed Fillet tools,
- fixed some reported crashes,
- the Translation fields enabled in Property Grid,
- fixed some open save issues.
Tuesday, January 19, 2010
Bug fixing
Started bug fixing. Until now fixed bugs related to Pipe, Revolve, Mirror tools. Refactored these tools to be derived from a common code so that currently the code for these tools is under 10 lines of code. Probably this code refactoring will be useful next week when we will change the modifiers to work with states and integrate with command line.
Currently 44 more open bugs to fix.
Currently 44 more open bugs to fix.
Monday, January 18, 2010
The new mapping and fixes
One of the latest changes that was done was that now in NaroXML files are stored plain .Net type names and are solved by .NET reflection instead an alias picked for that. This change makes that two bugs (crashes) may affect you and they are: File->New (the equivalent Ribbon operation) will fail and the Undo/Redo will not apply the transforms. Those are side-effects of this change.
Because NaroXML in some degree worked with internal form of NaroCAD storage, this change will make that in future adding custom attributes will be less prone of errors, there is added a button that do a fuzzy logic to generate a lua half-made script based on document structure. Why is useful? If you will have that Lua scripts you can generate fairly complex changes that contains all shapes you created on (or mostly) and with generated coordinates.
If you tried rendering operations and you had issues because some of that interface do not warn you if you have nothing selected, and if you don't pick one shader for example, you will get an error in command line and you cannot guess so easily the source of that error, the interface regarding that area is much more fixed (like picking a default when are shaders available, etc.).
A nightly build can be taken from here.
Because NaroXML in some degree worked with internal form of NaroCAD storage, this change will make that in future adding custom attributes will be less prone of errors, there is added a button that do a fuzzy logic to generate a lua half-made script based on document structure. Why is useful? If you will have that Lua scripts you can generate fairly complex changes that contains all shapes you created on (or mostly) and with generated coordinates.
If you tried rendering operations and you had issues because some of that interface do not warn you if you have nothing selected, and if you don't pick one shader for example, you will get an error in command line and you cannot guess so easily the source of that error, the interface regarding that area is much more fixed (like picking a default when are shaders available, etc.).
A nightly build can be taken from here.
Saturday, January 16, 2010
NaroCAD 1.3 Beta Released
NaroCAD gets a lot of changes in the last month that you will love!
Sneak peek of this release:
So you are encouraged to use this new release that is uploaded under Sourceforge and to give any feedback.
Sneak peek of this release:
- Ribbon UI is a great step forward as it gives simpler UI and separated by logic and purpose. So you have three tabs that are catogorized as Home, Shapes and View.
- The interface was complete rewrite to use Windows Presentation Foundation. This means that the interface is scalable, with good animation speed that theoretically was not (that easy) to be done in the old interface. Also the interface will use more of .NET 3.5SP1, which was the latest runtime that was used by NaroCAD. So you will get more capabilities, updated look&feel, to not look like Office 97, but like Office 2007.
- Experimental rendering system that makes to you to create high quality pictures of the shapes you create.
So you are encouraged to use this new release that is uploaded under Sourceforge and to give any feedback.
Preparing for release
Finished porting and verifying all tools from the previous application to the new WPF GUI. Added also more detailed tool tips that explain how the tool should be used.
Made a fix that solves the flickering problems that appears on Windows XP at the OpenCascade OpenGL rendering control hosted on WPF. For this used the tips found here.
Added also tools to the bottom of the window from the status bar. Put there the most used tools for manipulating the view. They can be also found on the View Ribbon Tab.
The current version of application looks like a good candidate for a beta version release.
Made a fix that solves the flickering problems that appears on Windows XP at the OpenCascade OpenGL rendering control hosted on WPF. For this used the tips found here.
Added also tools to the bottom of the window from the status bar. Put there the most used tools for manipulating the view. They can be also found on the View Ribbon Tab.
The current version of application looks like a good candidate for a beta version release.
Friday, January 15, 2010
View tab on updates and installer fixes
WPF's Ribbon gets filled with all(most everything) of NaroCAD functionality of Windows.Forms. The installer was updated to get new changes in the last weeks and was fixed with the new issues found. Tomorrow most probably will be released a preview WPF version that includes the Ribbon UI, the renderer fixes and we may like to give it a try.
Thursday, January 14, 2010
WPF Progress
Progressed a lot on the Ribbon GUI interface. Connected the events for around 40 tools, covering all the drawing tools plus the ones from the quickstart zone like undo, redo, save open. On the bottom made a status bar where the most used tools will be put. The drawing tools work well, the same like they were working on the previous interface, not affected by the porting.
Remained also to finish the status bar, the View tab drawing and event wiring for these. On the View tab will put the pan, zoom like tools. There are also more complicated problems that remained to be solved like flickering.
A NaroCAD screenshot on XP:
Remained also to finish the status bar, the View tab drawing and event wiring for these. On the View tab will put the pan, zoom like tools. There are also more complicated problems that remained to be solved like flickering.
A NaroCAD screenshot on XP:
Wednesday, January 13, 2010
How Java was removed as dependency
As the last days I worked on the WPF integration I wanted to present a technological aspect that may be interested for some.
Rendering operation have some usages and advantages but the biggest problem in itself is that is no small rendering system out-there that is fairly decent and full-featured with a small runtime. So NaroCAD was somehow catched in a trap of having either to download a full blown renderer (like Povray) or to download other that have dependencies to Python or to Java. Cause of popularity of runtimes, the Java based renderer Sunflow was chosen (and easy integration to create polygon renders).
This Sunday I found a solution that do not depend on Java runtime. The solution was to provide with NaroCAD a Java virtual machine based on .NET (IKVM) which add to the install size around 25% of size (so the full package will grow from 19 to around 23M). The greatest part is not only that simplify the setup for user (why user should setup a Java virtual machine and to install it if does not exist on the final machine) as probably no user will do a more than two steps setup.
Studying more the IKVM project, I found that it can convert the Java bytecode (the .jar package) to a MSIL files (.exe .NET files) so sunflow.jar is right now as sunflow.exe. It have a lot of other advantages for user. like if you have installed Vista (or newer) OS (or XP with .NET 3.5 SP1 installed separately) you can run renderer and NaroCAD without any external runtime. So the single external runtimes that NaroCAD depends (OpenCascade, Lua and now IKVM .NET dlls) are bundled in the installer.
Rendering operation have some usages and advantages but the biggest problem in itself is that is no small rendering system out-there that is fairly decent and full-featured with a small runtime. So NaroCAD was somehow catched in a trap of having either to download a full blown renderer (like Povray) or to download other that have dependencies to Python or to Java. Cause of popularity of runtimes, the Java based renderer Sunflow was chosen (and easy integration to create polygon renders).
This Sunday I found a solution that do not depend on Java runtime. The solution was to provide with NaroCAD a Java virtual machine based on .NET (IKVM) which add to the install size around 25% of size (so the full package will grow from 19 to around 23M). The greatest part is not only that simplify the setup for user (why user should setup a Java virtual machine and to install it if does not exist on the final machine) as probably no user will do a more than two steps setup.
Studying more the IKVM project, I found that it can convert the Java bytecode (the .jar package) to a MSIL files (.exe .NET files) so sunflow.jar is right now as sunflow.exe. It have a lot of other advantages for user. like if you have installed Vista (or newer) OS (or XP with .NET 3.5 SP1 installed separately) you can run renderer and NaroCAD without any external runtime. So the single external runtimes that NaroCAD depends (OpenCascade, Lua and now IKVM .NET dlls) are bundled in the installer.
Tuesday, January 12, 2010
WPF Commands
Finished implementing the ToolbarService that allows any module at loading to register its own ribbon tabs. All modules will define their tabs and will also catch the commands from their own registered tab.
Added at the Modeling module code that inserts a RibbonTab at loading. Here encountered problems that tabs from a designed Ribbon can't be taken and registered to the main Ribbon, had to define tabs in XAML as independent components.
Will continue working at connecting the buttons from tabs to launch SCSF commands in the modules. Probably will create a CommandService to make command connecting task easier and simpler for the developers.
A screenshot with the latest GUI improved by my colleagues:
Added at the Modeling module code that inserts a RibbonTab at loading. Here encountered problems that tabs from a designed Ribbon can't be taken and registered to the main Ribbon, had to define tabs in XAML as independent components.
Will continue working at connecting the buttons from tabs to launch SCSF commands in the modules. Probably will create a CommandService to make command connecting task easier and simpler for the developers.
A screenshot with the latest GUI improved by my colleagues:
Monday, January 11, 2010
WPF fixes
WPF gets closer with work driven by bxtrx and I did contribute some fixes too. Today I've work on debugging the TreeView update which seems to happen, but no update in context. I did reduce to a small spot the code.
So the title is fixed, the splash is starting. And the work is ongoing.
So the title is fixed, the splash is starting. And the work is ongoing.
WPF events
Enabled processing of the mouse events generated from the OpenCascade control in the WPF application. Solved some of the problems, it still remained to solve some flickering and redrawing problems. The whole team focused on integrating WPF, working now at populating the icons in the toolbar and connecting them with the commands. Planning for tomorrow evening to finish adding tools and start testing/fixing. Will have also to activate the options dialog and integration with the NaroStarter application that catches errors during usage.
The latest GUI version with an office 2007 black skin:
The latest GUI version with an office 2007 black skin:
Saturday, January 9, 2010
WPF GUI first run
Succeeded to launch the WPF application hosting the controls that Naro had on WindowsForms. It still looks strange also doesn't behave as it should behave but looks good for the first application run. The OpenCascade view doesn't respond yet to mouse events but the Property Grid and Tree View work well, an object selected in the tree is also selected in the scene.
Will continue working at connecting the mouse events and also the toolbar events.
Will continue working at connecting the mouse events and also the toolbar events.
Rendering last fixes
Do you remember the rendering capability of Naro? It is based on Sunflow Global Illmination System. This makes to not add as much to installer and require a portable (Java) implementation. For performance sensitive persons, you will need to install JDK (that include the "server" implementation, meaning that the run-time of Java will create multiple optimizations) and I recommend Java 7 pre-release versions that also will bring some performance improvements and at least on my machine it worked stable.
Sunflow is somehow easy to work with, but it prove that our implementation have bugs like retrieving the FOV (the camera angle), also, there was no clear result how it works.
You will have to setup in Tools/Options where is your java.exe executable. Also is recommended to use -server option (if you have installed the JDK on Windows).
After some research I found that there is a PerspectiveView class in OpenCascade that expose the angle in a proper way. Also, I found that based on user's locale installation (for example on Windows in Spanish, the floating point separator is not . (point) but , (comma) ) the script will not be a good result for the Sunflow render. Also there was a bug in lighting and depends on scene orientation and camera, was impossible to get it why the piece appear or not, because the screen was plain black. Some annoyances still remain (like you can setup a single material per scene shapes), but a lot of fixes are done. Also, a preview in the rendering dialog will give to you a measure how things works. Before generating rendering script, there is a triangulation step, but because it generates twice the points, the search algorithm is inefficient of searching duplicate points, so you may encounter a freeze between pressing render and effective rendering. Anyway, it will not take as long as the full rendering anyway.
The scene is an imported STEP file from here.
The build with fixes (also it includes some small fixes that were done from the last weeks) may be taken from here. This will be probably the last Windows.Forms build (with a non Ribbon interface) so if you will not want yet to switch to Ribbon, and you like the Office-97 like UI that Naro have right now, take this build.
Sunflow is somehow easy to work with, but it prove that our implementation have bugs like retrieving the FOV (the camera angle), also, there was no clear result how it works.
You will have to setup in Tools/Options where is your java.exe executable. Also is recommended to use -server option (if you have installed the JDK on Windows).
After some research I found that there is a PerspectiveView class in OpenCascade that expose the angle in a proper way. Also, I found that based on user's locale installation (for example on Windows in Spanish, the floating point separator is not . (point) but , (comma) ) the script will not be a good result for the Sunflow render. Also there was a bug in lighting and depends on scene orientation and camera, was impossible to get it why the piece appear or not, because the screen was plain black. Some annoyances still remain (like you can setup a single material per scene shapes), but a lot of fixes are done. Also, a preview in the rendering dialog will give to you a measure how things works. Before generating rendering script, there is a triangulation step, but because it generates twice the points, the search algorithm is inefficient of searching duplicate points, so you may encounter a freeze between pressing render and effective rendering. Anyway, it will not take as long as the full rendering anyway.
The scene is an imported STEP file from here.
The build with fixes (also it includes some small fixes that were done from the last weeks) may be taken from here. This will be probably the last Windows.Forms build (with a non Ribbon interface) so if you will not want yet to switch to Ribbon, and you like the Office-97 like UI that Naro have right now, take this build.
Friday, January 8, 2010
WPF
Succeeded to finish the first stage of implementing the WPF GUI with SCSF: implemeted an AppShell application window that holds a DeckWorkspace. On this workspace each module will load its own layout. Modified the Part Modeling module (the one used for modeling shapes) to load its layout on the main Shell layout consisting on a Property Grid, a Tree View, a Command Line and a Rendering Scene. When other modules will be implemented like an Assembly Modeling module, a Technical Drawing module or a CNC module, each module will define and load its own layout on the main workspace.
Will continue at Part Modeling module to wire the events, add code so that the module populates the menu and the toolbar and also port previous functionality.
Will continue at Part Modeling module to wire the events, add code so that the module populates the menu and the toolbar and also port previous functionality.
Wednesday, January 6, 2010
Bugs, fixes, bugs, fixes
When I worked to WPF treeview, I found that Ribbon is a love relation for AutoCAD users. I've worked and tried to craft a WPF tree code. The code is not that big but differs functionally and I didn't fixed yet the issues. Also, SharpDevelop, my IDE of choice when I add an WPF project, will update the NaroCAD solution to 11.0 (meaning the same with Visual Studio 2010 which is not desirable) so I did had to work on a separate solution.
I really hope tat I will make an equivalent implementation of treeview using WPF. The biggest difference is that WPF do separate the code that was stored completely in tree, as a Model/View/Controller implementation and I need to write a model that do filtering and link events all together. The great part is that the implementation will make things much faster also. so I hope that are great news around.
I really hope tat I will make an equivalent implementation of treeview using WPF. The biggest difference is that WPF do separate the code that was stored completely in tree, as a Model/View/Controller implementation and I need to write a model that do filtering and link events all together. The great part is that the implementation will make things much faster also. so I hope that are great news around.
Sunday, January 3, 2010
Capabilities skeleton code
As there is a work for migrating to WPF interface, I've tried to make better the migration. I've found a bit of disappointment that there is no property grid implementation (that works) that is free excluding the Windows.Forms implementation that is already used by NaroCAD. There is a TreeView with WPF, but if I will migrate the code of TreeView, I will need to migrate also search (filtering). Because I was not sure if and what to do exactly (I will ask some advices to bxtrx), I've made a capability framework for now.
What is it about? Is much less that the name pretends but can have nice usages like: right click or to set a custom icon in treeview, or populate nicely the sections in property grid.
So how should work: it works like a dictionary that you say for an object in dictionary if is related with other object and which attributes does it have. This dictionary will test the attributes if they exist regardless of they are in the object itself or in any object related to. By this, if you will want to create an object, like Sphere, you can say that is a shape, is a solid, have no plane faces. By this the Property Grid will be able to show (if the code will be moved in the capabilities frame) the Shape properties (like Transform), the right click can show: boolean operations, but will not show the Extrude because have no plane face.
That is all about. Hope that the concept to work and to improve in the next day and to work along with the WPF integration.
What is it about? Is much less that the name pretends but can have nice usages like: right click or to set a custom icon in treeview, or populate nicely the sections in property grid.
So how should work: it works like a dictionary that you say for an object in dictionary if is related with other object and which attributes does it have. This dictionary will test the attributes if they exist regardless of they are in the object itself or in any object related to. By this, if you will want to create an object, like Sphere, you can say that is a shape, is a solid, have no plane faces. By this the Property Grid will be able to show (if the code will be moved in the capabilities frame) the Shape properties (like Transform), the right click can show: boolean operations, but will not show the Extrude because have no plane face.
That is all about. Hope that the concept to work and to improve in the next day and to work along with the WPF integration.
Saturday, January 2, 2010
Happy New Year 2010
I know that is a bit late, and there are many things to wish to this year.
Of course the 2010 moniker will make us to hope that things will be better this year than the last year, that we will have things to enjoy.
I really hope that year after year us to enjoy in everything what we do and to succeed in all things that we purpose for this time!
Happy New Year once again!
Of course the 2010 moniker will make us to hope that things will be better this year than the last year, that we will have things to enjoy.
I really hope that year after year us to enjoy in everything what we do and to succeed in all things that we purpose for this time!
Happy New Year once again!
Subscribe to:
Posts (Atom)