Related issue: #10770.

Is this really a toggle?
Let's assume the user has a number of objects (in a Std_Part) with different transparencies. Will this implementation allow the user to return to the original situation?

Reading the code I get the idea that this is not the case, and IMO this therefore needs some more thought. Maybe a proper transparency override should be the aim.

Is this really a toggle? Let's assume the user has a number of objects (in a Std_Part) with different transparencies. Will this implementation allow the user to return to the original situation?

Reading the code I get the idea that this is not the case, and IMO this therefore needs some more thought. Maybe a proper transparency override should be the aim.

This is a real toggle, so there is no way to go back to original situation. So for example you have 2 transparent and 2 not-transparent solids, if you select them all and toggle they will all go to not-transparent, then toggle again they go to transparent. But if you want to go back to 2 transparent 2 not, then you have to do it manually. The same as the current kicad tool.

BUT you can revert by using ctrlZ.

What you describe is something like the 'Draw style', which override the transparency property at the viewprovider level. So a change that is not persistent, ie that do not save. IMO this would be more confusing for the user. Especially since you can ctrlZ I don't see the point of a temporary change. But that is up for discussion of course

I agree with @Roy-043, changing the model and/or its properties in any way, just for some temporary changes/state/view is considered very bad practice. Even for basic individual projects this is not okay, but could maybe be by some users somewhat acceptable, but for bigger and especially group projects this is just bad, you don't touch/change the model (or parts of it) without a good reason. In more advanced setups (eg. PLM) where you would get access to only a subset of the model and have the rest read-only, or when all changes are managed by versioning, this would not even work.

The way @realthunder did these things with viewport overrides is a good example of how to do it properly. "View->Persistent section cut" is another example of such bad implementation vs. the "View->Clipping plane" and again proper improvements to it by @realthunder

I have no time to handle the asked feature modifications. Besides not everyone seems to agree on this modification request. But its mostly that I have to focus on assembly right now and on top of that Abdullah is back to work on sketcher to work on offset and co.
So I suggest that perhaps this is added like this, and an issue is opened to ask to change for a temporary transparency modification.

I would guess it comes down to the usecase really.

I am still learning FreeCAD but I usually use transparency to see better what I am doing when the object itself obstructs some of the geometry behind itself, and I cannot, for example, see the sketch I am doing. While this is maybe something Sketcher could also handle better, I think at least this case would be handled with a View mode, like wireframe/solid/shaded/transparent (that could maybe even have some kind of an onion skin style thing, or a slider / mouse wheel modifier binding to adjust the transparency).

The objects also do have transparency among other style properties, like if you make a part that actually is translucent. But I also think changing this property as an operation that both changes all selected objects but also resets them all to the same transparency level might be a bit of a firehose. I mean there might be a case for that too, but these are different things, and at least for me the case is to navigate things better, which would call for a view mode.

And while you can likely achieve the same results by adjusting the properties, it feels like it is done in the wrong place, since it has side effects.

I might well have not thought it throughly yet, but this is my first impression.

While this is maybe something Sketcher could also handle better, I think at least this case would be handled with a View mode, like wireframe/solid/shaded/transparent (that could maybe even have some kind of an onion skin style thing, or a slider / mouse wheel modifier binding to adjust the transparency).

That capability exists.

Is there a possibility to integrate this with the concept of a show/no show space (or group of objects with currently 63% transparency or hidden objects [maybe identified with 0% transparency]). Then switch the visibility between all visible objects and all hidden objects.
viewtopic.php?p=665961

Reference from CATIA: http://catiadoc.free.fr/online/intug_C2/intugrf0220.htm

In order to avoid adding one more button to the toolbar, It has been suggested that :

"Could the the space-bar toggle of visibility be changed to toggle between visible->transp->hidden?"

This sounds good to me. What are your thoughts on that? Visibility is a persistent change. So it it toggle between transparent as well it would make sense for it to be persistent.

Would it make sense to steer the object tree to look a bit more like a layers/objects dialog in other design apps?

Edit: Actually this needs more thought, so we'll discuss this with the design working group and will get back.

After a rather lengthy discussion with the design working group the general recommendation we have to offer is this:

1. Toolbuttons should not be used to modify display parameters for single bodies. This should be restricted to global controls.
2. We recommend the existing functionality of using the space bar as a keyboard toggle for visibility be extended to support 3 visual states. "Normal" > "Transparent" > "Hidden"
3. One of the following options be implemented as the gui control for this toggle.
   • (preferred option) Implement a single icon located to the left of bodies/containers with the 3 states. Normal, transparent, and hidden. Different icons can be used for each state to indicate the setting.
   • (secondary option) add an entry to the context (right click) menu for treeview to directly toggle the transparency.

Below is an example of what is being proposed for the treeview, and if this is implemented, I can draft the 3 icons.

I agree for the space key cycling through.
For the eye icons I'm not sure. For me its over-loading the tree. Linkstage has this I seem to remember and I thought it was a bit heavy.

Ah found it. Here's how it looks :

Hmm so yes not a huge fan. I would rather just put the command in the right click menu.

@PaddleStroke I agree that the linkstage implementation is quite cluttered, my proposal was more limiting. In your screenshot there are a few items of note. The icon is added to everything. Also, linkstage adds other additional icons (up to 3 in addition to the object's type) all over, which again, adds clutter. My proposal was to limit only one extra icon and have it only be present on bodies and container objects. This means: Body, Part, Group, other geometry objects ie Part WB only rather than with features, origin planes, axis etc. that should limit the scope where these are shown.

In either case, menu or indicator in the tree, are acceptable solutions.

Ah yes if icons are only on bodies and container it wouldn't be so bad.
Still this is more work that can happen in a separate PR.
Here I propose that we just remove the toolbar icon and instead add it to the cycling of space bar.
Then in a subsequent PR the right click context menu can be replace by the icons.

I think that is a good plan.

Currently when selecting an object in the 3D view and hitting space bar - the last Part Design Feature is hidden, not the body or part. This makes it hard to see in the collapsed tree view, which items are visible or not. Changing visibility of the body does not toggle the last feature of the body.
Edit: I have created an issue for that: #11132

When some parts, bodies and features are hidden and you activate Toggle Objects (https://wiki.freecad.org/Std_ToggleObjects), bodies that are visible but where only the last feature is hidden get reversed, so that the body is still invisible but the last feature not. So nothing is toggled from the user's viewpoint.
Edit: I have created an issue for this: #11131

Can this be tackled in this approach to toggle the visibility of the whole body, not the last Part Design feature of the selected body?

So it appears that doing thy cycling on space bar is pausing many questions. For simple solids it's very simple indeed.
But for App::Parts, LinkGroups, Groups it becomes a mess.
Let's take App::Part for example. It has a visibility property, but no transparency property.

So currently to toggle the visibility of a App::Part, you change visibility of the App::Part, not of the subobjects.
But for transparency the toggle I made is changing the transparency of the subobjects.

It feels like there're so many cases that it's going to be a big project. As @maxwxyz mentioned before there seem to be many issues and how to handle them is not obvious.

Ok. It looks like we're feature creeping. Should we move this back to draft or merge and improve in a later PR?

Well its for maintainers to decide I guess. I would say merge to avoid rebasing issues.

Leave in right-click menu, exclude the qtoolbutton by default and merge would be my suggestion.

Sounds like a good solution. I did that then. Removed from toolbar

Does not work as expected, shall I create a new issue?

@PaddleStroke @obelisk79 How does "toggle transparency of objects" compare to LS3's "transparency on demand" after clicking on object? From my experience working with LS3 the most usefull feature of making body temporary transparent after selecting a face/edge is the clickthrough feature: you don't have to rotate the body/assembly all around to select all the features you want to modify, you just click through the body. You think that is a bad practice? While coming back to master It seems to me now like working with one eye closed due to to the lack of that feature. Probably have grown to comfortable using it. If this is a bad place to discuss this issue, should I continue it on discord or forum?

I think you probably should open a feature request (github issue) describing what you want. This would be the best place to discuss this.

Small detail: the position of the tool in the View menu seems strange. Why not place the tool after "Color per face". It would fit in that group of commands I think.

This is true, I am not sure what came to my mind when I did this.