The ability to organize your list items on the platter and with groups

[jasonhartsoe]

Is your feature request related to a problem? Please describe. Yes. You cannot move up or down any of your items or group them.

Describe the solution you'd like IN the list box, it would be great to organize your modifiers, parts, options, etc. I'd like to see the ability to move the items up or down in the list by dragging and/or clicking up/down arrows. This way you can organize your view exactly how you want it. It would be great to also add groups as well. With the ability to add group under group under group etc. So groups under groups as well.

Describe how it would work You can click, hold, and drag your modifiers/items/parts, etc. up and down in the list box wherever you want to place them. which clicking on the item, there could also be arrows that appear where you can move up and down...or that are already there but greyed out until you click the item. The arrows can move it up and down in the list as well. I'd also like to see the ability to create groups as well. This way you can organize your list better to suit your needs. All options for the group will be the same as each individual item as well. You can move the groups up and down. Disable the groups, make the entire group invisible(previous feature requests for these) and so on.

This would only apply under each parent item. You would not move the modifiers/parts/objects/child items outside of their parent items. So lets say you have a parent item/part, and under it several modifiers and objects. You can organize and group the modifiers/objects, but they will remain organized under that parent item only. You can also group/move up or down the parent items but all child items will remain with it and will not get removed. You also cannot remove child items from the parent by dragging/moving. So each item remains with it's respective parent...and you can move/group parents leaving all child items intact.

Describe alternatives you've considered No.

Additional context Thanks!

[neophyl]

There is a reason they are in that order. That's the order that the various operations are applied. However you can reorder them, you just have to change a setting to be able to do so. Preferences (Cntrl+P) and then GUI>Order object volumes by types.

The tree is also the primary indicator for if meshes are either Parts or Objects. This is a very important distinction in PS. When changing these like splitting to parts or merging objects its the only way to track that.

To do your proposed change would also require alternatives for all that functionality to be rethought and reimplemented.

[jasonhartsoe]

I'm not sure you understand or confused with my request. It's a simple request and has no effect on anything you just mentioned. They aren't in order of any usage, or required to be in any specific order. i can create the order anyway I want. As for organizing them, there is already the ability to move them up and down, it's just not elegant or shows you where it's placing them. SO that alone defeats the contradiction you just mentioned since the ability to do so already exists. As for placement. It doesn't matter what order they're in or arrange them to be. When it slices it's based on Z location. Has nothing to do with the listbox items and their locations. They are just the reference to where they're placed in code. We aren't changing code here. We are changing the visibility of the list items to view. Nothing to do with the application gcode generation or changes to the gcode whatsoever. So no, it wouldn't require some major change or implementation.

I think you're over thinking it here. As for the meshes, obviously you wouldn't move those, etc. I understand a bit of your thinking here. Of course things like meshes and parts/objects would still remain under their respective parents. Maybe I should clarify above, but I'd assume anyone who is responsible for this area would already have known my request. So you can understand:

If you have a parent item, and under it a few modifiers and some parts/objects, etc...you can move/group them under that parent item only. And so on. I was NEVER referring to moving these outside of their respective parents which would indeed cause issues as they would no longer apply to the correct placements. Above, as you can see it's all under one item here...so you can easily move them up or down, and grouping if we could. The real benefit would be if I have a lot of parts, and I want to order my parts (which would be the parent items where other items fall under)...so I would move the parent items in groups or up or down, while the respective child items still remain under them. You can only organize and group under each parent/child item...but not move them outside of their parents.

[Snuff1eupagus]

@jasonhartsoe

It would have an effect on the things @neophyl mentioned. You have a multipart request here. Some of what you have requested is already possible in PS. @neophyl has shown you the way, take the time to learn what he has offered. Then reexamine your request. You're missing some major functionality here, that you already have. Frankly a better alternative would be to offer clipping between Objects. This is about position in the object pane and Hierarchy on an object basis and it's you @jasonhartsoe who are not understanding.

[jasonhartsoe]

No I indeed understand exactly what I requested, It's you all who don't...and by your response it clearly shows you are not aware of what I'm asking as that functionality does NOT exist. So You too have misunderstood here. The request is indeed hierarchy, but without removing respective childs. It would NOT have any effect as it doesn't today. You are able to move some items up and down, but without it showing any active response....but you cannot move everything, nor group items, etc. Which would NOT effect anything. Your assumption is in not understanding or likely having never wrote code in your life. Regardless, just because it can be moved, doesn't mean it's going to mess anything up. You are assuming here they won't compensate for the changes to work as intended and just add some organization properties....and list order. I assure you, they would not only create the ability to order, but also assure it doesn't affect functionality. Your limiting the functionality and their ability to write code here without understanding how things work on the backend. DOn't take offense to this, I'm just being blunt as I've been writing code for nearly 30 years. Even when you move what can be moved, it has no effect period. And ordering a child item under a parent also will have no effect. Once again, you're limiting your understanding here...and lack there of.

Say you have the following:

My Part --Ironing --Generic Slab ----Infill,Ironing --Seam --Generic Box ----Parameters

Etc.

Since I have to make it clear to those who can't view it without an example, you would NOT in this case move Ironing inside the generic slab, nor would you move the seam or ironing under the generic box. It would retain all groups/parent/child/relationships and I assure you, the dev team would understand the purpose and what's needed to maintain this so there's no confusion. As everything you two have stated is not only incorrect, but not understanding the request at all. You're also making the assumption the dev team wouldn't understand that restrictions would need to be in place and how to update the code to reflect the proper use. This is standard in about every list item box or tree and understood you wouldn't place things where they don't belong. Your assumption they wouldn't understand this or not part of my request is misunderstood here.

So they can move things like so:

My Part --Seam --Generic Slab ----Infill,Ironing --Generic Box ----Parameters --Ironing

(Make sure you're following the dashes so you don't get confused again here thinking they're under something when they're not. In other words, Ironing is NOT part of the generic box...it's STILL part of "My Part" only but just moved down to the bottom of the list. It also DOES NOT effect the outcome and the gcode generation is the same for the area and part by placement. It does not generate it at the end and not mess up that functionality. Also, once again, making the assumption they wouldn't compensate to assure it's functionality works as expected.

You can also do something like:

My Part --Generic Box ----Parameters --Generic Slab ----Infill,Ironing --Seam --Ironing

What you wouldn't do are things like:

My Part --Generic Box ----Parameters ----Seam ----Generic Slab ------Infill,Ironing --Ironing

and so on...mixing modifiers, etc. into other modifiers and items that are not part of the parent/child relationship.

As for groups, you can also do something like:

My Part --Ironing --Seam --GROUP LEFT SIDE OF PART (Collapsable) ----Generic Slab ------Infill,Ironing ----Generic Box ------Parameters

Once again, this is a visual representation. It's just a visual reference. It does NOT change the code, the outcome, or functionality of the code and part. You're limiting the understanding here and how it works. You are making assumptions that don't exist. Code will be updated in-order to work properly...and not just updating this box as a single point of reference here. So NO it will NOT cause any issues as they will compliment the code to reflect the changes. If the developers had no clue what they ere doing, then sure, mistakes can happen. But that is NOT the case. And the ordering mentioned above will NOT effect anything except how your organize everything in reference. But again, no issues whatsoever. Your lack of understanding here is what has you confused to my request. As I stated over and over, there are no issues and the backend will reflect the changes. But moving parent items or grouping does not effect anything related to the gcode generation etc. even unto now. None of the order has any effect period. It will still generate the code exactly how it's expected to as it's already laid out by marlin etc on what, where, when, how. It's not going to skip down and generate a parameter code entry at the bottom because the generic box is at the bottom, and not apply it where it's supposed to be and at what Z height/layer etc. It doesn't work like that....which is what I'm assuming you think is happening. That is DEFINITELY not how it works at all. Regardless of order, it still compiles and applies the right code to the right place at the right time no matter what order. Feel free to try it over and over if you have any doubts. I assure you, that's not how it works at all. Which is WHY placement, grouping, etc will not matter....obviously you want to retain the parent/child relationship as mentioned and shown above. Not moving child items under other parents. Nor moving some parents under other parents etc...So please refrain from making any other mistakes and misunderstandings here by not understanding either my request, or how gcode in general is generated by slicing, and prusaslicer in general.