search

axxapy / gnome-ui-tune

Tunes overview UI of the gnome 40 a bit
GNU General Public License v3.0
102 stars 10 forks source link

Workspaces goes blank in the overview #30

Closed soumyaDghosh closed 1 year ago

soumyaDghosh commented 2 years ago

This is the same issue as described in #29, I tested that in a clean installation of ubuntu22.04, problem is same.

Screenshot from 2022-09-25 12-35-11

And this is from Ubuntu 22.10 kinetic kudu

Screenshot from 2022-09-29 09-22-22

axxapy commented 2 years ago

I can not reproduce it in virtual machine, so, you have 3 options:

  1. check that you have latest version of extension installed
  2. disable "hide search", open dashboard (it will fix itself) and enable this option back (do same on each reboot)
  3. disable "hide search" completely
  4. Investigate issue on your own and send a PR. Extension files are located at ~/.local/share/gnome-shell/extensions/gnome-ui-tune@itstime.tech. This particular line is responsible for hiding search: https://github.com/axxapy/gnome-ui-tune/blob/master/src/modHideSearchInput.js#L15. You may try increasing delay, for instance (one line above) from 50 to 500 (it's in ms)
soumyaDghosh commented 2 years ago

I got the issue. I use hard-disk-drive, with an average of 150MB/s of RW speed. The virtual machine is in the same hdd. So, may be the dash-to-dock takes more time to initialize. 500ms mostly solves the issue.

martindmtrv commented 1 year ago

For the longest time I thought this was a Dash2Dock issue, but seems like it was caused by some clash here.

I had the same issue and switching it to 500ms seems to fix for me as well.

If I ever get in this weird state, typing in the overview and then returning to the overview (pressing esc) seems to fix it right away without needing to dive in the settings. I wonder if there's any way we can "wait" for Dash2Dock to load up instead of using an arbitrary wait time though

ddnexus commented 1 year ago

For me it fixes it with 150ms. The only problem is changing it again at every update.

@axxapy Couldn't we just have a fixed default delay bigger than 50ms? For example 250ms? That would solve the issue without actually having to investigate anything nor complicate the code.

axxapy commented 1 year ago

For me it fixes it with 150ms. The only problem is changing it again at every update.

@axxapy Couldn't we just have a fixed default delay bigger than 50ms? For example 250ms? That would solve the issue without actually having to investigate anything nor complicate the code.

I mean.. I really feel bad about that kind of hacky solutions with delay... But lets give it a shot. Updated to half-a-second. Released. It will wait 500ms now.

ddnexus commented 1 year ago

Thank you!

I really feel bad about that kind of hacky solutions with delay...

So why there was a 50ms delay anyway?

Btw, the resizing in 2 steps looks more noticeable now with 500ms. I would have used a shorter delay that would probably have the same result with half the delay, however, I think nobody will notice it.

axxapy commented 1 year ago

Fixed in the latest release (exclusively for Gnome 45)