no need for a dumb menu item while hoverclock-qt is on

[tinkermakar]

FYI, I have accidentally found out that I can remove all the StatusArea[TOP_BAR_DUMB_INDICATOR] lines from everywhere in your code while I have hoverclock installed and active. IDK what exactly it does, but maybe you can find out more. I am on Gnome 43.

[tinkermakar]

I think I know what's going on. When you bring any window on top of your full screen app with ctrl+tab then your extension will work just fine without the dumb indicator, and hoverclock is essentially just a transparent, non-interactable window on top of everything else, thus it takes the role of that extra window on top. Perhaps you can do the same in your extension? raise some transparent window with these attributes?

[tinkermakar]

The main annoyance of current implementation is not the need to click away to close the top bar, but automatic googling of any top bar menu you accidentally hover over. E.g the entire calendar pops up when you just wanted to see the time if you hover up in the middle

[marcinjahn]

Hi @tinkermakar. Right, I am aware of that. On Wayland, for some reason, panel will not stay on top unless something else is activated. It could be some indicator, which I ended up using, or any window. I did experiment with opening an invisible window initially, and it did work, however, it requires me to spin up a new process every time I do that. It seemed a bit over the top to create a new process every time I want to see the top bar.

Ideally, it would work just like on X11 where the implementation is much simpler. It could be that it will work like that when some Wayland-related bug gets fixed in Gnome Shell/Mutter, or something else.

[tinkermakar]

@marcinjahn how about permanently adding a window once if on wayland upon startup? That would be just one very helpful process

[marcinjahn]

That could probably work, I wonder though, would Gnome Shell overview display that window? Also, what if that window gets rendered on one workspace, and the full screen app is on another workspace? Would it still work? Those need to be checked. I will experiment with that when I find some free time. Contributions are also welcome :slightly_smiling_face:

[tinkermakar]

I'll be glad to contribute, I even tried while tinkering yesterday, but my main problem is I can't find the relevant documentation to see what I can do with Gnome's API. Can you share a couple of documentation links when you have time?

[tinkermakar]

I'll just need to replicate hoverclock's window with the params linked above, but in JavaScript. Their window works just fine for the purpose. And it's always needed only on the primary display, since the top bar is always there

[marcinjahn]

@tinkermakar You could probably have a look at this commit. There, you will find app.js, a simple app example that pretty much just renders the window on screen. It could be further simplified, and made invisible. This line of code was what I used to actually spawn the process with that window.

Things to do would probably be as follows:

• spawn the process when the extension is enabled
• kill the process when the extension is disabled
• make the window invisible, and maybe configured in some other ways to make it work when switching workspaces.

[tinkermakar]

@marcinjahn I have the script for the window, but IDK how to build this app from source code etc. May I contact you on LinkedIn for a screenshare and help me do my first opensource contribution?

Here's the window script:

#!/usr/bin/env gjs

imports.gi.versions.Gtk = "3.0";
const { Gtk } = imports.gi;

const application = new Gtk.Application();

application.connect("activate", (app) => {
  let win = app.win;

  if (!win) {
    win = new Gtk.ApplicationWindow({
      application: app,
      defaultHeight: 0,
      defaultWidth: 0,
    });
  }

  win.set_keep_above(true);
  win.set_decorated(false);
  win.set_skip_taskbar_hint(true);
  win.set_skip_pager_hint(true);
  win.present();
});

application.run(null);

[tinkermakar]

@marcinjahn something weird is happening, please take a look here

When I run the dummy-window.js with gjs directly, it works as expected -- stays on top etc. However, when I trigger it through spawn_command_line_async, then set_keep_above, set_skip_taskbar_hint and probably more does not get an effect. Seems like all the ones that exist in GTK3 but miss in GTK4 get lost, even though the window is generally a GTK3 one. Could that be some xwayland issue? I am clueless.

[tinkermakar]

yes, it was indeed an xwayland issue, I resolved it, opening a PR!

[marcinjahn]

Looks like you managed to resolve the issues before I even came to see that there were any :smile:

[marcinjahn]

Maybe if the app used GTK4, there wouldn't be a need to use XWayland. For now it's alright though I think.

[tinkermakar]

Unfortunately, Wayland API does not allow pinning a window and hiding from the sidebar yet

[marcinjahn]

Thanks for the initiative @tinkermakar. I'll close this issue when the new version gets released in EGO.

[marcinjahn]

Version 8 released, closing the issue