Hey everyone - new member

My name is Joe, just joined over here after seeing a blog post by Johan Thelin from the Planet KDE feed :)

I'm an Audiovisual Consultant, and recently become cross-discipline (at the request of superiors) and am now venturing into telecom and security. I'm a big fan of KDE, specifically on SUSE, and have recently changed most of my (far too many) machines over to OpenSUSE 10.0. I'm a regular wiki contributor over there, as well as being mildly active on the lists.

More recently I've decided to get back into coding, and have begun reading up on using Qt since I'm a somewhat recent convert to KDE over Gnome (still had those myths about Qt's licensing built into me until somewhat recently :D). As a result, a new app I'm working on, an autocad equivalent, will become my first Qt app. Sure, its a huge project for an initial crossover, but I find them more interesting rather than disturbingly huge ;)

Thats about it, glad to be here :D

Welcome to our board.

Hi Joe!
(My first name is Jerry, but my handle on all the Linux watering holes is GreyGeek).

Quote:

---

As a result, a new app I'm working on, an autocad equivalent, will become my first Qt app.

---

Wow! That's a tough app to cut your teeth on!

Have you seen QCad, a cadcam system built using QT?

The website (http://www.ribbonsoft.com/qcad.html) appears to be down, presently, but it is in all the Debian repositories and you can probably find it at RPM Bone.

Seen it, tried it, was far from impressed. I've also tried ProgeSoft cadforlinux, BricsCAD, and many other little things out there. The downsides to all of them vary from being IntelliCAD (and, as a result, windows based working through wine), to being 2D only, to not handling DWG (especially after the 2000 format), to being just piss-poor when it comes to overall usage.

I've taken a peek at the QCAD source, and I'll be using a few ideas from them in my app, however I'm taking things in a bit different and more powerful direction. As an AutoCAD user for a long time, and having to use it on a daily basis, I'm intimately familiar with many of the benefits and issues with it. The biggest issue, to me, is that its virtually impossible to use with linux (newer versions have many, many explorer integrations).

With the many issues that exist, and knowing what ACAD should do but doesn't, I've decided that coding my own version would be a hell of a way to break myself in :) I've always found going headfirst into something that seems excessive can be ultimately a much better learning experience, and much more rewarding. My initial Pascal (the wordy C) experience was a form creation utility for lawyers (my brother's comp sci teacher was running the project - yep, got paid :D ).

I posted up on my new blog about it, and also have the initial project proposal posted up. I'm currently working with Qt Designer on creating the prototype UI, and trying to finish the feature specification and project roadmap, along with a developer specification. All that is going to be posted on the KADD sourceforge site that just got accepted.

I may be new to using the Qt libraries, but... I'm a bit of a perfectionist, a touch of a workaholic, and very much of a linux zealot ;). It'll take time, I have no illusions about my abilities or the scope of the project, but I'll be working diligently to create a viable offering. Considering the number of CADD people out there with coding experience, I'm sure I'll generate atleast a minimal amount of support, which may help speed the project up. However, my roadmap is based on project milestones, not dates, so I have no worries there either.

No, I'm not normal :D

Well, good luck!:)
Don't hasitate to ask here for help on your project.
Did you think already in general how are you going to do the 3D stuff?

I've put some thought into it, yes... but I will be trying to firm up my idea this weekend. I want the methodologies I'll be applying to be as obvious and descriptive as possible in the developer spec, so I need to really examine how I'm going to accomplish this, and do it properly.

And trust me, I'll probably be a regular pest over here when it comes to questions ;) On the up side, KADD will be GPL, so it will be easy for everyone to see what I'm trying to accomplish! :D

Well, I actually may as well post up my initial ideas here...

Since its 3D, I'll effectively need someX, someY, and someZ as a representation of the 3D environment, using realX, and realY to translate the view to the 2D representation of the 3D image being put on the screen, as well as a limitX and limitY to handle the on screen "viewport". Now, I'll also need angleX, angleY, and angleZ to account for rotation.

From what I've looked at with Qt, the QPainter object will handle my line drawing, and I'm guessing I'll be able to make use of the QGL libraries to handle my rendering using opengl, hopefully. And I'll have to compare to the source for the upcoming KDE4, which intends to make use of XGL, glitz, etc, etc to speed up drawing of better widgets, and KDE4 is my intended GUI accompaniment for KADD's eventual release.

Did that come across making any sense? lol

Btw, I'm completely self-taught when it comes to c/c++/java/etc, everything except pascal (and that was a high school course), so if I occasionally have oddly complicated methods simplified by an obvious library... well its probably because I don't know it exists :D

It sounds to me you are trying to make things from scratch.
I think its not a very good idea, not (only) because its a monumental amount of work (you don't think ACAD was done by one or few hobby programmers do you?) but because it will be conflicting with the reasons you set out to to this project from the first place - namely - features and compatibility.
If you want your CAD to be all the others are and more ( as you wrote above) then you will have to be able to implement things as they did, or at least, be able to implement their formats.
So as a start, I would try to learn how ACAD and others are doing things.
This will give you insight on the advantages and disadvantages, and allow you to take the good and fix the bad.

I don't want to sound discouraging, but I don't think you are aware of the amount of work you set to do, even though you claim you do...

As you said, I think as well, a good way would be to go after mile stones.
Make it modular, and bouild the system from building blocks.
One block at a time.
After you have finished your design, see which is the best component to start with, I will be interested to know once you decided.

Good luck!

The unfortunate thing is, I don't have much of a codebase for 3D to start with... unless I want to have my hand at K3D or Blender, neither of which use Qt (gtk apps).

Effectively how I mentioned above is how they are accomplishing things, with each set of realX, realY, etc being appropriated to each available viewport (ie local vars, multiple instances capable). As far as compatibility goes, the primary issue is with the drawing files, mainly because the later format (post-2002) makes use of an encrypted header, despite the fact that they claim they do not. However, the ODA (opendrawing alliance) has a library available (albeit closed source, its the best option available), which is free when the program being written is available under an appropriately free license.

The drawing system... yes, much must be from scratch, simply because of the lack of a solid Qt based 3D drafting system, though I will definitely be using existing apps such as K3D and Blender mentioned above to give me some ideas for appropriating coordinate systems in a distinctly usable method. Its in the side applications and the scripting engine that I'll be able to make use of much existing code, considering the number of gui term apps, distributed rendering systems (did I mention I'll be trying my hand at SMP? I won't be able to do this myself, though, I know that), scripting systems, dxf management, etc, etc available under the GPL.

That being said, once the developer spec, feature spec, roadmap, and gui prototype are complete (end of the month-ish), the first section I'll be working on won't actually be a part of the main KADD application, it will be for a plotting subsystem. I'm making the plotting system a standalone app, and using plot styles with the dwg in a wrapper to set up automated processing of plots, something that should exist with AutoCAD. This initial portion of the project (more like a sub-project), will allow me to start getting a feel for Qt and the acad dwg library provided for me by the ODA.

So I think I'm atleast on the right track in my dev planning. The key is, I don't want to implement everything they did, I want to implement everything they did thats useful and then some. You'd be surprised at the level of useless utilities available within autocad, while missing some of the most basic (like a real internal calculator, or atleast ability to use one install on the pc by default).

The only essential naming structure I need to maintain is from DXF, which is the open standard. DWG uses the same elements with some additional bytes (and the encrypted header) for a little bit more capabilities, however those will be handled by the ODA library. The DXF standard, however, contains a header, a class section (with blocks, entities, and objects), tables (which is a symbol table subset), block reference table, layer, linetype table, text style table, UCS, etc. The UCS I'd need to found regardless to be able to handle the someX, someY, and someZ.

Considering the length my dev spec is at already... sure itll end up being more than I initially believe, but I have no doubt that this is an absolutely, complete, ridiculously massive undertaking ;)

EDIT: Btw, yes, I'm trying to be as modular as possible, and developing that into the spec. I'd rather be featureless other than my base requirements for the milestones than develop an effectively useless codebase should I require some sort of general update to structure and design of a routine. Thats also why I'm starting with the plotter system, it'll be able to act standalone, but will also help me formulate my outcome by actually running through the steps associated :).

Well, I think it would make much more sence to take one of the open source ones, like QCad and build on it, add what you think is missing like 3D...
Doing things from scratch looks to me madness...

Hey, but if you are up to it, go ahead! :-)

Oh don't get me wrong, I'll reuse snippets wherever possible, no need to reinvent the wheel...

The problem is alot of qcad code is, imho, kind've messy. I'm pretty particular about my code, and I'd end up having to rewrite alot anyway out of OCD ;)

Hey Joe! We met over on fedoraforum.org.

Hey!

Always fun seeing members of other forums pop up randomly! :D

Well it looks like I'm progressing on KADD...

I have some more info, more libraries, etc, etc. In the quest to minimize reinventing the wheel, I have come across a variety of tools. So, in a brief update (to anyone who may be interested), here is where I stand:

HPGL - Overall, very simple layout. The PCL 5 manual contains detailed information on HPGL, so I'll be able to create PLT's pretty easily.

Open Design Alliance - This is the heart of DWG compatibility. I'm waiting for an answer on specifics about the licensing though, so this could come as an issue.

OpenCascade - CAD/CAM/CAE kernel and development platform... for 3D design, rendering, etc, etc. This will provide the backend generation of models, with its own preset primitives being available, its an excellent tool. The license is similar to LGPL, so definitely no problems there. C++ oriented, with examples of being used with Qt.

File Format - Since using DWG will limit me to what AutoCAD is capable of, I've decided to do something like .kad, acting as a wrapper, containing the DWG file and an xml file. The xml will contain (for now... maybe more later) varying plot configurations and settings for semi-automated plotting, and subversion/cvs/git/whatever repository login information, server, and revision information. This should be an outstanding startas a very usable and extensible format.

Plotting - Plotting will be divided into two parts - the front end, where the options are chosen, and a "plot server", which will actually generate plt's or other formats and outputs, and process them. This will allow networked users to make an output selection and submit it to a plot server for processing, reducing per-workstation overhead when being used in a networked environment with a dedicated print server.

Command Line - I've been reviewing yakuake, among others, and know where I'll be taking this. Inside KADD will be its own Lisp shell, similar to elisp, or vanilla lisp shell (VLS). I'll use one of those as the base (more likely VLS), and port, as necessary, to VLisp (Visual LISP aka AutoLisp). I'd like to stay away from this if I can, since I'd prefer to use common Lisp over any modified lisp. Not sure how I could do this and preserve current lisp routines, but I'll have to test one by one and see what breaks - I don't think theres much choice there. If anyone has any ideas, they are very welcome :)

Well, thats about it for now I guess... when I get home I have to do some catching up on housework, but I'll hopefully be dedicating a few hours a day to this as of Friday :D

[QUOTE=CuCullin
.....

No, I'm not normal :D[/QUOTE]

Neither am I, but I can retire next Feburary if I want to! Are you sure you have enough time between now and retirement to complete this proggy? ;)

@greygeek

Quote:

---

Neither am I, but I can retire next Feburary if I want to!

---

I bet you will continue coding after February;)

Cheers

Quote:

---

Originally Posted by GreyGeek

Neither am I, but I can retire next Feburary if I want to! Are you sure you have enough time between now and retirement to complete this proggy? ;)

---

Of course not! I barely have a life as it is.... won't stop me from trying though ;)

I've also realized a single document can't be updated well enough to relate to my frequent little ideas and such, and actually am moving all documentation to a wiki - I think it makes for a more updatable and manageable setup. Also, if people at some point become interested and involved, they too can update and expand upon whats being done, kind of documenting as it goes.

For now, I'll be happy if I can get the core elements together, and expand from there. I'm trying to reuse as much code as possible, hopefully making it a bit easier to get things together in some reasonable shape before 2066 (appr. retirement year ;) ).

Now if I could somehow stop myself from screwing around with betas, I'd have an easier time with kdevelop! :D