Application that should start minimized to systray is opening a window instead.

[Tumbleweeds]

I have two applications that start minimized to systray: Nextcloud-client and KeePassXC, the later works as expected, but Nextcloud-client starts showing its GUI instead. I did some testing on dwm, maybe it will help figuring out what is happening: dwm with no patches shows the GUI when the application starts. dwm with only the systray patch behaves as expected, i.e. starts minimized to systray and no open windows. So, the application seems to be behaving as if dusk had no systray when it starts. Although, other than that, the icon shows in it and everything works fine.

[bakkeby]

How are you starting the Netxcloud client?

If you right click on the systray icon and click Exit Nextcloud and start it again, does it start with a GUI or does it only start minimized to systray?

I'm assuming that this is in the context of the application starting automatically on startup.

[Tumbleweeds]

The issue is not related to automatic start. I did the following tests while not starting it automatically. And I waited 5 min to make sure this was not a timing issue.

• First time Nextcloud-client starts, GUI will show, exiting and starting again will start minimized.
• If I use the systray (clicking on it seems to be enough) before starting Nextcloud-client, it starts minimized. Although techically that is the same test as above since I had to click on the systray to exit the application gracefully.
• If I start and then kill Nextcloud from shell and without ever touching the systray, it will start minimized next time.

[Tumbleweeds]

I did one more test... So far I've been starting Nextcloud from dmenu. But if I start from shell, then it starts minimized.

[bakkeby]

That is interesting. Does it make any difference if you run nm-applet prior to starting the nextcloud client? Just wondering if it makes a difference if it is the first systray application to start or not.

I noticed that nextcloud has the --background option but in my case it always opens a window because I haven't connected it to a server.

[bakkeby]

In any case I'll push through some changes that I did earlier to ensure that the systray window is created and advertised earlier. I don't know if that will fix your issue though.

[Tumbleweeds]

I actuallly never start Nextcloud first. I use another application that starts minimized, KeePassXC, and that has to start first because Nextcloud will use the Secret Service to fetch credentials. So Nextcloud is always the second one in the systray. Also, I thought it could be the systray not being ready when it starts, but I tested waiting 5 minutes before starting with no luck. I don't use the --background, but testing with it made no difference either. Maybe your changes will improve, but based on what you are saying, I doubt it will resolve this issue. But thanks for trying! And many thanks for this awesome dwm fork. I'm really impressed and started using it as my daily driver last weekend.

[bakkeby]

Still interesting that it opens the main window when starting the client via dmenu, but it starts minimized to the tray when you start it from a terminal.

And that it seemingly works if you use a vanilla dwm with the systray patch. I may be able to do some more testing if I can get nextcloud set up correctly.

[Tumbleweeds]

I double check all tests and yes, I can confirm it only works if starting from a terminal. I actually use J4-dmenu-desktop, but changed it to dmenu_run for testing. But it would only work if I either start Nextcloud or dmenu/j4 then Nextcloud from the terminal. I also checked if there were any env variables differences and only found WINDOWID set only on the terminal and TERM=linux instead of st-256colors.

[bakkeby]

If you are checking environment variables then have a look what the window manager has compared to the terminal.

Here is an example for how you an get this information.

/usr/bin/cat /proc/$(pidof dusk)/environ | awk -F"\0" '{ for (i = 1; i <= NF; i++) { print $i } }'

These are what was present when the window manager started, via startx or a display manager.

When dusk (or dwm for that matter) launch dmenu the environment variables are inherited from the parent (i.e. the window manager in this case) so they should remain the same for the program launched via dmenu.

But you say that this behaviour is not the case in a plain dwm with the systray patch so I am thinking that it is unlikely to be due to environment variables.

[bakkeby]

I believe that I may have figured this out.

I set up nextcloud on my NAS and connected the nextcloud client to it. Whenever I start it the nextcloud client starts minimised regardless of how I start it.

I have debug logging enabled so when it starts I see this in the logs.

manage --> client Nextcloud
applyrules: new client Nextcloud (31457309), class = 'Nextcloud', instance = 'nextcloud', role = '', wintype = '406'
applyrules: client rule 21 matched:
    class: NULL
    role: NULL
    instance: NULL
    title: NULL
    wintype: _KDE_NET_WM_WINDOW_TYPE_OVERRIDE
    flags: -9223372036854775808
    floatpos: NULL
    workspace: (null)
    label: NULL
manage <-- unmanaged (Nextcloud)

That is matching on this default rule: https://github.com/bakkeby/dusk/blob/4322d31ab5e639630e2877c7fbaae3af1e0fde6d/config.def.h#L246

If I remove that that rule, recompile and restart dusk and start nextcloud the nextcloud gui is shown centered on the screen. This is because the window is now managed by the window manager.

It looks like it is just a window that is intended to just pop up next to the systray icon, i.e. the position of the window is managed by the program itself.

Presuming that you have removed that rule in your setup. Maybe worth setting up a rule just for nextcloud in that case?

[Tumbleweeds]

Ahh... good catch! I actually had the rule in place, but the DIALOG rule was taking precedence, so the fix was to change the order to this:

    { .wintype = "_KDE_NET_WM_WINDOW_TYPE_OVERRIDE", .flags = Unmanaged },
    { .wintype = WTYPE "DIALOG", .flags = AlwaysOnTop|Floating },

Thank you so much for taking the time to figure it out!

[bakkeby]

Made sense adding this change to the default config as well.