Corners and dash-to-dock

[arielsboiardi]

Hello,
I found a but that took me some time to figure out.
If dash-to-dock (a pretty common extension) is enabled, the rounded corners appear on login (or alt+f2 r on X).
The only way to hide the again is disabling and re-enabling smart-transparent-top-bar, in order to send the

Main.panel._leftCorner.hide();
Main.panel._rightCorner.hide();

and hide them again.

I did not have time to do more test, but it did not happen with dynamic-panel-transparency bu rockon999. I was guessing it has to do with the order or priority in which extensions are loaded (?? really don't know).

I was also looking into implementing the corner transparency, but yeah, it seems a lot of work.

[aunetx]

Thanks for reporting!

I will see how dynamic-panel-transparency does to do the right thing, and maybe I will see why this happens with dash-to-dock (that I use too) :)

I will not do it now (because I do not have a lot of time :( ) but it's just a matter of time!

[arielsboiardi]

Hi, so I did some more tests. I would like to help but my knowledge in this kind of things is pretty limited.

1. I was able to implement a very crude corner transparency. I guess you already tried and choose to avoid it due to the very ugly artifacts in the transition.
   1.1. I think the problem is that corners do not have a transition-duration built in...
   1.2. I would still like to have the ability to show them, but I would wait for GNOME 40 and GTK4 before putting the time into it.
2. dynamic-panel-transparency is really buggy (at least w.r.t. corners) so I would not take it as a reference.
   2.1. He was able to implement a somewhat natural transition to the corners by setting transparency at small time steps, which was a solution I was thinking but it is really convoluted and hacky.
   2.2. Many of the bugs, I think, are due to this added complexity: after an animation the corners are lost and remain transparent, even when set to be visible...
   2.3. I think the reason it seems to avoid the problem is that the corner transparency is not updated on on extension enable but on every event.
3. I gave a look to dash-to-dock and found the problem
   3.1. dash-to-dock checks if the dock is vertical in extend mode and some other conditions. In that case it hide the corners. Otherwise it is hard-coded to Main.panel._****Corner.show() without checking weather their visibility is already set elsewhere.
   3.2 Commenting those line solves our problem but of course breaks a feature of dash to dock.
   3.3 I'll look into a way to perform this check and try tu PR dash-to-dock, because i think this could interfere also with other things (if I'm mistaken please give me your opinion, again I know very little about this stuff).

[aunetx]

Thanks for all of this! This is really helpful :)

I don't know what you think about it, I could implement a way to work around dash to dock changing corners state, but maybe the solution indeed is to simply PR them!

If you decide to do this, then there is no problem any more, or else I will try to find a quick solution in my extension (although I don't know what to do without checking every few seconds, which would be very inefficient ofc)

[arielsboiardi]

Hello, I really did not have time to look into dash-to-dock, ad I ended up removing your extension because, event if it is excellent, it is less necessary to my workflow than dash-to-dock.

After all I think that the responsibility to check is on the extension the re-enables something assuming that nothing else could have changed that setting... Unfortunately my knowledge at the moment is not enough to figure out a way to solve this, so I think I'll just open a bug on dash-to-dock when I'll have time. But I did not understand if you have experienced this bug yourself...

[aunetx]

Okay, I fully understand (dash to Dock is way more important to me too than any of my extensions)

The problem is that it's been 5 months since I last used (and not just tested) smart-transparent-topbar so I just did not paid attention to the existing bugs (as I am not really aware of them)

But don't worry, I will try do fix this myself so you don't have to file an issue on their github page, which would anyway not be really necessary (I don't think a lot of others extensions than mine are affected by this, and mine is really less important than dash-to-dock so it's maybe better just not to bother them with that)

[arielsboiardi]

Since at this point neither of us is using the extension, it seems to be more about the puzzle...

I thought that maybe this can be fixed by disabling corners in the ~/.config/gtk-3.0/gtk.css on enable (if possible), i guess that file has higher priority than extensions loaded at login (?). Again I'm sorry I am not able to test myself, if you cant link me a good reference for these things I can try some time (I could not find anything relevant in the Gjs documentation).

Otherwise we can also call it a day, maybe pointing out that this is a known issue since it drove me crazy for a good half hour.

[aunetx]

Haha yes that's just a puzzle!

I'm sorry to make you work like that, but don't worry I will investigate into my code very soon, ever if this means I come with an ugly solution! After all, maybe we shouldn't search for hours for a solution that can be found by just calling a function whenever I detect dash-to-dock to be launched (which I already do in my current extension, but which may not be enough actually depending on some parameters...)

Well, if I'm not too tired, I will do this tonight! And else tomorrow, you have my word ;)

[aunetx]

Oops, I made a mistake by saying that I already do that, it is about my other extension!

But I will copy some code from it (the one which calls DashBlur.try_blur() on every Dock instance created by dash to Dock), and just hide corners every time :) maybe this is bruteforce solution, but it should work OK!

I'm sorry not having though about it before BTW :/