User talk:Uwestoehr

From FreeCAD Documentation

FEM_PostCreateFunctionCylinder and FEM_PostCreateFunctionBox

Please check the usage paragraphs.

Example FEM_PostCreateFunctionBox:

  • no big white cuboid
  • no white grid
  • 16 instead of 6 small cubes.

--Roy 043 (talk) 10:00, 17 March 2023 (UTC)

thanks. Is now fixed.
--uwestoehr (talk) 23:01, 24 March 2023 (UTC)

Please look at the Property page again

2 remarks:

The units you have given are SI units not FreeCAD units. IMO that should be corrected. Example: area should be mm^2.

Do the Lists and PartShape properties actually exist? Or did you forget to add version info? I can't add them with code like this:
obj.addProperty("App::PropertyLists", "ThePropertyName", "Subsection", "Description for tooltip")
There may be more properties with the same issue.

--Roy 043 (talk) 20:44, 5 March 2023 (UTC)

I did not have a look at the properties that were already at the page: https://wiki.freecad.org/index.php?title=Property&oldid=1170272 I will have a look at the code in few days. Concerning the units, the user can set to get CGS, SI, etc. I think it is sufficient to inform about the length at all.
--uwestoehr (talk) 22:19, 5 March 2023 (UTC)

These properties cannot be added (version 0.21.0.32198):

  • ExpressionContainer
  • Geometry
  • Lists
  • PartShape
  • TimeSpan
  • Velocity

Test code:

props = [
"Acceleration",
"AmountOfSubstance",
"Angle",
"Area",
"Bool",
"BoolList",
"Color",
"ColorList",
"CurrentDensity",
"Density",
"Direction",
"DissipationRate",
"Distance",
"DynamicViscosity",
"ElectricalCapacitance",
"ElectricalConductance",
"ElectricalConductivity",
"ElectricalInductance",
"ElectricalResistance",
"ElectricCharge",
"ElectricCurrent",
"ElectricPotential",
"Enumeration",
"ExpressionContainer",
"ExpressionEngine",
"File",
"FileIncluded",
"Float",
"FloatConstraint",
"FloatList",
"Font",
"Force",
"Frequency",
"Geometry",
"HeatFlux",
"Integer",
"IntegerConstraint",
"IntegerList",
"IntegerSet",
"InverseArea",
"InverseLength",
"InverseVolume",
"KinematicViscosity",
"Length",
"Link",
"LinkChild",
"LinkGlobal",
"LinkHidden",
"LinkList",
"LinkListChild",
"LinkListGlobal",
"LinkListHidden",
"LinkSub",
"LinkSubChild",
"LinkSubGlobal",
"LinkSubHidden",
"LinkSubList",
"LinkSubListChild",
"LinkSubListGlobal",
"LinkSubListHidden",
"Lists",
"LuminousIntensity",
"MagneticFieldStrength",
"MagneticFlux",
"MagneticFluxDensity",
"Magnetization",
"Map",
"Mass",
"Material",
"MaterialList",
"Matrix",
"PartShape",
"Path",
"Percent",
"PersistentObject",
"Placement",
"PlacementLink",
"PlacementList",
"Position",
"Power",
"Precision",
"Pressure",
"PythonObject",
"Quantity",
"QuantityConstraint",
"Rotation",
"ShearModulus",
"SpecificEnergy",
"SpecificHeat",
"Speed",
"Stiffness",
"Stress",
"String",
"StringList",
"Temperature",
"ThermalConductivity",
"ThermalExpansionCoefficient",
"ThermalTransferCoefficient",
"TimeSpan",
"UltimateTensileStrength",
"UUID",
"VacuumPermittivity",
"Vector",
"VectorDistance",
"VectorList",
"Velocity",
"Volume",
"VolumeFlowRate",
"VolumetricThermalExpansionCoefficient",
"XLink",
"XLinkList",
"XLinkSub",
"XLinkSubList"
]

obj = FreeCAD.ActiveDocument.addObject("App::FeaturePython", "Test")

for prop in props:
    try:
        obj.addProperty("App::Property" + prop, "Test" + prop, "Subsection", "Tooltip")
    except:
        print("Not valid: " + prop)

--Roy 043 (talk) 21:00, 6 March 2023 (UTC)

FYI: I have now removed the properties that cannot be added as mentioned above. Please restore them when they do work. Thanks.
--Roy 043 (talk) 18:24, 19 March 2023 (UTC)
Many thanks! TimeSpan should work but does not -> I will have a look
--uwestoehr (talk) 22:37, 24 March 2023 (UTC)

OK, TimeSpan is a unit no property. Strange that it was then added to the properties.

About FEM_CompEmConstraints and similar

I have edited the page linked above, basically removing duplicate and redundant info. Before editing the other pages I want you to check this. IMO it in preferable to avoid these pages all together. See https://forum.freecad.org/viewtopic.php?t=72392.

--Roy 043 (talk) 10:14, 15 February 2023 (UTC)

Fine with me. As lazy as I am, I just copied the code from the existing FEM command group (the one for functions). Now you uniformed them, thanks.
--uwestoehr (talk) 00:26, 18 February 2023 (UTC)

PartDesign_AdditiveLoft and PartDesign_AdditivePipe: Faulty info

Can you please check your recent edits:

The Select feature dialog does not list faces. So that is faulty information.

And IMO PartDesign_SubtractiveLoft and PartDesign_SubtractivePipe should also be updated. Because the new feature also affects those commands.

Thanks.

--Roy 043 (talk) 15:09, 25 November 2021 (UTC)

> The Select feature dialog does not list faces.
Thanks! I fixed it now.
> PartDesign_SubtractiveLoft and PartDesign_SubtractivePipe should also be updated.
Yes, I simply forgot them. I did this now.
--uwestoehr (talk) 03:46, 27 November 2021 (UTC)

File:Std_SetAppearance_taskpanel.png

See: https://wiki.freecadweb.org/User_talk:Roy_043#File:Std_SetAppearance_taskpanel.png

Again see: https://wiki.freecadweb.org/User_talk:Roy_043#File:Std_SetAppearance_taskpanel.png

One is automatically informed when you reply to a topic one started in your discussion page. (Signing the topic also automatically adds the page to the watch list.)
--uwestoehr (talk) 20:48, 27 September 2021 (UTC)

You did not like my rewording of the new Navigation cube settings (Preferences_Editor)

What prompted my edit was the poor English of your original text. I will not put my edit back, you are obviously very touchy about this. But I do suggest you have another look at it. --Roy 043 (talk) 20:08, 6 May 2021 (UTC)

Thanks for the info. I only see this change from me: https://wiki.freecadweb.org/index.php?title=Preferences_Editor&diff=872718&oldid=872381 , so I added info. The reason is that I authored this feature and there were several discussions in GitHub and the forum what the default actually does and why this is the default. Thus I added this info. --uwestoehr (talk) 16:58, 7 May 2021 (UTC)
That's the text I mean.--Roy 043 (talk) 08:14, 10 May 2021 (UTC)

Std_TransformManip created as duplicate page of Std_Transform instead of renaming

It is not a good idea to create duplicates of pages. We have seen the confusion this has caused in the case of the TechDraw documentation. It is better to rename the original page and add a redirect. This avoids double work and also preserves the translations of original page. --Roy 043 (talk) 08:24, 30 April 2021 (UTC)

OK. I thought the original page must be preserved since we have users of FC 0.18 who will then not find the page via "What's this?".--uwestoehr (talk) 19:14, 3 May 2021 (UTC)
The redirect will take care of that.

Math and Nowiki

I see that you change <math> tags to <nowiki>, for example here: https://wiki.freecadweb.org/index.php?title=Sketcher_BSplineDecreaseKnotMultiplicity&diff=856101&oldid=854468 But this is not the intended usage. nowiki is typographically spoken verbatim. But math follow the myth typography guidelines (half spaces around operators, italic variables etc.). So math should be used for equations. nowiki only for text to be unformatted.

(For information, you can directly copy TeX code into <math> and this can be created even with Word or Libreoffice nowadays.)

thanks and regards --uwestoehr (talk) 13:10, 21 February 2021 (UTC)

You are overlooking a very important issue. AFAIK nowhere in the wiki are math tags currently used. Incode is typically used instead. So what you are doing is introducing an inconsistency. IMO this should be avoided if in anyway possible.
--Roy 043 (talk) 15:50, 22 February 2021 (UTC)
I don't understand your argument. The Wiki software we use provides the <math> tag for good reasons. That we don't already use it cannot be an argument. In contrary the opposite should be - it is time to use it now! For example we have a lot of pages where a proper formula would explain than long text. (Just imagine how one would write formulas like these.)
And I don't understand why we should use a verbatim formatting for formulas. <incode> is intended is for programming code, which is indeed verbatim. But math is definitely not verbatim ;-). Please don't let us reinvent the wheel but use the available tools provided by MediaWiki.
--uwestoehr (talk) 18:16, 22 February 2021 (UTC)
I think you do understand. Let's not play a debating game. To ensure that the wiki is consistent it is important that editors follow the standard and examples set by previous editors. Introducing new features and tags that are not used by anybody else should be avoided. It is not about who knows best, it is about following a standard.
--Roy 043 (talk) 17:09, 23 February 2021 (UTC)

> I think you do understand. Let's not play a debating game.

No I do not understand you and you haven't told a concrete reason what problem you actually see or fear. And sorry, but I am not playing games, I debate and have valid arguments. Please don't debate by arguing the other should not debate.

> Introducing new features and tags that are not used by anybody else should be avoided.

So you tell me, "please stop any progress, we make a mistake for years. We cannot fix it, we must continue doing it wrong - consistently wrong." So again, what is a reasonable reason not to use a Wiki tag that is widely used for years in e.g. the Wikipedia and many other Wikis? And why should we continue to forbid users to write formulas? I cannot see any "bad" side effect. Please tell me. --uwestoehr (talk) 18:05, 23 February 2021 (UTC)

How do you propose to make other editors aware of this 'standard' that they do not know? And if this is indeed progress then hundreds of pages will need to be fixed. And nobody is going to taken on that job anytime soon. So at the end of the day what you are doing is introducing an exception, an inconsistency. IMO this is not progress, for if there is one thing the wiki suffers from it is that: inconsistencies.
--Roy 043 (talk) 08:52, 25 February 2021 (UTC)
"How do you propose to make other editors aware" -> We add it to WikiPages
"then hundreds of pages will need to be fixed" -> No change is necessary. Over the time editors will use <math> when they think it is necessary or useful. Existing pages can stay as they are. I think that is the normal way progress is made. Take for example one from the C++ code of FC: std:unique_ptr was once a new pointer in C++ and we use a mixture of ui files using this pointer type and some with the old static pointer. Over the time the change is made - depending of the coder preferences and their time. The same with the Wiki. If an editor thinks <math> is a cool think for the page you wrote or maintain, use it, if not just do nothing. And last but not least, the Wikipedia does and did it the same way. --uwestoehr (talk) 14:41, 25 February 2021 (UTC)

Part WB Docnav

Hi Uwe,

You are correcting what you call typos in the Docnav of the Part WB pages. But the extra spaces you add actually create an inconsistency. Why not follow the existing system used within this WB? Command 'Part_TransformedCopy' results in 'TransformedCopy' in the Docnav. IMO there is nothing wrong with that system.

--Roy 043 (talk) 15:18, 23 January 2021 (UTC)

Hi Roy, sorry, this was not clear to me. I was just wondering because in most of the WBs there is a space. However, I think I only added it for a few pages and I see you reverted it.--uwestoehr (talk) 22:10, 23 January 2021 (UTC)


Hi Uwe, I'm not sure if I'm handling this wiki talk thing correctly. I didn't find a quoting or answering mechanism. So we may better discuss this in the forum, where others can participate.

You wrote: User chrisb recently wrote: "The PartDesign patterns are not yet as optimized as their Draft counterparts. So for a bigger number of instances Draft array is currently the way to go." This is not the case since Draft array is designed to pattern everything, no matter if sketches or parts. The PartDesign pattern is only to pattern feature of a body. So as for all other PartDesign features, it is only working within a body and this works well. For future, user realthunder is working to extend that PartDesign can handle more than one body. However, for now the pattern feature is as powerful as it can be. You are definitely right, that the pattern feature is as powerful as it can be, but only from its concept. There are quite some forum posts where working on a model became unbearable, because computing times were too long. If you have hundreds of instances of non trivial features you have to do something else. This has nothing to do with realthunder's extensions. Draft array is much faster. I had added that section to the wiki after a corresponding forum discussion, so you may search the forum around the change date.

I know how PartDesign patterns work, and that they cannot be replaced without any further changes by Draft array. And reading my changes now, you are right that it can be read as if Draft array can be a simple replacement. I dare to say that it is possible in most if not all cases to use DraftArray together with booleans and avoid PartDesign patterns completely. So I propose to leave the hint to Draft array, and extend it with: This may require major changes to your model.

Fine with me --uwestoehr (talk) 00:52, 4 February 2021 (UTC)

B-Splines

I took pleasure to translate and read this page. thank you.

Many thanks. Also many thanks for the translation!

--uwestoehr (talk) 19:21, 19 September 2021 (UTC)

Icon Part_SectionCut.svg

Hi Uwe, the icon Part_SectionCut.svg is used for the Persistent section cut tool in the View menu. Shouldn't it be named Std_PersistentSectionCut.svg? -- FBXL5 (talk) 09:26, 25 February 2022 (UTC)

"Part_" is correct because this is a feature of the Part WB, despite it is available in the View menu. I will setup a Wiki page describing the feature next week.
--uwestoehr (talk) 16:22, 25 February 2022 (UTC)