[cad-linux] Re: executable geometry data. attribute definitions
- From: Janek Kozicki <janek_listy@xxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Mon, 8 Sep 2003 04:12:59 +0200
Massimiliano Mirra said: (by the date of Mon, 08 Sep 2003 01:38:36 +0200)
> One more chance I considered is that `geometry' files don't
> necessarily need be flat text files containing geometric data, they
> can be executable files generating geometric data
wow, really cool
[snip example]
I like this idea very much.
> Yet another kind of attribute is the `transformations' file, that
> covers non-rigid transformations (already covered by axis) which might
> look like:
>
> stretch: 0.5 10
> squeeze: 11
> rotate: 10
and then we will need some kind of engine that reads (and executes
where necessary) whole this stuff.. and - like phrostie just
said - display it (through .dxf) on the screen :))
> Only when the user is sure about the transformations, he `commits'
yeah. this toDxf parsing tool should use another tool that `commits'
> I like clean, minimalist interfaces, too. A canvas widget might just
> help you build prototypes to quickly try out ideas, because so much
> work has already been done for you, and when you have found the
> combination of features and functionality you like the best, you can
> get back to xlib and code an efficient interface. Consider that. ;-)
good point :)
> > like this:
> >
> > +----------------------------------------------------+
> > | layer | color | linetype | name |
> > +----------------------------------------------------+
> > | road | red | - - - | stripe |
> > .
> > .
> > .
> >
> > here is displayed a single filename. Like in midnight commander, but
> > the real filename is:
> >
> > <layer> <color> <name> <unique number>
> > <linetype> <contents type>
> > l#road-c#red-l#=.=.=-stripe-1045317918-1278-225423.line
>
> Yes, somewhere the object metadata has to be displayed to the user,
> and that's a good way to display it. But still I'm very wary of
> putting too much into a file name.
Eric Wilhelm said why to not do this. In the post named:
Subject: [cad-linux] Re: CAD format, virtual filesystem, editing
he convinced my, that this is not a good way. But we have many more
possibilites to store attributes. One of them is a file named attributes
in each xspace directory object. Another one is a tag 'Attributes:' in
Bruno's filesystem.
Bruno asked what if we don't want to carry attributes around (the
attribute will be stored inside a file)?
Bruno (hope you will read this) the attributes will be stored in
separate file. Imagine a following line inside a file:
Attribute: Layer road
ok. so this object belongs to so-called road layer. We copied this
object somwhere. Did we choose to copy a definition of road layer
(another file that defines this layer - anything you would like to
define: color, linetype, width) along with it?
If yes, then the layer will exist in new drawing. If no - the object
will belong to "layer 0".
Bruno - am I missing something or this is a solution for 'tables' ?
but then - we will have to develop a good way to store attributes definitions.
One sparks to my mind:
if a directory contains directory called Attributes/ then all attributes
defined there are descendant to all directories that fall in the same
directory tree that Attributes/ is placed in. Inside Attributes/
directory you can have subdirectories for each attribute. So for example
following file:
./Attributes/Layers/road
will contain all information about a road layer (linetype, color, width,
maybe even material? any definition you want) note that attributes can
be redundant, because you will also have a file:
./Attributes/Linetypes/dotline (with definition of linetype)
and
./Attributes/Color/red (with contents like this Color: #aa0000 )
but you can also have such a file:
./Attributes/Linetypes/reddotline
with contents:
Linetype: dotline
Color: red
Anyone could produce any useful combination of attributes.
and if a file:
./Attributes/Materials/stucco
could be an executable, to generate stucco information... man.. that
variety of possibilities astounds me
--
# Janek Kozicki
Other related posts:
