SketchUp / api-issue-tracker

Public issue tracker for the SketchUp and LayOut's APIs
https://developer.sketchup.com/
38 stars 10 forks source link

`active_layer.visible = false` hides the active_layer and sets the other layer to the active (current) layer #945

Open dezmoHU opened 9 months ago

dezmoHU commented 9 months ago
  1. SketchUp Version: tested on 2017Make, 2021, 2022, 2023, ....
  2. OS Platform: tested on W11

Open new model. Create a new tag : "Tag". Set it to active (current) tag: put the pencil icon to right side or use the Tags toolbar. (The Model#active_layer= method in API) Try to hide the current tag via UI, you will get a popup: "You can not hide the current tag." Then the tag wont be hidden. That's okay.

Use this code in Ruby Console:

Sketchup.active_model.layers["Tag"].visible = false

It returns false, hides the active layer ("Tag") and sets the other layer ("Untagged") to the active (current) layer. This is unexpected behaviour. If you create and additional layer (e.g. "Tag1") it is possible that it will be the active layer, but most of my tests the the default (Layer0) get the active (current) state.

Bonus: If you create a "Tag Folder" as a parent of the above mentioned "Tag", then set "Tag" to be the active and execute this:

Sketchup.active_model.layers["Tag"].folder.visible = false

It returns false, This is unexpected return. But does NOT hides the "Tag Folder" (silently fail). This is expected behaviour, but need to raise massage.

See also with ani-gifs here: https://forums.sketchup.com/t/trying-to-create-an-extension-folder-visibility-to-hide-and-show-specific-folders/255416/20?u=dezmo

thomthom commented 9 months ago

It returns false, hides the active layer ("Tag") and sets the other layer ("Untagged") to the active (current) layer. This is unexpected behaviour.

What is the behaviour you expect?

It returns false, This is unexpected return. Why is this unexpected? Ruby setters, methods that ends with =, like visible= will always return the value given to it. This is Ruby magic that will override any return statement that the def visible= might return.

This is expected behaviour, but need to raise massage. Is that what you expected with layer.visible= as well?

I don't think we can change layer.visible= now. That might break some extensions, since it doesn't just silently fail but actually have side effect of setting the default layer active. With LayerFolder.visible= we might get away from introducing an exception...

But can you clarify further what you expected?

dezmoHU commented 9 months ago

I must have to agree: Setter methods always return the value that is passed in as an argument. So ignore my comments about it, I'm still in a learning stage...


My expectation would be that both methods behave as the user sees in the UI.

cant_hide_UI

So the LayerFolder.visible= method act like this, therefore it is let say okay. (However would be nice to mention in documentation, that you can't hide the folder containing active/current Tag )


I expected that layer.visible= false would not hide the active layer, like in the UI, and like layerfolder.visible= false . But especially I didn't expect to change another layer to the active layer. If this is the case - and it is - then it must be mentioned in the documentation.

I mentioned above:

If you create and additional layer (e.g. "Tag1") it is possible that it will be the active layer, but most of my tests the the default (Layer0) get the active (current) state.

I cant reproduce it right now, but I wouldn't have mentioned it if I didn't see it. (Actually, I could be wrong...and I've seen ghosts... :-) ). So I'm not sure if "setting the default layer active" is always the case as side effect, or other than the default layer will be set...?!

thomthom commented 9 months ago

It's always risky to change API behaviour after its released. As long as there is way to do what you need. This might have to become a documentation issue to clarify behaviour and examples.

Basbva commented 6 months ago

In the same thread dezmoHu mentioned I responded to above remarks with the following remark in post 37 of that thread.

When I want to hide the 'active_layer.folder' and enter Sketchup.active_model.active_layer.folder.visible = false it returns false but fails to hide the folder. Meanwhile in the UI I manage to accidently hide the 'active_layer.folder'. Are those two phenomenons not related?

Reason seems to be to override the 'hidden' status of the folder for the active_layer.folder to remain as is. This could also be clarified in the documentation, as a reason to select a specific layer.

thomthom commented 3 months ago

When I want to hide the 'active_layer.folder' and enter Sketchup.active_model.active_layer.folder.visible = false it returns false but fails to hide the folder.

As mentioned above, any setter method (ending with =) in Ruby will return the value it was given. This is Ruby doing its magic and overriding anything the code might try to return.

This is however marked as a documentation issue for clarification.

Meanwhile in the UI I manage to accidently hide the 'active_layer.folder'. What are the steps for that?

Basbva commented 3 months ago

Meanwhile in the UI I manage to accidently hide the 'active_layer.folder'. What are the steps for that?

Make a tag active, in the tags window, in a hidden folder and the folder becomes visible. Undo once and the folder becomes hidden again while the tag (active_layer) remains the active tag. Fully functional, albeit invisible.

kathstenby commented 3 months ago

We have opened this issue SU-57460 to address this bug. Thanks, Kath