[freearchitecture] Re: x3d-cad vs. step

[Lars O. Grobe]

Hi!

> This is actually one of the long-term goals of VectorSection.  Because 
> entities are designed to be able to be atomic bits on the filesystem, a 
> daemon could handle concurrency and network issues on top of that.

The VectorSection contains MANY of the ideas needed to create a useful
CAD environment ;-) The problem I see, but that might be a
misunderstanding, that it currently only supports geometry, right?

>> The UI inconsistency is still not solved.
> 
> UI inconsistency is going to be difficult without a company like Apple 
> building everything.  Everyone has their own ideas and demands for 
> interaction design.

I know. In fact, my 3 points were alternatives ranging from little
effort to very ambitious (and ressource consuming). But imho the
consistency of the UI is really critical.

The concept of many small tools is well established in open source. As
long as their is no GUI, these tools already had consistent user
interfaces, with stdin/stout/sterr, calling conventions etc. That is
what made the unix idea of combined small tools powerful.

Combining many tools with GUIs to one big project has showed to be more
difficult, as people get confused when they move objects with "g" in the
3d-app, with "m" in 2d-cad and with "space" in the layout. Maybe that is
one reason why people like office suites, or tools from one company
(Adobe e.g. uses the same keys and similar menus in all apps, so if I
know Photoshop it is easy to learn Illustator).

Do not forget that in a typical workflow, an architect, whose main job
is not to be able to know programs at all, has to use many different
apps, often one for just one step in the process. That is why, in small
offices, those "we do everything in one" concepts are popular. If I use
e.g. Vectorworks, I can use the same GUI, shortcuts, handbooks for 2d,
3d, layout etc. If I have to learn the user interfaces of Pythoncad,
Blender and Scribus, I will never get the productivity just because of
confusion.

I believe that it would be possible to convince at least some authors of
projects to adhere to a common UI if the role of their project is well
defined in the context of such a architecural framework. But it is
necessary to define that framework clearly to make it possible for
everyone to estimate how a project can contribute, how much effort is
needed if the goal of that framework is something the authors want to
support.

In short terms, I do not believe that a big company is needed for such a
project. I think that authors would appreciate if there was a design for
a framework that would allow them to develop an important part of a
successful project, as long as this design itself is promising,
consistent and community-developed.

My optimism is proven now by what I wrote, right? ;-)

>> 2) We develop a new UI interface + model holding application and try
>> to get "engines" derived from existing projects to plug-in. So we had
>> ONE UI, and specialiced tools (invisible for the user).
> 
> Again, a big job.  Trying to create an API that allows any application 
> to get its work done while limiting the UI is going to lead to huge 
> amounts of metaphor shear.  IMO, that's not the place for an 
> abstraction layer (see WxWidgets for a trivial (albeit inverse) example 
> of why this is both difficult and limiting.)

The idea was to write both an interface app and a model server and
encourage developers to interface their existing applications to these.
There are many projects which have already seperated most of their
functionality into libs. G3Dviewer is mostly calling functions from the
seperate lib that contains all the object loading/writing/converting
code afaik, as an example. But still this is a big project, and worse,
it does not promise results soon, which is necessary to encourage others.

> Hmm.  Common format.  That's a great idea.

Certainly not an idea, bust still unachieved (if we are talking about a
native-like supported format. Of course, this third alternative was my
most pessimistic one ;-) Only if you read with which kinds of workaround
people try to combine open source tools today and now...

CU Lars.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3485 bytes
Desc: S/MIME Cryptographic Signature
Url : https://www.email-lists.org/pipermail/freearchitecture/attachments/20060509/82d5c83d/smime.bin