|
Development Notes OpenClip began with a problem. In England, PRD Software has been working on developing In2Space, an architectural modeller with tools specifically designed with buildings in mind. From the beginning, it has been designed as the 3D Modeling Partner for PowerCADD, with many similarities in the two programs so the PowerCADD user will feel right at home. It is designed to be simple, intuitive and easy to use, indeed no manual is planned or needed. But there was a problem. In2Space was based around copy-and-paste from PowerCADD so the user could easily move between the two programs. They were using QuickDraw vector pict, which worked fine with PowerCADD 7 but is now obsolete. There is no vector pict on the pasteboard with PowerCADD 8. They were up a creek without a paddle and without an idea of what to do about it. I felt like doing something nice for them, so I began by talking to Todd Stanley about how this might be accomplished, whether we could get the drawing information from what PowerCADD put on the pasteboard. That wouldn't work, and Todd suggested we put the information in a file, and talked about how we could accomplish this by putting event handlers on the Cut, Copy and Paste commands, all new territory for me. I then contacted PRD's Paul Ratcliffe and Andy Bull and asked them what they needed from the PowerCADD drawing. They only wanted to import lines and polygons; they were only concerned about the fill color of the objects and the drawing scale. So I went to work creating a PowerCADD plug-in for them, and putting a handler on the menus proved to be somewhat difficult. But after a week or so working on it, I got it working, ran through the PowerCADD drawing for the objects they wanted and sent it to Andy Bull at PRD. He put the objects in an NSDictionary and then decided to put this direct on the pasteboard instead of dealing with a file. I then began to think of how this concept could be used in a general way with other programs. Our PowerCADD users want us to 'get closer to 3D' so they can more easily work between the 2D world of PowerCADD with a 3D modeling program—and everyone seems to have a different favorite! In order to do this, you had to be an expert in both programs. In the case of PRD, they didn't know enough to create the PowerCADD plug-in, what they ended up with had many limitations, and they certainly would not be able to handle a Paste back into PowerCADD without more help. So one day I placed a call to David Kropp at AutoDesSys. They have been working on FormZ for as long as I've been working on WildTools, and I was particularly impressed with their new Bonzai3D program. While there are always minor differences, I was struck by the similarity of Bonzai3D with WildTools. Both offer a complete set of tools, and it looked like they were thinking along much the same lines that I had been. For many of the tools in WildTools, there were equivalent capabilities in Bonzai3D. I didn't see any obvious missing capabilities. I was impressed with the completeness of the software. I introduced myself to David and asked him if he would like to work together to break down the wall between 2D and 3D. He was interested, and fortunately for me, he had been hearing rave reviews of WildTools for years. I didn't need any introductions or references! We talked in general about what is involved and the common problems. David talked about the problem with translators of having to dummy-down objects for programs that could not handle more advanced objects. So consulting with him from time to time, I then set out to design a 'container' that would handle all of this. It took another month of work, and I got it working in PowerCADD in the OpenClip plug-in. But until you have someone 'listening', this was all 'screaming in the wilderness' where no one could hear you. In December 2009, we finally got to work getting it into Bonzai3D 2.0. They were a little unsure about how well this would work, but Tim Hanes got it working with about 12 hours of work. Since then it's all been easy. None of us could believe how flawlessly it all worked and kept wondering why we all didn't do this 20 years ago. (Easy answer: Apple had not provided the tools back then.) I've always thought that the first law of Macintosh programming is that whatever you're proud of today will embarrass you in a month. Tim Hanes agrees with this, and at this point we are all convinced that we are just getting started and don't even know what the questions are. I then added a 3D copy capability to OpenClip and put OpenClip capabilities into two of the TopoTools commands, so you can copy topo contours and 3D surfaces direct from the "2D" world of PowerCADD to the 3D world of Bonzai3D. How about them apples! There are some unanswered questions... While the OpenClip concept has been begun on a Mac, once it gets going we will quickly come up with a mechanism to do this on Windows. The files are generic xml, and there are many mechanisms for handling key-value pair dictionaries out there. So we urge all cross-platform developers to adopt OpenClip on an evaluation basis while we get the Windows side of things worked out. And if you are cautious about using programming created by others, please consider that the programming required to implement OpenClip is all very simple and straightforward. When you go through it and hook it up with your program, see how it all works flawlessly and think about what sorts of problems you might have with it, then you will come to understand the enthusiasm that people have for OpenClip from the development side. We have all had the experience of writing software that requires a lot of time to maintain and support and other things that have been free of this. OpenClip looks like write-it-once, low maintenance programming. In our experience with Bonzai3D, the only problems were basic things like getting the rotate-about point of rectangles right, consistent colors with all object types, and getting the 'normal' right on rectangles and ellipses. But beyond that, it's all worked flawlessly and has been completely free of crashes. I also thought that perhaps the OpenClip file at the OpenClip path could be used interchangeably with the pasteboard. So a programmer working from a Ruby scripting language might create the file, and then my OpenClip plug-in could be smart enough to see that the file is more recent than the data on the pasteboard, so use the file instead. I haven't been able to get that to work, and maybe it is never necessary. It looks like all this really needs to be done with C++. I'm always open to suggestions and looking for ways to improve things, so if you have any ideas on what we might be doing in OpenClip, please let me know. Thanks, Alfred Scott |
