[Feature] Create a flag to allow multiple instances of the tray icon. #2095
Labels
Comments
|
This could look something like this (example for the tray) and would work because the flags are represented as a single integer which are bitwise OR'ed together (and class BluemanTray(Gio.Application):
def __init__(self) -> None:
app_flags=Gio.ApplicationFlags.FLAGS_NONE
if (ARGS_HAS_MULTIPLE_INSTANCES) # This needs implementation
app_flags=app_flags | Gio.ApplicationFlags.NON_UNIQUE
super().__init__(application_id="org.blueman.Tray", flags=app_flags)
# ... |
|
One additional note slightly unrelated to this PR, the Gio docs state that According to |
|
If I get it right, you do have a single D-Bus session bus for multiple desktops, right? Why do you think we need multiple applet processes? One issue that immediately comes to my mind is that only one of them can register the default agent with BlueZ so that only one of the desktops would receive authorization requests and the like. I absolutely can imagine multiple tray instances with a single applet instance, though. Being curious: What's your experience with other "tray applications" and multiple window manager instances? |
|
I don't particularly need (or want) multiple applet processes, however I figured it might take slightly more processing to launch several trays vs just brute force another applet. Honestly, D-Bus is a mystery to me. I'm running My experience is exactly half and half funnily enough. |
|
A few other applications (albeit daemons) that allow multiple instances that I use are: While it's not super common that I run multiple instances, as I usually just use workspaces (like a sane person 😄), it is useful for debugging my WM, and when I'm struggling with Awesome, It's helpful to have full access to the remainder of my system controls in my system bar. |
|
The current design is that the applet (re)starts the tray. It's not trivial to change this. |
|
Yes, I absolutely would not expect it to work out of the box either, e.g. I don't think the communication between one applet instance and multiple tray instances would work as intended. Anyway, you do seem to have one session bus per desktop. so it's obvious that we'd need one applet per desktop and applet <-> tray would still be 1:1. I just tried and actually What issue do you run into? |
|
prefixing Desktop 1: `> blueman-applet --loglevel debug`Desktop 2: `> blueman-applet --loglevel debug` |
|
🤔 I'm puzzled why it quits on the second desktop. Just tried and successfully started blueman on a separate desktop without any tricks (also tried 2.2.4 but I might have done something wrong there, so no guarantees). Are you sure that there's only a single blueman-applet process from the first one? Does |
|
running this to replace both instances of FLAGS_NONE with NON_UNIQUE: > cd /usr/lib/python3/dist-packages/blueman/
> rg 'Gio.ApplicationFlags.FLAGS_NONE' -l | xargs -n1 sudo sed -i 's/Gio.ApplicationFlags.FLAGS_NONE/Gio.ApplicationFlags.NON_UNIQUE/g' Desktop 1: `blueman-applet` (this is normal)Desktop 2: `blueman-applet` (Second Instance Started)Interestingly, if I close the first instance (ctrl+c), I get this error on the second: |
|
After that error, the tray dies, but the applet seems to survive. manually running |
|
I tested running two instances, and it seems to be able to (at least) do all the major actions (connect/disconnect) and both instances handle updating the icon and tray states fine. |
|
Here is some debug output. Oddly enough, this time, I didn't get the tray exception... Please note that the Desktop 1: `blueman-applet --loglevel debug` (this is normal)Desktop 2: `blueman-applet --loglevel debug` (Second Instance) |
|
Seems like the same session bus then. Without Within a single session bus the way to go would rather be a single applet with multiple tray instances, i.e. setting However, from #2095 (comment) and my experiments with that, I'd clearly expect one session bus per desktop. 🤔 |
|
I really couldn't explain to you my DBus setup. Like I said, Dbus is black magic to me, and I'm not even sure why I'm running dbus-launch. I saw it in the /xsession.d/* files, so I copied it into my start script. |
|
Alright, so, assuming that the target is multi-desktop, single-session-bus, I think the way to go is setting I agree that |
|
My thoughts go to using the |
|
awesome does not seem to set that and even if it would I'd just expect the same value for all instances. Maybe I don't get the idea yet, though. 😅 What should differ is |
|
Ooh, I didn't pickup that it's the same desktop 😅. Yeah, then DISPLAY may be a good alternative. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version Info
blueman:
BlueZ:
Distribution:
Desktop environment: No DE, awesome window manager v4.3
I occasionally run multiple instances of my window manager (in seperate ttys) and would appreciate having full access to my system tray. This could be remedied by adding a flag (
--multiple-instances/-m?) to permit multiple instances of (at least) the tray icon, though, asblueman-appletis what's run, it would also likely be needed to permit multiple instances of the full applet.This could be implemented by passing
Gio.ApplicationFlags.NON_UNIQUEtosuper().__init__in the tray as well as in the Main applet.The text was updated successfully, but these errors were encountered: