View Issue Details

IDProjectCategoryView StatusLast Update
0002462FreeCADFeaturepublic2021-02-06 06:50
Reporterpiffpoof Assigned To 
Status newResolutionopen 
PlatformMacintoshOSMac OS XOS Version10.6.8
Product Version0.15 
Target Version0.20 
Summary0002462: Manage Object Display Order in Tree View
DescriptionThis feature request is especially pertinent to models involving large numbers of objects.

Under current versions of FreeCAD there is no option to specify in which order the objects shall be listed. Often an operation on an object will result in the resultant object (i.e. the outcome) being placed at the bottom of the object list. If the operation (e.g. Cut) is deleted than then objects previously held within the Cut are placed either at the end of the object list or at the the end of the Group (if the objects are within a Group). Where to look for the results of your operation? It is not always predictable.

With large collections of objects, methods to manage the objects are required. One method is by creating Groups and placing objects within them. Yet with large object collections even the number of objects in a Group can be daunting. Especially if operations can remove objects from Groups.

When working with a large number of objects such behaviour can be very annoying. Objects being worked with can be placed at the bottom of the object list, often off the screen.

There are numbers of potential solutions to this, I've a generic approach here:

Right-click in Tree View to Select Object Listing Order
The user could right-click to select one of the following sort orders:
- as is (i.e. the way FreeCAD lists objects in 0.14 and 0.15)
- alphabetic
- user determined order (i.e. user drags objects to desired place in the list)

If the ability to sort objects alphabetically were available through a right-click menu option, then the user would at least know where in the list of objects to direct his attention to locate an object.
Additional InformationAs an example, with initial testing of the Open Street Map data importation by Microelly2, over 500 buildings can be imported. Obviously these can all be placed into a Group named "Buildings" but the problem simply happens again within the Group. With the current versions of FreeCAD the objects are listed in the order of creation, and then the ordered can be modified by certain object operations. So looking for Building 357 requires searching the complete list of 500 buildings
forum thread is
TagsNo tags attached.
FreeCAD Information


has duplicate 0002124 closed FreeCAD Unable to order the list of parts 
has duplicate 0001730 closed PartDesign objects in the object tree cannot be reordered 
child of 0000922 assignedrealthunder FreeCAD Topological Naming 



2016-03-02 17:41

reporter   ~0006878

Last edited: 2017-11-06 13:11

Thanks for detecting the duplicate Yorik - I didn't find that one.

I have read Shawn's feature request (0002124) and it is basically the same as this one. I also read Werner's reply.

In reading Shawn's feature request, I think he makes a good point in that such an ordering is standard in commercial packages (at least those I have worked with, I can't speak for all packages). I would also point out that scaling FreeCAD to large projects (large in the sense of being comprised from a large number of objects) is not going to be easy unless some presentation layer is introduced to manage GUI presentation of the object structures.


2016-03-06 20:25

manager   ~0006889

But Shawn underscores the difficulty of adding such functionality. Safeguards must be added to prevent the end user from borking his model. In short: the system must not allow the user to reorder a feature to place it on top of a feature it's based on. This is no easy task to implement IMHO.

One thing that will help with large projects is the work in the PartDesign-Next branch, and eventually Assembly wb allowing multiple document types.


2017-11-06 13:18

administrator   ~0010391

Last edited: 2017-11-06 13:20

Merging part of 0001730
See 0001730:0005481 and 0001730:0009438
Ultimately this issue relies a lot on Topological Naming which has been an ongoing issue for a long time.


2018-06-10 13:25

administrator   ~0011393

@realthunder responds in


2022-03-03 13:55

administrator   ~0016478

This ticket has been migrated to GitHub as issue 5643.

Issue History

Date Modified Username Field Change
2016-03-02 11:15 piffpoof New Issue
2016-03-02 17:25 yorik Relationship added duplicate of 0002124
2016-03-02 17:41 piffpoof Note Added: 0006878
2016-03-06 20:25 normandc Note Added: 0006889
2017-01-17 19:49 Kunda1 Relationship added related to 0001730
2017-11-06 13:08 Kunda1 Relationship replaced has duplicate 0002124
2017-11-06 13:11 Kunda1 Note Edited: 0006878
2017-11-06 13:14 Kunda1 Relationship replaced has duplicate 0001730
2017-11-06 13:18 Kunda1 Note Added: 0010391
2017-11-06 13:19 Kunda1 Relationship added child of 0000922
2017-11-06 13:20 Kunda1 Note Edited: 0010391
2018-06-10 13:25 Kunda1 Note Added: 0011393
2021-02-06 06:50 abdullah Target Version => 0.20