I do agree that persons are not well educated and if I will say to someone: use Firefox (my choice) because is the best, and that person do not have as first concern which browser run on it's machine, will install Firefox regardless if is safer or not than IE.
The issue I want to talk at large is why NaroCAD do not support alternate OSes like Linux. Firstly NaroCAD as a project with a small team so only supporting the install script for any new platform will mean spend time without any result in a short term. Because of this, if we will want contributions Linux will be as good as we will get a win lately in our free time that we spend developing every new feature you met. If Linux in itself is good for servers, have a fairly good toolset for developping applications, including Mono (a free .NET implementation) and OpenCascade version of it, integrating all is not as a free lunch.
- First drawback are the wrappers, which we decide for shortening the time we will generate them (wrappers are a bridge between C++ world - where OpenCascade stands - and .NET world where NaroCAD is implemented). They use over 1000 classes and compilation of them take some time. We pick C++.NET for having only one wrapper. I've tried to spend some time developing a C++/C/C# wrapper but time spent on it do not result on a new wrapper and the time I have is not justifiable.
- The second problem is Windows.Forms GUI toolkit that we use. Mono's Windows Forms implementation is fairly good, but integrates bad with OpenGL at large and our bridge as we will use OpenCascade wrappers will need to get the Windows' X11 handle at the end or to create a separate package just for that. Or To use Qyoto wrappers of Qt (.NET wrappers) and to try to make a blackbox implementation of it. Which is not trivial again as we will have to reimplement all Windows.Forms in Qt.
The good part is that NaroCAD had separated OpenCascade code and probably if a company will want Naro ported to another GUI toolkit, excluding the OpenGL talked part, it can simply change some source-data classes that expose the same for Naro's framework.
Wrappers have still issues to the day (even we use C++.NET) but are much easier to address those than to create a completely new one. Also, the OS price is not relevant (excluding for a very poor country, but students get Windows for free from their university, or pirate it anyway).
We did try to optimize a lot of NaroCAD's code (or I personally did), so it should run on a netbook that do not cost more than 300 dollars in US, which includes Windows XP which runs Naro.
The easiest solution to make things working with Naro, is just to fix a small piece of code, or even contribute fixing the installer experience. If you have no PC experience, is also easy to submit a bug report, and your feedback can give for us cases when NaroCAD just did not work as you wish and when we have time, we will address those.
3 comments:
"The second problem is Windows.Forms GUI toolkit that we use. Mono's Windows Forms implementation is fairly good, but integrates bad with OpenGL"
Out of curiosity, how do you integrate OpenGL into your application? OpenTK offers a cross-platform WinForms control (GLControl) plus a cross-platform version of Tao's SimpleOpenGlControl. Getting OpenGL to work is as simple as referencing OpenTK.dll and doing:
GLControl glControl = new GLControl();
glControl.Paint += (sender, e) =>
{
// OpenGL commands, followed by
glControl.SwapBuffers();
}
Thank you Stephen for your take.
NaroCAD do let OpenCascade to create the OpenGL context, giving to it the Window Handle directly.
Right now is a rewrite of NaroCAD to use WPF which may be or may not be as simple to use but will make that we will need also a WPF implementation (hopefully the Moonlight stack will provide an enough implementation for what we use on).
I will try to use for my future openGL projects the GLControl (I used SDL bindings previously to create an OpenGL context usign Tao: ( http://sourceforge.net/projects/stengine )
Is much shorter and you're right is really easy to setup.
So your point is fully valid, if we write our OpenGL opcodes, will make things bad. Also, as a small side-effect is that the drag&drop package (WeinFen Luo used by SharpDevelop 1-3.xx) uses Win32 API, which also should pe ported.
Thank you Stephen for your take.
NaroCAD do let OpenCascade to create the OpenGL context, giving to it the Window Handle directly.
Right now is a rewrite of NaroCAD to use WPF which may be or may not be as simple to use but will make that we will need also a WPF implementation (hopefully the Moonlight stack will provide an enough implementation for what we use on).
I will try to use for my future openGL projects the GLControl (I used SDL bindings previously to create an OpenGL context using Tao: http://sourceforge.net/projects/stengine )
Your idea is much shorter and you're right is really easy to setup.
So your point is fully valid, if we write our OpenGL opcodes, will make things bad. Also, as a small side-effect is that the drag&drop package (WeinFen Luo used by SharpDevelop 1-3.xx) uses Win32 API, which also should pe ported.
Post a Comment