[cad-linux-dev] Re: uber-converter, other tools
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: CAD linux development <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Thu, 19 Aug 2004 13:53:04 -0500
# The following was supposedly scribed by
# Bruno Postle
# on Thursday 19 August 2004 12:30 pm:
>It would be great to have a CAD tool that I could ask to show only
>circles on layer 'columns' that arn't red that were last-modified on
>a Sunday and have a radius less than 800 or greater than 1000 - This
>would be so much more powerful than just turning layers on and off.
I'd like to see such a tool get started as soon as this hub format is stable.
In fact, it would be good to have such a tool parallel the hub design. Right
now, we are basing design decisions primarily on pythoncad, autocad,
PostScript, and SVG. Postscript and SVG are going to be very limited in
writing to the hub, but the goal is to have the hub data structures designed
in a way which allows as much information as possible to carry back and forth
between as many connected formats as possible.
I think your ideas are rather focused on the persistent database, such as in
your Draft implementation. This is also a good catalyst to have in the
design, since pycad and acad have no concept of persistent entity ID's.
Conceivably, some persistence could be achieved with acad -> hub -> pycad ->
hub -> acad by testing geometry locations, but both of the current
implementations are assuming a 'clean' directory to write into.
Ultimately, connecting to parametric and relational programs will require a
different hub. At that point, I refer you to the hub-is-a-node principle
where we achieve persistence in dumber hubs by encapsulating the search
process into the hub1<->hub2 interface.
--Eric
--
"Cleanliness is next to impossible."
--Unknown
Other related posts:
- » [cad-linux-dev] Re: uber-converter, other tools
