App::Link: the big merge

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
user1234
Posts: 181
Joined: Mon Jul 11, 2016 5:08 pm

Re: App::Link: the big merge

Postby user1234 » Tue Aug 13, 2019 3:44 pm

Hello!
realthunder wrote:
Tue Aug 13, 2019 1:46 pm
It will be easier if the properties are displayed with sorting by name
I know, you do not ask me, but i, as a user, think, that is a bad idea. Properties should be always sorted by their functions.

Found a other small, but in my opinion important bug.
It is standard in all programs, that you can rename things with F2, also in FreeCAD (master branch). But in this branch (App::Link functionality PR#2350) git commit 7da1bc5789d51c2ede74068b8e16e5a46a6d50f5 you can only rename things, when you click two times on an object and then press F2. This i think is not ok. And when you rename something, it came also an expression icon. Is this intended (the expression thing)?

Sorry annoy you, but i think this must be fixed (no offense).

As i see in the PR, i must compile it new, thanks for your work!

Greetings
user
Attachments
test2.FCStd
(94.83 KiB) Downloaded 11 times
_rename.webm
(338.02 KiB) Downloaded 9 times
wmayer
Site Admin
Posts: 14637
Joined: Thu Feb 19, 2009 10:32 am

Re: App::Link: the big merge

Postby wmayer » Tue Aug 13, 2019 6:02 pm

My intention is to make FreeCAD object more dynamic, like Python object, where the user or programmer can freely add or remove properties for their own use.
With the FeaturePython classes this is possible for a long time already and the property editor could handle this just in time without un-selecting and re-selecting the object. The new thing is that this will be possible for C++ based feature types, too.
So if the property view displays by creation order, it is kind of harder for the user to control the display order.
I have to look at the code again and check what exactly makes the order criterion. E.g. for some types like a Part::Box the order is Length, Width and Height but for most other types the properties come in alphabetic order. Anyway, the most important point will be that dynamically added properties appear in the correct group and not just at the end -- just in case this doesn't work any more.

But from my point of view these are all things that can be fixed once the PR is merged into master which I think will happen by the end of this week. I also have noticed many regressions, bugs and crashes and there is no need to fix all of them before the merge because this only delays it more and more.
user1234
Posts: 181
Joined: Mon Jul 11, 2016 5:08 pm

Re: App::Link: the big merge

Postby user1234 » Tue Aug 13, 2019 7:08 pm

Hello!
wmayer wrote:
Tue Aug 13, 2019 6:02 pm
I think will happen by the end of this week
Many thanks for your work!

The one continuity issue, i wrote before (this is no stumbling block, only a suggestion):
When i place an array or make a group with links, then the original object raises in its origin and you do not see (at a glance) from where are the links, while working on a larger file. For parts and bodies that is not very important, because this is easy manageable. But if you work with the Part Workbenech, Draft Workbench, or other Workbeches with many small tree-unsorted elements in it, this can end in a mess.
_expand_array.webm
(207.89 KiB) Downloaded 12 times
(As you see in the *.webm , the hightlight error still exist still for me, i do not know why this is not repeatable for you).

So i have two suggestions (for later when it is merged):

Suggestion one:
I know from other CAD software, that linked objects like you make, have an extra group for linked objects (as far i remember the term is publication).
_suggestion_1.png
_suggestion_1.png (136.84 KiB) Viewed 748 times
Suggestion two:
Sub objects like the screenshot and the original object vanish from the tree. And when you delete all links, the object raises in its origin. But i think that is not possible.
_suggestion_2.png
_suggestion_2.png (179.59 KiB) Viewed 748 times
As i say before, this is no stumbling block. In the end every user is responsible himself to sort his work. I see that all what you have done as prework for assembly. Opinions from other users would be good, if this is a good workflow.

Also i found a very small bug:
When i link with array a linked group, i get

Code: Select all

('[Draft.todo.commit] Unexpected error:', <class 'AttributeError'>, 'in ', ['obj = Draft.makeArray(FreeCAD.ActiveDocument.LinkGroup,FreeCAD.Vector(1,0,0),FreeCAD.Vector(0,1,0),2,2,useLink=True)', 'Draft.autogroup(obj)', 'FreeCAD.ActiveDocument.recompute()'])
, but it works.
_link_array_group_link.png
_link_array_group_link.png (169.93 KiB) Viewed 748 times

Many thanks you for your work!

tested all with:

Code: Select all

OS: Debian GNU/Linux 10 (buster) (X-Cinnamon/lightdm-xsession)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.Unknown
Build type: DebWithRelInfo
Python version: 3.7.3
Qt version: 5.11.3
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: C/Default (C)
git commit 1816b84cb1ace8d84508f4e75788a354e68a5bbc on PR App::Link functionality #2350

Sorry for bad english
Greetings
user
realthunder
Posts: 1106
Joined: Tue Jan 03, 2017 10:55 am

Re: App::Link: the big merge

Postby realthunder » Tue Aug 13, 2019 10:28 pm

user1234 wrote:
Tue Aug 13, 2019 3:44 pm
I know, you do not ask me, but i, as a user, think, that is a bad idea. Properties should be always sorted by their functions.
There are groups of properties, which are intended for functional grouping. What I meant is to sort the properties by name within the same group.

Found a other small, but in my opinion important bug.
It is standard in all programs, that you can rename things with F2, also in FreeCAD (master branch). But in this branch (App::Link functionality PR#2350) git commit 7da1bc5789d51c2ede74068b8e16e5a46a6d50f5 you can only rename things, when you click two times on an object and then press F2. This i think is not ok. And when you rename something, it came also an expression icon. Is this intended (the expression thing)?
Hmm... I cannot reproduce this. In my linux build it works with a single click and F2. Can you click Help -> About FreeCAD -> Copy to Clipboard, and paste your build information here.

As for the expression icon, yes, this is intended. You can use expression binding to dynamically change the object label.

Sorry annoy you, but i think this must be fixed (no offense).
No need to be apologetic. Bug reports are always welcome.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
user1234
Posts: 181
Joined: Mon Jul 11, 2016 5:08 pm

Re: App::Link: the big merge

Postby user1234 » Tue Aug 13, 2019 10:47 pm

Hello!

tested all with:

Code: Select all

OS: Debian GNU/Linux 10 (buster) (X-Cinnamon/lightdm-xsession)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.Unknown
Build type: DebWithRelInfo
Python version: 3.7.3
Qt version: 5.11.3
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: C/Default (C)
git commit 1816b84cb1ace8d84508f4e75788a354e68a5bbc on PR App::Link functionality #2350

Maybe it is Qt related. Also it could be that the locale setting Locale: C/Default (C) makes the error. Also my file manager does not like the locale setting. I must test it on my other system, but at the moment a have no access to it.
realthunder wrote:
Tue Aug 13, 2019 10:28 pm
There are groups of properties, which are intended for functional grouping. What I meant is to sort the properties by name within the same group.
OK, this makes more sense. But when you work a lot with properties (like me), it is very unhandy always to expand the groups in the property tab. If there is a general option, that always expand the groups in the properties, it would be ok. But at the moment, there is not such an option.

Greetings
user
realthunder
Posts: 1106
Joined: Tue Jan 03, 2017 10:55 am

Re: App::Link: the big merge

Postby realthunder » Tue Aug 13, 2019 11:52 pm

user1234 wrote:
Tue Aug 13, 2019 7:08 pm
The one continuity issue, i wrote before (this is no stumbling block, only a suggestion):
When i place an array or make a group with links, then the original object raises in its origin and you do not see (at a glance) from where are the links, while working on a larger file. For parts and bodies that is not very important, because this is easy manageable. But if you work with the Part Workbenech, Draft Workbench, or other Workbeches with many small tree-unsorted elements in it, this can end in a mess.
From you description, I think you have some confusion of the link's behavior. When you create a simple LinkGroup (not draft array), and drag object inside, the object actually moves into the group. If you are dragging the object out of some parent, by default, it will first be removed from that parent. To avoid affecting the original object in any way, you can create a Link to that object, and then move the Link into the group.

The 'Draft LinkArray' is NOT a group in its default state (i.e. when the elements are not expanded), so it does not remove the base object from its original parent. But, to avoid visual confusion, it does auto hide the base object when the array is created. The child object under the array is the original base object. This behavior is similar to Part Fusion/Cut/Common etc. When you expand the elements, however, it becomes a group, but only to hold the auto created Links to the base object. To find out which object the Link links to, you can right click the Link, and choose 'Select linked object'. There are more action available under the context menu group 'Link actions'.

To help navigating among large tree, there are also the 'Back' and 'Forward' command, which allows you to jump back and forward to your previous selections. I didn't expose them to avoid confusing the user with the existing back and forward command in Web workbench. I probably should expose them somehow. Anyway, you can bring them out using 'Tools -> Customize -> Toolbars -> View'. You can opt to add the button to the 'Global' toolbar, so that the buttons are always shown. The 'Link actions' are also available under toolbar name 'Link'.
Screenshot from 2019-08-14 07-43-02.png
Screenshot from 2019-08-14 07-43-02.png (65.69 KiB) Viewed 700 times
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
realthunder
Posts: 1106
Joined: Tue Jan 03, 2017 10:55 am

Re: App::Link: the big merge

Postby realthunder » Wed Aug 14, 2019 12:06 am

user1234 wrote:
Tue Aug 13, 2019 10:47 pm
realthunder wrote:
Tue Aug 13, 2019 10:28 pm
There are groups of properties, which are intended for functional grouping. What I meant is to sort the properties by name within the same group.
OK, this makes more sense. But when you work a lot with properties (like me), it is very unhandy always to expand the groups in the property tab. If there is a general option, that always expand the groups in the properties, it would be ok. But at the moment, there is not such an option.
Here is what I meant by property group. It is always expanded, maybe you didn't notice it before. The groups are always sorted by the group name. The current implementation displays the properties inside the group by its creation order. What I meant is to sort the property within a group by its property name. So for the following picture, with 'Box' group, it will display as 'Height', 'Length', 'Width'. That's it.
Screenshot from 2019-08-14 07-53-48.png
Screenshot from 2019-08-14 07-53-48.png (21.05 KiB) Viewed 697 times

BTW, there two tabs or properties. The 'Data' property are the object's property. The 'View' tabs are the view object's visual properties. The visual properties are sorted by its name within the same property group. This is the current implementation. And I see this is on purpose judging from the code. I am not sure about the original intention, though.

Screenshot from 2019-08-14 08-00-07.png
Screenshot from 2019-08-14 08-00-07.png (32.45 KiB) Viewed 697 times
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
realthunder
Posts: 1106
Joined: Tue Jan 03, 2017 10:55 am

Re: App::Link: the big merge

Postby realthunder » Wed Aug 14, 2019 12:26 am

wmayer wrote:
Tue Aug 13, 2019 6:02 pm
I have to look at the code again and check what exactly makes the order criterion.
Like I mentioned in the previous post, the property groups are always sorted by the group name. But there is is a differences in the property order in object and view properties. The code responsible of this difference is here. It uses getPropertyList() to get object properties, but getPropertyMap() for view properties.

I guess the original intention is so that the developer has more direct control of property display order. But with the introduction of generalized dynamic property, and especially undo/redo dynamic property adding, this becomes counterproductive.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
yorik
Site Admin
Posts: 11458
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: App::Link: the big merge

Postby yorik » Wed Aug 14, 2019 9:12 pm

I gave the app::link branch a test spin too (used Werner's hand-picked branch), things have improved a lot since last time I tried. There are still many little issues, ex: create a blank doc, create a draft line, the draft line doesn't appear in the tree view until you force some refresh (turn it on/off, delete it...) or IFC export behaving weird (placements messed for some objects), but I think none of what I found are serious or showstoppers (some issues might have other causes too)... If you are willing to stay tuned and help fixing the problems as they appear @realthunder, for me we can do the merge.

Instabilities are to be expected, though, I think we should warn users somehow, before the merge, so they get a chance to keep a "working unstable version"...

It would be great to have a kind of wrap-up of all the new functionality available to users, python coders, etc... It's quite hard to find everything :)
User avatar
Kunda1
Posts: 5205
Joined: Thu Jan 05, 2017 9:03 pm

Re: App::Link: the big merge

Postby Kunda1 » Wed Aug 14, 2019 10:03 pm

yorik wrote:
Wed Aug 14, 2019 9:12 pm
I think we should warn users somehow, before the merge, so they get a chance to keep a "working unstable version"...
Maybe put aside builds for Linux, MacOS, Windows of the last working unstable version before big merge ?
Want to contribute back to FC? Checkout:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features