-
-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PoC Flatpak packaging #39
Comments
Hi, thank you for your contribution. I've never used Flatpak before so I don't know how it works. What should I add to README.md to describe installing it with Flatpak?
Yes, I'm planning to make a manager that places into system tray. Creating different debugger sessions would be easier with a manager that is running at system tray, we would easily create different sessions with setting their port and tmux terminal IDs. I really don't have any idea how Flatpak and its packages work. In this situation, what we should do? |
I wouldn't recommend it to users. This is more for evaluating the Flatpak packaging and the usefulness of the app when packaged as a Flatpak. Anyway, building is quite simple, you just need Flatpak-Builder and the Freedesktop SDK. So something like this:
|
Thank you. So you mean It should be published on flathub.org? I'm going to test the package. I will let you know the result. |
Correct.
This would be a pretty nice feature to have, and this desktop integration would make a good case of why Flatpak packaging is fitted for the app.
It might be worth looking into flatpak-spawn if you want to start multiple instances of the app instead of multiple processes in a single Flatpak app instance. |
Sorry for delay. I will look at this soon. What does |
Let's say you have one session of gdbfrontend 1 already running in a Flatpak gdbfrontend app instance A. If you let Flatpak instance B to continue running, and session 2 is not created under Flatpak instance A, then how do replicate this behavior when the user wants to create another gdbfrontend session from the menu of the status bar indicator? or from the webuן of gdbfrontend instance 1? |
You mean Flatpak already has a status bar indicator for apps? As I understand (I maybe wrong) Flatpak has a kind of capsulation for apps? I meant I will make a session manager that allows us creating multiple sessions without command line; a tray icon that has a menu to manage running debugger sessions and create new ones. I will check it out soon. Thank you again for packaging! |
No, I was referring to this
It uses user namespaces, specifically, you need to take in consideration the fact you have a different PID namespace for each Flatpak instance of the app. |
Session manager will have a PID and it will spawn processes for debugger sessions. So I don't think that we need something from Flatpak for spawning debugger sessions. When we close the session manager, it will send SIGTERM to debugger session processes. |
If only a single session manager will be allowed to exist, then there's no need to worry about having multiple Flatpak instance of the app, and all the debugger sessions will be created in the same Flatpak instance / same PID namespace. |
I will make a session manager with Qt but I'm using Windows 11/WSL2. WSLg doesn't support tray icons for now xD but I will make it on Linux soon. Also I will publish the Flatpak package soon. |
I haven't coded anything with Qt, so I'm not exactly sure how Qt is handling the status icon, but from my experience as a user and looking at D-Bus (with Bustle, D-Feet), I can tell you the following. Make sure to use a reverse DNS naming scheme as a prefix for the tray icon name, so it will be exported by Flatpak and be available to the host as part of the icon theme. Without doing so, users with status bars that don't support the old XEmbed protocol, and using instead the StatusNotifierItem (SNI) protocol, might not see the icon and will have a default blank icon. SNI is using D-Bus as IPC, and from what I've seen it can handle a status icon as a pixmap element in D-Bus, a name of an icon from the icon theme (why the icon should be exported), and the full path to an icon file. In the latter case, it's possible that the icon file path will only be accessible from the Flatpak sandbox, and not from the host, and then the status bar won't display the icon correctly. Again, I'm not exactly sure what Qt is doing, but I'm guessing here that it probably would be best to load the icon with As one who uses Waybar, I had too many issues with SNI and Qt5 apps, and while I should, I didn't look further into this. I believe that KDE users shouldn't be affected as it ships with XEmbed to SNI proxy, but Gnome users might, and definitely users like me who use a Wayland window manager instead of a desktop environment. If you need further guidance and recommendations, then I suggest dropping by the |
So, we don't have any way to use Flatpak for only installation of our app? What if we don't want any sandbox stuff?
Yes.. I will ask about it. Thank you again. |
Hiiii again @tinywrkb sorry for late response but I don't much time 😿 Could you publish this Flatpak package somehow? Otherwise, I had to understand how Flatpak works exactly. As I remember, it is doing a kind of isolation but I don't know exactly. I would be happy if you could contribute about publishing the Flatpak package. |
This is a quick Flatpak packaging, and without much testing.
As far as I can tell, this would be mostly useful for remote debugging, and debugging with the Flatpak runtime.
I'm not sure how GDBFrontend works, but maybe it would be also possible to access GDB on the host using a host running tmux session. I haven't tried this as I don't have GDB on the host, and my system is immutable.
Another possible alternative is to have a flatpak-spawn wrapper executing GDB from the host, and have GDBFrontend select the wrapper instead of the default GDB executable.
A few notes about the packaging:
--runtime
option, it's possible to run the app with another Flatpak SDK that is based on the same version of the Freedesktop SDK.home
filesystem access might seem superfluous, but some of us users globally block permissive permissions, so I think that being explicit is more correct.app-id
ascom.oguzhaneroglu.GDBFrontend
.The text was updated successfully, but these errors were encountered: