Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Erster Upload von Kartoffelpüre #69

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added stylebook/BomView-Body.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added stylebook/ComboView-Feature-TimeBar.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added stylebook/ComboView-Feature.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added stylebook/ComboView-Flat.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
68 changes: 68 additions & 0 deletions stylebook/ComboView-History-of-an-Universe.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
# ComboView - History of a Universe

The ComboView is the most important Part beside the MDI-View.

## History

Working on a Model will end in a tree like structure thad define your Model. The slim ComboView itself is not able to show the tree. A slim way to show a tree and have a easy way to not miss the important references complete, is a History structure. If you work with a History you avoid to work with references on parts of a tree that not exist on a certain point.

If you work with a clear history, you need a TimeLine as a kind of time machine.

![TreeHistory](TreeHistory.png)

## Naming

Because of the closeness to historical aspects we use terms from this field.

* Historic dependencies could be addressed by Parents and Children.

* A collection of historic dependencies is called Era.
(We don't use Family because that term in some CAD has a different meaning)

* Moving in the History is like using a time machine, for that we use a PresentAgeBar.


## Structure

Structure View

FlatView is a View that shows the Content in the Combo view in a pure historic view. This Historic view is identical with the order FreeCAD would calculate (if no multiprocess)
![FlatView](ComboView-Flat.jpg)

The BOM-View shows the BOM structure. This is autogenerated by Dependencys of bodies. Her you could change the position and fill some properties.
![BodyView](BomView-Body.jpg)

This is the FeatureView which has a focus on showing reference dependencys.

Details se below.

![FeatureView](ComboView-Feature.jpg)


![FeatureView-with-PresentAgeBar](ComboView-Feature-TimeBar.jpg)

DocumentName

* 📦 Model - Feature Name
The existence of this Model start with the first feature that creates it.
The Model entry contains two icons. The feature Icon and the general body Icon.
* Feature
* Sketch
* Externals and Dimensions
Such as Plane, and other geometry that used by the sketch. Also Dimensions with values.

* SubModel
SubModels exist, if references for creating this new Model is based on another Model e.g. Sketch on a Surface of _Model - Pad 1_ and relation on other external edges. to create a new Body


If a body has references from another body, both Bodies are automatically merged in a MultiBody Object, this is because that way you could see at the first glance, that bodies depending on others, also it is not possible to create a mate between two bodies that already linked by sketch relations.

## Possibilities

* Era - (Directory)
An era defines a historical area that concerns a certain interdependent set of features. It is not possible to omit individual elements in between. Normally an Era define a specific part of a volume and all features that are needed to get it.

* PresentAgeBar
Is a kind of Time machine that allows you to travel back in time and see how a file looks like in the past. It helps also to place references and sketch relations on geometry that are in the correct relation to the new feature.
If you modify an item the PresentAgeBar moves to the historic point where it is located and shows the shape of the body on that time.
**IMPORTANT**: It's not possible to create references and relations to geometry that exist in the Future. So References and relations could only been established to items created before the current PresentAreaBar.
43 changes: 43 additions & 0 deletions stylebook/ComboView_PartDesign.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
# Style Guide ComboView in PartDesign

This document is still a work in progress. Please leave a comment in the chat or highlight some text and click on the tooltip to comment. This document is related to "Style Guide "ModernUI 23" FreeCAD"

This document assumes the TNP problem is solved.

The PartDesign Workbench uses a parametric, feature editing methodology, which means a basic solid is sequentially transformed by adding features on top until the final shape is obtained.

This behavior requires a history-based approach to design. A feature may depend on one or more other features, resulting in a relationship tree.

Even if the TNP problem is solved, it is recommended to design a flat hierarchy.

This style guide is intended to help design the FreeCAD interface and create a simple user interface that is intuitive and easy to understand.

1. ComboView --> DataAndHistoryPane (TreeView)
 --> See also the [MultiBodyPart vs. Assembly Problem](MultiBodyPart-VS-Assembly-problem.md)

![FeatureView](ComboView-Feature-TimeBar.jpg)

![Tree History](TreeHistory.png)

1. _Model_ History Tree
Contains the Body modifying History. Has a command that temporary replaces the 3D-Area with a Treeview that shows Relation between Features.
* Feature
* Sketch
* Plane (The DatumPlane, or a relation to a face)

* Relations to other Feature, sketch or body They highlight the related objects on Mouse hover

* PropertyPane (optional)
Allows to Split feature with a lot of settings into smaller parts, so specific settings are easier to find and modify.

* ModelData
* Body BOM-Settings
Use as "part" or "construction", physical properties like Material and density, etc.

* Body Properties (only if BOM-Settings are none or part)

* Property and value table
(Label, Description, calculated weight, max dimension, etc.)

2. Reference List
List of data links from this document to external document.
Binary file added stylebook/FreeCAD-Window.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
33 changes: 33 additions & 0 deletions stylebook/MultiBodyPart-VS-Assembly-problem.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
# What is the MultiBodyPart Vs. Assembly Problem?

## What is an Assembly?

An assembly is a bunch of independent objects that stick together. This Independent Objects normally are parts which either are developed to fit in several unrelated Assemblies or where third party objects.

If you modify them you normally only use a kind of cut so it either fit into a certain place or get holes to place it or another part.

## What is a MultiBodyPart (with external references)?

This Problem increase in an environment with a solved TNP Problem. A MultiBodyPart is a Bunch of volumes that depending on each other by using external references.

For example: You are creating a large machine that contains several parts, but you need to adjust the dimensions of the structure and the shell in which the parts are located to fit the contents or the planned environment. In this case, you prefer a solution where you only need to change some key values, such as length, width and height, to modify the U-beam structure and the sheet metal shell of the machine.

## Where is the Problem?

The Problem appear if you try to mix both. As clear the difference use-case seems. It is difficult to separate this two in real life. Especially If you are in an early stage of a new product.

It could happen, that you create a MultiBodyPart but after that try to move a body with assembly mates to a new location.

## Solution?

### Use application limitation

So you have to set up, or you get automatically a "MultiBodyPart" Object. The moment you use External references or use feature that split or merge Bodies. Bodies inside this object could not be moved independent to other Bodies of the same object except you opt-in a setting per object.

Allow to use Assembly-Mates only in context of bodies that origin from the same feature. e.g. you split a body into two bodies, but now you need a little distant between them. In that case you could mate both bodies to have a specific distant.
Assembly mates is a feature that relocate several Bodies according to several mates. This is similar to the sketch relation inside a sketch.

### Have trained and informed User

User which know what they do could create really cool and easy to maintaining machines. (Sadly we could not assume that.)
With the freedom to mix assembly and MultiBody you could save a lot of time. And easy modify along planned parameters. This need a good overview about the current case. A feature-tree that shows relations in an understandable way. A help to create, removing and repairing such references as easy as possible is important.
Binary file added stylebook/PopupMenu.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
41 changes: 41 additions & 0 deletions stylebook/Rules-for-Feature.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Rules for Feature

Every Feature has to define what type of Input is allowed. Assume that you preselect things and after that run a feature. This feature could take the preselected content that matches a type it understands. In best cases no other selection is needed. It's not up to the Feature Designer to decide if such kind of working is possible or not.

A good example could be a tooltip that shows possible relations that work with your selections. e.g.: [https://forum.freecad.org/viewtopic.php?p=582953#p582953](https://forum.freecad.org/viewtopic.php?p=582953#p582953)

![PopupMenu](PopupMenu.png)



If you successfully finish a new Feature the Feature is saved into the ComboView:

* It's saved onto the place where the PresentAgeBar is located.
* This Feature contains the Script and all parameter to fulfill its purpose and allow recalculation.

* Information has to be stored inside the Feature:
It helps to Update Feature and solve errors.
* Needed dependency like Workbenches and others.

* Version of FreeCAD, Workbenches and this feature itself.

* Date where this feature was created and modified

* Modifying a feature brings back the same Task Dialog that it was used to create the Feature.

* It has to work even a Workbench is not active which created a feature. That not means that all settings have to be available but at least:
* it has to be possible to modify and change dimensions

* It has to be possible to repair references

* Settings that need a loaded Workbench, shows a Menu entry to load the Workbench and after that made the settings visible for modifying (in background without left this task)

* While modifying a Feature, it has to allow:
* Measure 
* Create temporary visual Cut to find hidden things.
* Every Feature that could increase volumes could also reduce (cut) volume and between this by a single click.
Setting could be preset and hidden, if in most use case not needed
(e.g. in Arch the wall feature)

* Every Feature that add/remove volume could also split a body into several and also merge several bodies into one.
Setting could be preset and hidden if in most and usual use cases not needed
Binary file added stylebook/TreeHistory.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading