Are you sure?
EDIT: Ah fuck, I miss update the gh lib as well. Yes, you are right!
Updated in the comment above. Thanks mate.
1 Like
Yes, It seems the lagging when zooming definitely goes away. 
But I found some weird behavior when I zooming in with riched capsules checked. If I switched to âDraw Full Namesâ mode when zooming, as you can see the components in the zooming area wonât be enlarged.
And then I quit âDraw Full Namesâ mode, the components outside the zooming area remain enlarged. and I couldnât fix this until I moved every component one by one.
Hope it would be an easy fix.
I saw something very weird: 
It seems every new componentâs capsule is rendered at the origin, before it is moved by mouse.
Disabling Sunglasses completely is very tedious. It requires clicking âDisplayâ four times and then navigating to each of the three checked âFilter objectsâ and unchecking them, along with âRiched Capsulesâ. After turning them all off and quitting Rhino, I am unable to turn Sunglasses on again!?
Apparently Sunglasses are not visible when using âFile | Export Hi-Res Imageâ?
These was the side effects of my solution to extend the Group border so that they do not intersect the text. It doesnât work and Iâm not surprised. It expands the component boxes before drawing the groups and returns them to their original size after that stage (before drawing the components). I have tried several different ways without success, so I removed that feature.
Just click on Sunglasses to enable or disable it, two clicks. The filters are for customization and should only be used once or rarely changed. How can I reproduce that the menu is turn off? I have not been able to.
If that is so, it seems that GH does not call all drawing events.
UPDATE HERE, LAST TEST BEFORE I PUBLISH IT. 
Sunglasses.gha (190 KB)
Thanks!
2 Likes
It seems flawlessly working for me without previous problems so far⌠
I think it was worth a try. Thank you for your attempt .
Also here everything seems fine. Super!
Plugin updated to v1.1.0, please donât use the WIP versions of the comments, delete them and install it from here:
GH tool bar > Display > Sunglasses > Filter objects > disable Special or put the names in Exclusion.
1 Like
Hi @Dani_Abalde. Iâve been using Sunglasses for a while now and absolutely love it! I use the naming mainly for parameters to keep everything nice and tidy.
I noticed that the True-only button from Pancake displays its name, even when I filter only by parameters. Not sure if its something you or @gankeyu would have to fix, but it seems like its classified as the wrong thing. As you can see for a normal button the name is not showing like it should.
The native button belongs to the Special category because its object is inside the Grasshopper.Kernel.Special namespace. Any other button outside Grasshopper.dll, Sunglasses interprets it as IGH_Param and therefore in the Parameters category.
I think the best thing to do is to include the name (or nickname) of the Pancake button in the exclusions category.
1 Like
The best thing is probably to maintain a list and have a public API so that other plugins can re-define the category of some customized objects. ObjectFilter would follow that definition if the object is found in the special list. Itâs slightly better than exclusion list as it requires less manual intervention.
@Dani_Abalde Another thing that would be amazing would be an Include list, rather than just an exclude list.
I use a ton of Stream Filters wherever there is an option and it usually really helps to name those. Since it is just a component, but I otherwise donât want/need the name of every component, I would like to enable it for just that one component.
What do you think?
1 Like
Doesnât it take less time to exclude the ones you donât want than to include the ones you do want?
Maybe some solution that uses the component instances instead of the component type could be useful, but I donât see any quick way to do it because it is not how it currently works.
I donât need to see the names for any of the âcomponentsâ, except the Stream Filter. I canât reasonably type literally every component in there and just leave out âStream Filterâ. Surely, it would make just as much sense to have an include list, so you can leave a category off, but include certain components.
Stream Filters act as a kind of switch and donât have a specific meaning other than in the context they are being used. That is why they are different to most other components and it makes a lot of sense to label them. It makes reading a logic much easier if you can always see WHAT trigger it is connected to.
Take this example. There are 11 Stream Filters switching different options. I would love to be able to see over each one what it is they are switching.
I hope that makes sense.
Here it is again with the proper names for each Stream Filter. I donât need to see the names of any of the other components though.
I see. In that case you should put your filters in a transparent named group, you donât really need Sunglasses for that use case.
True, thatâs what I have been doing till now, also for Parameters, but I prefer the way Sunglasses shows it much more, since it looks way cleaner and we can turn it off if we donât want to see it.