I’m using the Linux version of WhatPulse 4.0 and, to be up-front, not exactly the snap package directly, but have extracted the binary and execute it natively (i.e., not in a container), since I couldn’t even use snap packages due to lacking systemd. I’m aware that this isn’t exactly supported, but I won’t ever install systemd on my personal day-to-day system, so actually using snapd is currently not an option for me.
Now, most things seem to work just fine (other then per-application network data, which is a known and documented limitation on Linux currently). However, curiously, the client does not seem to pulse any application data, but it does track and record such in the client alright. All of my last pulses include no application data, which sounds weird, given that I can see application statistics within the client just fine, including, e.g., usage graphs as part of the premium features.
What could be wrong?
I’ve read around, including the help center FAQ posts and places seem to mention a way to re-upload application information via the advanced drop-down menu in the client’s settings tab, but 4.0 doesn’t seem to have such functionality any longer (or at least it doesn’t seem to be available in the Linux version).
Curiously, if I click the “message of the day” part (bottom left label in the client), the window that’s coming up sometimes lists weird things like “There are currently 5 applications running”, but this also drops down to 0 temporarily every now and then for some reason.
While extracting the binary and running it natively isn’t “supported” as you say - it should be fine to do. The only reason why we’re distributing it as a snap is because that takes care of Linux’s dependency hell for binary apps.
As for the application data, I know see that it’s not documented properly, but the Linux client doesn’t support application data at all. Mostly because there’s not a standardised ‘registry’ with data about the app as there is with Windows and macOS. I’m working on ways to pull information about applications from another (internet) source, which might make it possible for us to support Linux apps also.
Yeah, I remember the bad old times of crashing WP clients due to mismatching libraries and can see how containerization (may it be via snap packages, appimage containers or other means) is the only way to provide a way that is almost always guaranteed to work, so no hard feelings there.
Regarding applications: interesting. Yeah, you’re probably right that it’s difficult to straight impossible to get application metadata on Linux in a consistent and convenient way. Heuristics can be used, but only for very basic information like the application type/name, but more advanced things like versions are terrible to discover without Windows’s registry or macOS’s appbundle Info.plist files. I’ve just been confused by the fact that the client is able to detect (some) running applications, like Mozilla Firefox, Mozilla Thunderbird, Chrome or Discord just fine on my Linux machine, but it’s probably not able to match this to any application ID as you’re using internally (the help center entry for that was very informative), so it’s not being pulsed either. That explains that discrepancy. Thanks for clearing that up!
EDIT: appstream is a mature and standardized freedesktop.org spec which may solve most if not all of your concerns about getting app metadata (as most mainstream desktop distros try to follow XDG guidelines)
