I propose to drop this. It's redundant (all its functionality is available from blueman-manager), a source of confusion, and functionality deviates from blueman-manager, e.g. it lacks a generic connect option, see #1380.

Maybe add the pot file anyway :stuck_out_tongue_winking_eye:

We could keep it up to date manually with every MR that effects it and add a check that it actually is up to date. :man_shrugging:

Forgot to add, when we actually get translated string we ned to update LINGUAS.

:thinking: cy has been missing there as well all the time.

This was requested on Weblate (Weblate does not offer to add new translations if the POT file is not in the repository).

This is a follow-up to https://github.com/blueman-project/blueman/issues/1362#issuecomment-686307938.

Linux tray icons / status indicators / whatever you want to call them are a mess. I'm trying to collect what I think to know about that mess.

There are basically two common ways to implement them: The old XEmbed protocol based on X11 and the newer StatusNotifierItem (SNI) based on DBus.

The two indicator implementations that blueman currently provides are based on GtkStatusIcon and libappindicator. GtkStatusIcon is a nice XEmbed implementation. GTK 4 will drop it (we could still use GTK+ 3 GtkStatusIcon, though, as blueman-tray is a small, mostly decoupled, standalone application now). libappindicator is an unmaintained piece of legacy software that has a bad SNI implementation and a bad fallback XEmbed implementation and evolved into some kind of industry standard for (non-Qt, non-kdelibs) SNI clients :man_facepalming:. There's also Ayatana Indicators which is said to a be drop-in replacement for libappindicator although it's not and it does not seem more advanced than libappindicator itself. :man_shrugging: It does have some adoption though, at least in Debian (see #1217) and MATE (see mate-indicator-applet).

As XEmbed is tightly coupled to X11 and Wayland is a thing nowadays, mainstream desktops started dropping support for it. KDE, who initially drafted SNI for Plasma 4, dropped support in Plasma 5 (there is an xembed-sni-proxy thingy since 5.5, though). Ubuntu picked up KDE's SNI protocol to build Application Indicator (and the infamous libappindicator) on it and dropped XEmbed support in Unity. Let's not talk about Gnome Shell when it comes to trays...

Instead, let's turn to our target group where it's rather a question of who does not yet support SNI than of who does not support XEmbed (anymore):

• xfce4-panel: xfce4-indicator-plugin since like forever (4.4?), xfce4-statusnotifier-plugin since 1.14
• mate-panel: Builtin support since 1.18 / 1.20, also mate-indicator-applet
• lxqt-panel: plugin-statusnotifier since 0.10.0
• Cinnamon since 2.8
• LXPanel: Doesn't seem like it has support (is LXDE still relevant, though?)
• Budgie: There is budgie-indicator-applet, kinda third-party
• i3: No
• Sway: SNI only

Two things that bug me in libappindicator are the missing activate action (present in the SNI spec) and unclear markup support (see e.g. https://bugs.launchpad.net/indicator-application/+bug/522149; while the SNI spec has a tooltip property with well-defined markup support, libappindicator uses only the title property and implementations historically add some markup support / cleanup there).

@bentzys: Thanks for trying my test script on Plasma. It's sobering that it did not show you any text. I guess my implementation is not complete enough and will have another look / thought.

@infirit: Your questions should be answered by the above novel. :sweat_smile:

There's a draft in #1382. It only implements the necessary bits of the SNI interface as I'm unsure how much sense it makes to stick to the standard if already the interface name deviates in reality.

Compared to the AppIndicator implementation we gain a primary action and a working tooltip (even with support for our bold text at least in mate-panel). Compared to the GtkStatusIcon implementation we lose formatt menu items ()

there are some untranslated strings in the stable component that have translations in the master component and it would make total sense to just copy them all for all languages

I've just done that by hand. 🙂 (#1366 lacks squashing for unknown reasons.)

Makes perfect sense to me. Usually you do not need it as the status icon change is sufficient if you use just one device at a time but you lack that feedback if you use multiple.

As expected, in step 2 you open blueman-assistant and in step 4 it lacks the generic connect. Instead of using "setup", you can just use "pair" and then "connect" from that menu.

@infirit: What do you think? Should we get rid of assistant? Otherwise we should probably add a generic connect option to it.

See http://www.bluez.org/contact/. You'll probably want to use the user mailing list.

The error is fixed in Debian package version 2.1.3-1. I assume you're using 2.0.8.

Looks like https://docs.weblate.org/en/latest/admin/addons.html#squash-git-commits does not work for the stable component... :confused:

Are you using the setup assistant? If I'm not mistaken it lacks that generic connect entry (which makes me think about removing the assistant completely again) and you have to use the right-click or menu bar device menu in manager instead.

blueman:version 5.50 BlueZ:version 5.50 Distribution:Debian Desktop environment:Wayland

Sep 09 18:32:34 debian bluetoothd[1081]: Loading LTKs timed out for hci0

unable to start snap bluez.obex and bluez.bluez services

some issue with d-bus configuration

• [x] I have consulted the Troubleshooting page and done my best effort to follow.

<!--

ℹ Please use some service like Pastebin or GitHub Gist to post your logs and keep the thread clean and readable. Make sure to describe the exact steps you took when producing it.

->

You're reporting a BlueZ issue to the blueman project. This is the wrong place and I have never seen that issue and absolutely no idea what it's about apart from what Google gives me.

Actually we're not using BlueZ' full potential there as org.bluez.Agent1.DisplayPasskey gets passed the number of (correctly) entered digits that we could use for a more intuitive presentation but our agent just ignores that. Also, we might display an incorrect PIN code < 100000 as we do not zero-pad to six digits.

_window first gets implicitly defined as optional, the assertion narrows it down to non-optional, but if we use it in the lambda it will be considered optional again (https://github.com/python/mypy/issues/2608). Opposed to that, window gets defined as the narrowed type of _window so it is non-optional right away.

This should be fixed in the stub that load_surface return an instance of cairo.Surface. What do you mean? I think that's the case there, but we expect that Surface to be an ImageSurface which is not guaranteed.

icon_info is already defined as non-optional in the method arguments, so we cannot assign the optional value from get_icon_info to it, but I could actually save icon_info = _icon_info as I could just use _icon_info.load_surface after the assertion directly.

I was a little bit confused here. text defaults to "", not NULL, see https://developer.gnome.org/gtk3/stable/GtkMessageDialog.html#GtkMessageDialog--text, so I think text=None should actually be something else than the default but I did not really look into it.

get_iter in the other branch may return None and the variable needs a common type.

From the interface there's nothing holding a caller from calling close twice. Instead of the condition we could also use an assert, causing a crash instead of silently doing nothing if it actually happens. mypy just wants to know that we are aware of the fact that self.__bus might be None.

This is an override, see https://gitlab.gnome.org/GNOME/pygobject/-/blob/7d5f4cd41ee0221c13842ab6323b7a016df02c7e/gi/overrides/GLib.py#L638. If io_add_watch gets called with a file descriptor (int) the callback will receive a file descriptor as well (kept in the func_fdtransform closure).

Maybe it was meant to be 24 Hz but I have no idea why.

@parr0tr1ver: Still interested in this?

I tried to the hypothesis a little bit but did not find good examples. I guess it's valid, though. We can try.

Nice. That does not look very bold to me but at least it does not show the tags. 🙂 I'll draft a DBus SNI indicator implementation and the mentioned trial and error mechanism for our tray then.

inluded in #1377

That's the tooltip for the the connect item in blueman-manager's device menu, so it describes what that item does and it's not about enabling anything but actually connecting profiles.

Fixed the tooltip in my gist. @bentzys, could you try https://gist.github.com/cschramm/c6cc7cea909d7a40e6f5a976dbaf484f again, please?

blueman: master 11/08/20 BlueZ: master Distribution: Gentoo Desktop environment: MATE

• [ X] I have consulted the Troubleshooting page and done my best effort to follow.

blueman usually select an A2DP profile when I reconnect. It would be nice if blueman could remember the profile I had before.

BTW, time for a new 2.1.x release?

The profile selection blueman offer's is just an interface to pulseaudio. You can add set-card-profile statements to /etc/pulse/default.pa to set a default profile.

Some fixes piled up in https://github.com/blueman-project/blueman/compare/2.1.3...2-1-stable so that I think it's time for a 2.1.4.

Some stuff that bugs me:

• @infirit: It seems like https://github.com/blueman-project/blueman/commit/778b2ad94265dda6f170d68b6b629dfa68225e3b ended up in the wrong section. Looking at the commits those things were not part of 2.1.3 but will be in 2.1.4, right?
• We backported some "make strings translatable" improvements and Weblate enabled me to set up https://hosted.weblate.org/projects/blueman/stable/. Obviously untranslated stuff did not get translated a lot yet, but what bugs me in particular is that there are some untranslated strings in the stable component that have translations in the master component and it would make total sense to just copy them all for all languages but it seem like you can only do that one by one. (@ymollard: To fix https://github.com/blueman-project/blueman/issues/1343 for fr, would you mind going through https://hosted.weblate.org/translate/blueman/stable/fr/?q=check:inconsistent? You will probably want to just apply the master translations at least for stuff that's untranslated in stable yet) (Translations coming in in #1366)

Would it make sense to leave the appindicator implementation in place but make the sni default with fallback to GtkStatusIcon?

I don't think it makes sense as that's exactly what libappindicator does (its fallback XEmbed implementation is GtkStatusIcon).

I was thinking about a pure DBus (as there seem to be no good and well-adopted libraries) SNI indicator implementation and changing the way blueman-tray selects the implementation from a single name to a list where it does trial and error, i.e. if the SNI plugin is enabled in blueman-applet, that list will be ["SNI", "GtkStatusIcon"] and if the SNI implementation signals that it cannot do it's job, blueman-tray falls back to the GtkStatusIcon one and gets a better icon than it would with the libappindicator fallback (an activate callback that is not just wired to the popup-menu callback, tooltip-markup instead of just title, ...). (An own SNI implementation would have the same main benefits: Using the ToolTip property instead of just Title and provide an Activate method.)

This is a follow-up to https://github.com/blueman-project/blueman/issues/1362#issuecomment-686307938.

Linux tray icons / status indicators / whatever you want to call them are a mess. I'm trying to collect what I think to know about that mess.

There are basically two common ways to implement them: The old XEmbed protocol based on X11 and the newer StatusNotifierItem (SNI) based on DBus.

The two indicator implementations that blueman currently provides are based on GtkStatusIcon and libappindicator. GtkStatusIcon is a nice XEmbed implementation. GTK 4 will drop it (we could still use GTK+ 3 GtkStatusIcon, though, as blueman-tray is a small, mostly decoupled, standalone application now). libappindicator is an unmaintained piece of legacy software that has a bad SNI implementation and a bad fallback XEmbed implementation and evolved into some kind of industry standard for (non-Qt, non-kdelibs) SNI clients :man_facepalming:. There's also Ayatana Indicators which is said to a be drop-in replacement for libappindicator although it's not and it does not seem more advanced than libappindicator itself. :man_shrugging: It does have some adoption though, at least in Debian (see #1217) and MATE (see mate-indicator-applet).

As XEmbed is tightly coupled to X11 and Wayland is a thing nowadays, mainstream desktops started dropping support for it. KDE, who initially drafted SNI for Plasma 4, dropped support in Plasma 5 (there is an xembed-sni-proxy thingy since 5.5, though). Ubuntu picked up KDE's SNI protocol to build Application Indicator (and the infamous libappindicator) on it and dropped XEmbed support. Let's not talk about Gnome Shell when it comes to trays...

Instead, let's turn to our target group where it's rather a question of who does not yet support SNI than of who does not support XEmbed (anymore):

• xfce4-panel: xfce4-indicator-plugin since like forever (4.4?), xfce4-statusnotifier-plugin since 1.14
• mate-panel: Builtin support since 1.18 / 1.20, also mate-indicator-applet
• lxqt-panel: plugin-statusnotifier since 0.10.0
• Cinnamon since 2.8
• LXPanel: Doesn't seem like it has support (is LXDE still relevant, though?)
• Budgie: There is budgie-indicator-applet, kinda third-party
• i3: No
• Sway: SNI only

Two things that bug me in libappindicator are the missing activate action (present in the SNI spec) and unclear markup support (see e.g. https://bugs.launchpad.net/indicator-application/+bug/522149; while the SNI spec has a tooltip property with well-defined markup support, libappindicator uses only the title property and implementations historically add some markup support / cleanup there).

@bentzys: Thanks for trying my test script on Plasma. It's sobering that it did not show you any text. I guess my implementation is not complete enough and will have another look / thought.

@infirit: Your questions should be answered by the above novel. :sweat_smile:

I guess you're using our AppIndicator plugin. We use libappindicator there and that is one piece of badly designed interface tightly coupled to indicator-application that it was initially build for. There is no differentiation between plain text and markup, just as single title, and tags in it get weird treatment in application-indicator as it strips some and shows others, see e.g. https://bugs.launchpad.net/ubuntu/+source/indicator-application/+bug/522149. Some implementations copy that behavior, some even support markup in the title, some expect plain text like yours (it's Plasma 5, right?).

When I just had another look it at, I realized that it's probably plain stupid that we're still using libappindicator, though, as there is an underlying DBus protocol with a much better interface than libappindicator's and the freedesktop.org StatusNotifierItem specification even shows the common understanding (although in reality things are org.kde, not org.freedesktop :smile:) and that specification does have a tooltip property with explicit and well-defined markup support besides the title property that it just describes as "a name that describes the application". I guess we should just use the DBus protocol directly to be able to use the tooltip property and get better results.

I just created a small Python script to test it: https://gist.github.com/cschramm/c6cc7cea909d7a40e6f5a976dbaf484f. Just run and check what tooltip and title stuff it gives you for the blueman icon that it adds.

Two blueman icons should probably be fixed by #1304 but it sounds really strange that it seems to depend on the presence of an adapter. I assume nothing shows up in any case if you disable blueman in KDE's autostart manager, right?

Credit where credit is due

I actually thought about removing all stuff that we do not use from the generated stubs as there are probably a lot of falsehoods in there that might lead to confusion if somebody makes the mistake to rely on the them (e.g. callback types are generally defined to take an optional object as user data while they usually take a variable amount of arguments; if one implements that signature as it is defined it would be wrong to pass zero or more than one user data argument but would be perfectly fine from the stubs perspective). Not sure how much work that would be, though, and one would have to restore the generated stuff as a basis when using additional things.

See the linked comment. Our code is not involved and there is probably not even a way to catch the exception for us except of a generic sys.excepthook. Apart from that, it does not do harm, and I would not really see stuff like Apport annoying the user as the problem of other applications than Apport itself. Ubuntu can add Conflicts: apport to their blueman package to avoid it. 🤭 Even if one sees it as others' problem, then probably PyGObject should catch that bug, not us.

Link to link to a Weblate page that shows the translators

I still fail to find some page like that on Hosted Weblate. :thinking:

Oh gosh. :see_no_evil: #1369

Credit where credit is due

For no reason I'm suddenly getting errors from the kernel when bluetooth service is (re)started. Journalctl says:

sept. 01 01:21:41 laptop systemd[1]: Started Hostname Service.
sept. 01 01:21:42 laptop dbus-daemon[966]: [system] Activating via systemd: service name='org.blueman.Mechanism' unit='blueman-mechanism.service' requested by ':1.2539' (uid=1000 pid=352047 comm="/usr/bin/python3 /usr/bin/blueman-applet " label="unconfined")
sept. 01 01:21:42 laptop systemd[1]: Starting Bluetooth management mechanism...
sept. 01 01:21:42 laptop blueman-mechanism[366359]: Unable to init server: Could not connect: Connection refused
sept. 01 01:21:42 laptop blueman-mechanism[366359]: Unable to init server: Impossible de se connecter : Connection refused
sept. 01 01:21:42 laptop blueman-mechani[366359]: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
sept. 01 01:21:42 laptop dbus-daemon[966]: [system] Successfully activated service 'org.blueman.Mechanism'
sept. 01 01:21:42 laptop systemd[1]: Started Bluetooth management mechanism.

sept. 01 01:21:43 laptop bluetoothd[366339]: Loading LTKs timed out for hci0
sept. 01 01:21:44 laptop kernel: Bluetooth: hci0: urb 00000000153bcec7 failed to resubmit (113)

In the GUI, any connection tentative later on then results in Resource Not Ready.

Although any idea is welcome about this, my issue also concerns how blueman 2.1.2-1 reacts to this strange bug from the kernel. Indeed, in generates such Python errors UnicodeDecodeError: 'utf8' codec can't decode byte 0xa5 in position 0: invalid start byte. I assume that try/catching decode instructions would be the right fix, at least to prevent Apport from generating crash reports.

If someone can consult the Apport reports gatherd by Ubuntu 20.04, I've sent of few of them in the last 12hrs.

See https://github.com/blueman-project/blueman/issues/1241#issuecomment-655923852 for the blueman part.

"failed to resubmit" gives me a lot of good matches on Google, not sure if they include a useful solution beside replacing the hardware, though. :smile:

...and I have to apologize, @wtuemura. I dumped your changes to the stable compoment as it was not too stable yet. :worried: Could you please re-apply them? They are in the history and Weblate also still remembers and offers the translations that you added for previously untranslated messages. https://hosted.weblate.org/changes/?component=stable&project=blueman&lang=pt_BR&user=wtuemura

Looks like Weblate does not maintain that list (it's from Transifex). I guess we need to find a solution to credit the translators but maintaining that list by hand is not it. :sweat_smile:

My suggestion would be:

• Create a wiki page for Launchpad and Transifex translators
• Remove Transifex translators from PO files
• Link to link to a Weblate page that shows the translators (I only found a manual export, yet, though :thinking:) and the wiki page with Launchpad and Transifex translators in the about dialog
• Remove Launchpad translators from about dialog

Make sure the downloaded POT file is that of the master branch.

Make sure the downloaded POT file is that of the master branch.

I tried to keep a clean commit history, in case you did not realize. There's obviously no need to review the generation commits. 🙂

I'm a little sad that I found just one little bug that could actually show up (https://github.com/blueman-project/blueman/pull/1353/commits/55792c52220aa3de5bb287c9cb6b9c1aee85c2d7). On the other side... pretty cool! :smiley: