[cad-linux] Re: CAD format, virtual filesystem, editing

  • From: Massimiliano Mirra <mmirra@xxxxxxxxx>
  • To: cad-linux@xxxxxxxxxxxxx
  • Date: Mon, 08 Sep 2003 01:38:36 +0200

Janek Kozicki <janek_listy@xxxxx> writes:

>> So ./viewport is the file describing the viewport metadata, such as
>> selections and such?
>
> as written below - selections are written inside a file. ./viewport file
> contains only information relative to viewport. Such as coordinates of
> central point of view, and zoom factor. Or FOV, or anything relevant.

Mmmmh... is it really necessary to store this in a file?  This data
seems limited to an instance of the viewport; do you envision a
setting where sharing it would be important and so storing it into a
file can be an advantage?

> Note that group will be reffered by filenames. So if filename changes
> then it leaves that group. hmm no _simple_ solution to this yet. 
> (complicated is to keep Bruno's filename 
> <HOSTNAME>-<UNIX_DATE>-<PID>-<INODE>.<OBJECT_TYPE> forewer. 

I'm not sure this format is optimal.  But I can understand the need to
create unique names and the advantage to be able to just drop files
here and there without worrying about accidental overwritings (which
for example xSpace currently lacks), maybe it's just a matter of
attaining it through other means.

> and to add more descriptions to it - like I mentioned in post 
> "[cad-linux] Re: Design methodology for an open geometric data management 
> standard"
> as to add attributes to filename)

This is where xSpace approach helps.  Since each object is a
directory, object attributes can easily be extended by creating other
files.  Right now there is `axis' (containing position, scale and
orientation), and `geometry'.  I already mentioned `cache'.  Later may
come `materials' and such.  And they can as well be softlinks to
outside libraries of geometric data or other kind of data.

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 (think static web
sites vs. dynamic web sites).  This provides a nice way to create
parametric objects, at least the self-contained kind that does not
interact with other objects.  Somewhere you have this (* means
executable, -> means link):

    /cad/library/parametric:
    *door
    *window

Then there is your work space

    /cad/space/house/kitchen:
    /cad/space/house/kitchen/window:
    geometry     -> /cad/library/parametric/door
    param
    /cad/space/house/kitchen/door:
    geometry     -> /cad/library/parametric/window
    param

/cad/library/parametric/door is a script written in whatever language
and this is its interface:

    $ cd /cad/library/parametric
    $ door --help
    Usage: info [OPTION]... [MENU-ITEM...]
    Options:
     --knob-height=NUMBER     Doorknob height from the floor.
     --keyhole-type=STRING    Style of keyhole (oval, round)

/cad/space/house/kitchen/door/param is a plain text file like this:

    $ cat /cad/space/house/kitchen/door/param
    knob-height: 1200mm
    keyhole-type: oval

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

etc...

Only when the user is sure about the transformations, he `commits'
them and the object geometry gets modified.  Or he never commits them
if original data integrity is important.

> I haven't tried tk. But xlib appeals to me by it's simplicity. I
> (personnaly) don't want cute icons, big menus/whatever I prefer command
> line <-> point'n'click work. No need of icons and menus at all.

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. ;-)

> 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.

Massimiliano

Other related posts: