I can take a look at this one

I made some progress, the problem is wingpanel as a mandatory dependency, which is not cool.

We could make it not required setting a variable if wingpanel is found and then in the code we can make the wingpanel code conditional if there's wingpanel or not.

meson file:

wingpanel = dependency('wingpanel-2.0', required: false)
if wingpanel.found()
    add_project_arguments('--define=IS_WINGPANEL', language: 'vala')
endif

then in vala files:

#if IS_WINGPANEL
           //stuff about wingpanel
#else
           //something else
#endif

So if I understand this correctly:
if build server e.g. elementary's will have this dep, Monitor will build with an Indicator?

But if it will be built on Flathub, there will be no Indicator in package?
My concern is, if someone installs this package from Flathub on elementary?

Anyway, You can create a test branch, we will see.

If developing for AppCenter, you are now supposed to use the flatpak AppCenter system to distribute the app to people outside elementary too. This means you only package for AppCenter while also possibly for non-elementary OSes. I'm pretty sure there is going to be an API for detecting whether the app is being installed on elementary or not too.

Yes, I'm aware of AppCenter and Flatpak marriage. But I'm not sure about those small details.

I would like to make Monitor available on other distributions, but I do not have much time to dive deep into the Flatpak right now personally.

Any updates on this? Just upgraded to Odin 6x and missing this application. Will build from source for now but obviously having it in the AppCenter would be a win.

@sysfu Monitor packaged as a Flatpak isn't able to show processes and also will not install an Indicator. I'm not sure it deserves to be published without this functionality.

@sysfu Monitor packaged as a Flatpak isn't able to show processes and also will not install an Indicator. I'm not sure it deserves to be published without this functionality.

Fair enough. I tried to build it from source however and ran into another wall with the wingpanel 2.0 dependency bug.

@sysfu did you try to change it to 3.0 ?

Monitor packaged as a Flatpak isn't able to show processes

I noticed there is not a single system monitoring app even on Flathub. Do you know if this is an inherent limitation of the flatpak container or just a funky coincidence? 🤔

@janxkoci that's how Flatpak was designed. It meant to isolate an app from an OS and other apps.

Yes, that's what I suspected. Just wanted to check with a dev who actually faced this issue that this is really the case. So is there any hope for a system monitor app shipped as a flatpak?

@janxkoci only if Flatpak will provide needed apis

You could try snaps. There is a snap version of "gnome system monitor" on Snap Store, so I think its viable.

I don't like snaps. But last week I noticed some system monitor apps on Flathub!

@janxkoci Just installed https://github.com/hakandundar34coding/system-monitoring-center and it looks like everything works from Flatpak 😲 Worth examining. At this point their app is everything I wanted Monitor to be (maybe UI is questionable, but that's subjective).

Updated flatpak branch, but have issue to add new modules. Would appreciate some help.

Having an issue with polkit, which is a dependency for udisks2. Here is more: https://gitlab.freedesktop.org/polkit/polkit/-/issues/187

@janxkoci Flatpak builds. However processes still don't show. I have no idea why it works for others and doesn't work for Monitor 😞 Feel free to tinker

To access processes and other related info you have to use flatpak-spawn. It means it is needed to write special workaround based on ps utility and others to retrieve process info specially for flatpak package. Is it worth it?

Is it worth it?

Well, I lived without this app for a year and found my ways. I don't know about other users, but probably most found a replacement when necessary.

I think it more depends on you, @stsdc as the author. Do you want to work on this app or move on to other projects?

Is it worth it?

I'd say no. If you want to package as a Flatpak, go for it, but keep it to testing repositories. That, for example, is what GNOME's Nautilus file chooser does.

Actual users of these types of applications go bare metal, when you're developing and need an easy way to build and run it, you go to Flatpak. Sandboxes generally don't play well here.

If you want to work around the sandbox, though, feel free to go for it. I wouldn't suggest it though.