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