Splitting complexity

[drmacro]

... But the dependency of file structure (with file extensions that are recognizable) and only do the "one thing and one thing only" approach of SW (but also SE, Pro/E etc.) is also IMO a good feature....

IMO it is not a good feature.

There is no concrete way to discern if a multiple file structure provides any benefit overall without having side by side data to compare. The benchmarks for such a comparison would need to be defined , what characteristic of each benchmark would represent beneficial, and then a version of FreeCAD produced to make the comparison.

This would entail a rather substantial effort to produce a version that modifies core functionality of FreeCAD.

But, this is a pointless discussion since opinions are unlikely to spur a project of such magnitude.

[grd]

IMO it is not a good feature.

There is no concrete way to discern if a multiple file structure provides any benefit overall without having side by side data to compare. The benchmarks for such a comparison would need to be defined , what characteristic of each benchmark would represent beneficial, and then a version of FreeCAD produced to make the comparison.

(Now I am talking about PDM)

It would help *a lot* with the creation of images (that can be used for displaying a pre-view of a drawing, assy or part), and it would also help with the material / weight problems that are here in FC, and also, when you see a drawing, a part or assy, it helps to know what type it is.

[drmacro]

IMO it is not a good feature.

There is no concrete way to discern if a multiple file structure provides any benefit overall without having side by side data to compare. The benchmarks for such a comparison would need to be defined , what characteristic of each benchmark would represent beneficial, and then a version of FreeCAD produced to make the comparison.

(Now I am talking about PDM)

It would help *a lot* with the creation of images (that can be used for displaying a pre-view of a drawing, assy or part), and it would also help with the material / weight problems that are here in FC, and also, when you see a drawing, a part or assy, it helps to know what type it is.

Name conventions can be defined and used with no changes to the code. Images can be done with current code (Tools>Save picture) , and if the correct settings are used in Edit>Preferences) a thumbnail is saved (in the FCStd file) and can be seen in the system file browser, and can be extracted from the FCStd.

A pic from an assembly:

MyAssemPic.png (68.83 KiB) Viewed 637 times

A picture in the file manager, to me, is far more better than any file name could ever be:

FileManagerThumbs.png (121.92 KiB) Viewed 637 times

[grd]

@dmarco. Yes, I agree totally. But you didn't replay the rest of my answer. And to be honest, these CSYS displays in the files is a bad idea. When you only have ONE object, the display is always completely correct.

[mfro]

(Now I am talking about PDM)

you aren't.

It would help *a lot* with the creation of images (that can be used for displaying a pre-view of a drawing, assy or part), and it would also help with the material / weight problems that are here in FC, and also, when you see a drawing, a part or assy, it helps to know what type it is.

If it would help you if you see if a file is a drawing, why not just *name* it as such? Nobody prevents you from doing so.

Regarding "PDM":
PDM is way more than a thumbnail of an image of your part.
Let's say you are a producer of metal boxes of different size. What would it help if you had thumbnails of hundreds of identical looking metal boxes to chose from?

PDM also needs to be sure about the contents of a file, so even if you had (e.g.) an assembly extension, PDM had to look into the file if it really contains what it pretends to. Same with attributes like weight, outer dimensions, it has to check if the drawing header is filled in completely and correctly (or even do that itself). To achieve that, the PDM CAD interface has to have the ability to look into and interpret (at least part of) the file contents. Checking if a model that pretends to be a drawing is really a drawing is the probably the least difficult task it has to do.

So let CAD be CAD (and concentrate on it) and PDM PDM. There's (way more than) a reason for that.

[user1234]

That is in fact not true for Creo. If you save files in Creo not over a PDM, is saves all per default in one *.pkg file.

You are talking about Creo Elements. We had earlier also a discussion Where Creo is mentioned and you talk about something else...
If somebody talk about Creo 99% of the time it is about the former Pro Engineer!

Well could be. In my bubble around me (the only 2 companies with PTC CAD software) Creo Direct Modeling is still Creo and Creo Parametric is Creo Parametric (i think because the name Creo was at first on Creo Direct Modeling). But yes, not many know about Creo Direct Modeling anyway (and that is good, because it is, nicely said, not good).

We continuously speak about flexibility for the programmer but the flexibility of the user is a bit ignored...

I can not speak how other interpret about that in this thread, but i understand all this flexibility here for users, not for the devs.

(Now I am talking about PDM)

It would help *a lot* with the creation of images (that can be used for displaying a pre-view of a drawing, assy or part), and it would also help with the material / weight problems that are here in FC, and also, when you see a drawing, a part or assy, it helps to know what type it is.

All PDM i worked so far, analyzed the file (structure) before saving anyway. So a PDM can flag a drawing only, an assembly only or whatever anyway. Also pictures are not that good preview. They can be distorted (like in the PTC Modelmanager) or without (or false, when the preview is bad) meaning. For example Siemens Teamcenter generates a preview (also in 3D) through (if you want a spools manager) a tessellated shape (*.jt format, see https://en.wikipedia.org/wiki/JT_(visualization_format)).


Greetings
user1234

[grd]

All PDM i worked so far, analyzed the file (structure) before saving anyway. So a PDM can flag a drawing only, an assembly only or whatever anyway. Also pictures are not that good preview. They can be distorted (like in the PTC Modelmanager) or without (or false, when the preview is bad) meaning. For example Siemens Teamcenter generates a preview (also in 3D) through (if you want a spools manager) a tessellated shape (*.jt format, see https://en.wikipedia.org/wiki/JT_(visualization_format)).

Yes, we can and we probably should display a JT file, but then it is --again-- much easier with only ONE body instead of I don't know how much. Are you seeing what I am looking for? Everything becomes much easier, especially for the user.

[Jee-Bee]

Because of that I actually didn't want to post anymore in this thread, but anyway, since you addressed me directly...

I understand what you mean. I also was a frustrated frog and need to rest the discussion for a few days...

When you only have ONE object, the display is always completely correct.

Not necessary. I had a project some time ago where we had to model things on the place where they are in assembled state. in this way it is easy to place them on CSYS / default. If you have an object 200 x 300 mm and more than 1.5 m of CSYS images are almost useless.
It is better then no image... but it is still.
Also a nice one is that some companies want the objects the collor as they have in real live and specially with black ojects a picture is worthless...

FALSE and on the contrary, this is what would happen if grd's proposal were to be implemented. He wants to forbid the current behavior of FCStd files that allow multiple objects in it. Flexibility is exactly what FreeCAD offers already.

Okay, maybe i had taken a shortcut too. i never intended to forbid the current way since it is weird the force a part and assembly in arch or draft...
I always intended it as extra options.

I think the OP is of the opinion that splitting things to multiple files would improve the general performance of the application. I didn't think it was an improvement in workflow or user experience thing.

I differ in this (what probably didn't make the discussion better) But i think it is the reversed.
Splitting in multiple file types make it possible to choose the file type i need to edit (Within FC but also with sorting in the OS File browser). It makes it more visual which files have already a drawing and which ones doesn't. When using version history there are options to edit only the drawing (typo's etc) without changing the base model(quite often the discussion from 2.0 to 3.0 OR 2.0 to 2.1)

So, and I have asked about this before in this thread, what enhanced usability does this proposed change functionally bring to the table that you don't already get through the 'workaround'.

Because the essential point of a work around is that you can do something but it's exactly not as good as intended.
A small example my accu drill has a max drill size 12 mm. If for some reason i need a bigger hole, first i take the biggest drill that fist, then i make a hole. after that i take another dril and try to remove material from the side up to the required size....
It works but it are never nice round holes and the Cylindricity is equally worse. Most of the time the hole center shifted a bit more than with drilling it directly. If it should look nice i need a bit of luck too!
For me the work around feels exactly the same.
I can split the files. good for revision like things and with the right naming(name_type) i can see what models have a drawing. But i can't filter / sort on model type when opening an existing file / or file browser. And i think i filter on model type way more that checking if every model has a drawing.

There is no concrete way to discern if a multiple file structure provides any benefit overall without having side by side data to compare. The benchmarks for such a comparison would need to be defined , what characteristic of each benchmark would represent beneficial, and then a version of FreeCAD produced to make the comparison.

Agree on this without optimization i don't expect speed improvement(from system view point). On user level (read searching to the requested file) it may improve speed.

[user1234]

Yes, we can and we probably should display a JT file, but then it is --again-- much easier with only ONE body instead of I don't know how much. Are you seeing what I am looking for?

Why this should be easier? You also have to do this in assemblies.

Greetings
user1234

[grd]

Why this should be easier? You also have to do this in assemblies.

Sigh...