profile
viewpoint
Christopher Schramm cschramm Munich, Germany

cschramm/active_admin 0

The administration framework for Ruby on Rails applications.

cschramm/active_mocker 0

Create mocks from active record models and run them without loading rails or running a database.

cschramm/ad-detector 0

Detects articles with corporate sponsors.

cschramm/awesome_nested_set 0

An awesome replacement for acts_as_nested_set and better_nested_set.

cschramm/brakeman 0

A static analysis security vulnerability scanner for Ruby on Rails applications

cschramm/caja-extensions 0

Set of extensions for Caja, the MATE file manager

cschramm/capistrano-unicorn 0

Capistrano integration for Unicorn!

PR opened blueman-project/blueman

Reviewers
Drop blueman-assistant

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.

+2 -541

0 comment

16 changed files

pr created time in 20 hours

push eventcschramm/blueman

Christopher Schramm

commit sha e01e5dc2338d75872ab006ef7f78a0741cac474e

Drop blueman-assistant

view details

push time in 20 hours

create barnchcschramm/blueman

branch : assistant

created branch time in 20 hours

push eventcschramm/blueman

Christopher Schramm

commit sha dd2c40a02a58110a317ddece26463c42c8d15c4f

Add StatusNotifierItem indicator implementation

view details

Christopher Schramm

commit sha b304436c57bae4f142d29fd10c658335c64c441c

Add an abstract base class for indicator implementations

view details

Christopher Schramm

commit sha c775c9728d8696dd73e8dd0ea0410f498edf2dc2

Support multiple indicator implementations with trial and error

view details

Christopher Schramm

commit sha b0b8ce35b02795be057acda097645f2366365a4b

Drop AppIndicator plugin

view details

push time in 21 hours

push eventcschramm/blueman

Christopher Schramm

commit sha ed6b2cfc6e1b217f5c6b2bc041327b3f3bb9c238

Add an abstract base class for indicator implementations

view details

Christopher Schramm

commit sha b24872cb3b5dee3022891b745042c6a8b3b92ebe

Support multiple indicator implementations with trial and error

view details

Christopher Schramm

commit sha b9782e5e825c8eae9f1c74c447a4af6dbb3df828

Drop AppIndicator plugin

view details

push time in 21 hours

pull request commentblueman-project/blueman

Add oc.po

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.

cschramm

comment created time in 4 days

PR opened blueman-project/blueman

Reviewers
Add oc.po

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

+2571 -0

0 comment

1 changed file

pr created time in 4 days

create barnchblueman-project/blueman

branch : oc

created branch time in 4 days

IssuesEvent

issue closedblueman-project/blueman

Status indicators

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:

closed time in 6 days

cschramm

issue commentblueman-project/blueman

Status indicators

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 ()

cschramm

comment created time in 6 days

PR opened blueman-project/blueman

Add StatusNotifierItem indicator implementation
+255 -46

0 comment

11 changed files

pr created time in 6 days

create barnchcschramm/blueman

branch : sni

created branch time in 6 days

push eventcschramm/blueman

Christopher Schramm

commit sha 71f5cc5bc2130d6228a505a407341e60955e6554

Fix Gtk related typing issues

view details

Christopher Schramm

commit sha 0d333d05292469c6c52e2dadf49dbe8f4850ec57

Use mypy --strict

view details

push time in 7 days

issue commentblueman-project/blueman

2.1.4

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.)

cschramm

comment created time in 7 days

issue commentblueman-project/blueman

Feature Request: desktop notifications via notify-send

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.

hissssst

comment created time in 7 days

issue commentblueman-project/blueman

Missing option to connect headset

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.

tracek

comment created time in 7 days

issue commentblueman-project/blueman

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

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.

techganesh007

comment created time in 7 days

pull request commentblueman-project/blueman

Translations update from Weblate

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

weblate

comment created time in 7 days

issue commentblueman-project/blueman

Missing option to connect headset

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.

tracek

comment created time in 10 days

issue closedblueman-project/blueman

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

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

<!--

ℹ 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.

->

closed time in 10 days

techganesh007

issue commentblueman-project/blueman

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

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.

techganesh007

comment created time in 10 days

issue commentblueman-project/blueman

linuxlite 5 using bluetooth manager wont connect to my apple wireless keyboard A1016

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.

maclinuxlite

comment created time in 10 days

delete branch cschramm/blueman

delete branch : test

delete time in 10 days

push eventblueman-project/blueman

Christopher Schramm

commit sha e0aa77c7c2222765e4e57b5cf1992c2b792dffe2

Fix type reference in AppIndicator indicator

view details

Christopher Schramm

commit sha b4f0738d5a9a360e6f8fef0e2a0bc9d4f9b38383

Actually load all packages in tests

view details

push time in 10 days

Pull request review commentblueman-project/blueman

Add stubs/gi

 class Info(ManagerPlugin, MenuItemsProvider):     def on_request_menu_items(self, manager_menu: ManagerDeviceMenu, device: Device) -> List[Tuple[Gtk.MenuItem, int]]:         item = create_menuitem(_("_Info"), "dialog-information")         item.props.tooltip_text = _("Show device information")-        item.connect('activate', lambda x: show_info(device, manager_menu.get_toplevel()))+        _window = manager_menu.get_toplevel()

_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.

cschramm

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentblueman-project/blueman

Add stubs/gi

 def make_device_icon(self, icon_info: Gtk.IconInfo, is_paired: bool = False, is_         ctx = cairo.Context(target)          if is_paired:-            icon_info = self.get_icon_info("dialog-password", 16, False)+            _icon_info = self.get_icon_info("dialog-password", 16, False)+            assert _icon_info is not None+            icon_info = _icon_info             paired_surface = icon_info.load_surface(window)             ctx.set_source_surface(paired_surface, 1 / scale, 1 / scale)             ctx.paint_with_alpha(0.8)          if is_trusted:-            icon_info = self.get_icon_info("blueman-trust", 16, False)+            _icon_info = self.get_icon_info("blueman-trust", 16, False)+            assert _icon_info is not None+            icon_info = _icon_info             trusted_surface = icon_info.load_surface(window)+            assert isinstance(target, cairo.ImageSurface)+            assert isinstance(trusted_surface, cairo.ImageSurface)

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.

cschramm

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentblueman-project/blueman

Add stubs/gi

 def make_device_icon(self, icon_info: Gtk.IconInfo, is_paired: bool = False, is_         ctx = cairo.Context(target)          if is_paired:-            icon_info = self.get_icon_info("dialog-password", 16, False)+            _icon_info = self.get_icon_info("dialog-password", 16, False)

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.

cschramm

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentblueman-project/blueman

Add stubs/gi

 def __init__(self, summary: str, message: str, _timeout: int = -1,                  actions: Optional[Iterable[Tuple[str, str]]] = None,                  actions_cb: Optional[Callable[[str], None]] = None, icon_name: Optional[str] = None,                  image_data: Optional[GdkPixbuf.Pixbuf] = None) -> None:-        super().__init__(parent=None, flags=0, type=Gtk.MessageType.QUESTION,-                         buttons=Gtk.ButtonsType.NONE, message_format=None)+        super().__init__(parent=None, type=Gtk.MessageType.QUESTION,+                         buttons=Gtk.ButtonsType.NONE, text=None)

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.

cschramm

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentblueman-project/blueman

Add stubs/gi

 def _load(self, data: Iterable[ListDataDict]) -> None:      def selected(self) -> Gtk.TreeIter:         (model, tree_iter) = self.selection.get_selected()-+        assert tree_iter is not None         return tree_iter      def delete(self, iterid: Union[Gtk.TreeIter, Gtk.TreePath, int, str]) -> bool:-        if type(iterid) == Gtk.TreeIter:-            tree_iter = iterid+        if isinstance(iterid, Gtk.TreeIter):+            tree_iter: Optional[Gtk.TreeIter] = iterid

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

cschramm

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentblueman-project/blueman

Add stubs/gi

 def _on_properties_changed(      def close(self) -> None:         if self.__signal:-            self.__bus.signal_unsubscribe(self.__signal)+            if self.__bus is not None:+                self.__bus.signal_unsubscribe(self.__signal)

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.

cschramm

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentblueman-project/blueman

Add stubs/gi

 def send_command(self, command: str) -> None:         os.write(self.file, out.encode("UTF-8"))         termios.tcdrain(self.file) -    def on_data_ready(self, _source: GLib.IOChannel, condition: GLib.IOCondition, command_id: int) -> bool:+    def on_data_ready(self, _source: int, condition: GLib.IOCondition, command_id: int) -> bool:

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).

cschramm

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentblueman-project/blueman

Add stubs/gi

 def pulse() -> bool:          if not self.pulsing:             self.pulsing = True-            GLib.timeout_add(1000 / 24, pulse)+            GLib.timeout_add(41, pulse)

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

cschramm

comment created time in 10 days

PullRequestReviewEvent

pull request commentblueman-project/blueman

PowerManager.py: provides a new dbus method

@parr0tr1ver: Still interested in this?

parr0tr1ver

comment created time in 13 days

pull request commentblueman-project/blueman

ManagerDeviceList: Hide devices with no name

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

infirit

comment created time in 13 days

issue commentblueman-project/blueman

Status indicators

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.

cschramm

comment created time in 13 days

PR closed blueman-project/blueman

Reviewers
Fix type reference in AppIndicator indicator
+1 -1

1 comment

1 changed file

cschramm

pr closed time in 13 days

pull request commentblueman-project/blueman

Fix type reference in AppIndicator indicator

inluded in #1377

cschramm

comment created time in 13 days

push eventcschramm/blueman

Christopher Schramm

commit sha 8f49537441fdaf9570e72e0c3d42d0bd18cb2cbf

Actually load all packages in tests

view details

push time in 13 days

push eventcschramm/blueman

Christopher Schramm

commit sha 90f9e0b3b4c94e2df333ca672f7ef6adf0c1b283

Fix type reference in AppIndicator indicator

view details

Christopher Schramm

commit sha 2cb739cffc4a2236ee53dad3bb179152ee2881f4

Actually load all packages in tests

view details

push time in 13 days

push eventcschramm/blueman

Christopher Schramm

commit sha 24d62f6dd52fd3607653f1d73a0580b79c9cba22

Actually load all packages in tests

view details

push time in 13 days

PR opened blueman-project/blueman

Actually load all packages in tests
+1 -1

0 comment

1 changed file

pr created time in 13 days

create barnchcschramm/blueman

branch : test

created branch time in 13 days

PR opened blueman-project/blueman

Reviewers
Fix type reference in AppIndicator indicator
+1 -1

0 comment

1 changed file

pr created time in 13 days

create barnchcschramm/blueman

branch : fix

created branch time in 13 days

issue commentblueman-project/blueman

2.1.4

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.

cschramm

comment created time in 13 days

issue commentblueman-project/blueman

Status indicators

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

cschramm

comment created time in 14 days

issue closedblueman-project/blueman

Remember last profile ?

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

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?

closed time in 14 days

joakim-tjernlund

issue commentblueman-project/blueman

Remember last profile ?

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.

joakim-tjernlund

comment created time in 14 days

issue openedblueman-project/blueman

2.1.4

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)

created time in 14 days

issue commentblueman-project/blueman

Status indicators

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.)

cschramm

comment created time in 15 days

issue openedblueman-project/blueman

Status indicators

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:

created time in 16 days

issue commentblueman-project/blueman

Applet Interface language

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.

bentzys

comment created time in 16 days

issue commentblueman-project/blueman

two BTZ icons in tray when booting with adapter inserted

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?

michaelhmich

comment created time in 17 days

delete branch cschramm/blueman

delete branch : credit

delete time in 17 days

push eventblueman-project/blueman

Christopher Schramm

commit sha 3dc65bb7b651d85828ee3c910c4bc163c08463fc

Fix typo in CHANGELOG Credit where credit is due

view details

push time in 17 days

PR merged blueman-project/blueman

Fix typo in CHANGELOG

Credit where credit is due

+1 -1

0 comment

1 changed file

cschramm

pr closed time in 17 days

pull request commentblueman-project/blueman

Add stubs/gi

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.

cschramm

comment created time in 17 days

issue commentblueman-project/blueman

urb ... failed to resubmit (113) + UnicodeDecodeError

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.

ymollard

comment created time in 17 days

pull request commentblueman-project/blueman

Updating the translators list

Link to link to a Weblate page that shows the translators

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

wtuemura

comment created time in 18 days

Pull request review commentblueman-project/blueman

Localize message in Info dialog

 * Pairing with pincode * Handle os.remove failing * Fix disconnecting NMDevice-* Untranslated string in DiscvManager+* Untranslated strings (@cwenling / Colomban Wendling)

Oh gosh. :see_no_evil: #1369

cschramm

comment created time in 18 days

PullRequestReviewEvent

PR opened blueman-project/blueman

Reviewers
Fix typo in CHANGELOG

Credit where credit is due

+1 -1

0 comment

1 changed file

pr created time in 18 days

create barnchcschramm/blueman

branch : credit

created branch time in 18 days

issue closedblueman-project/blueman

urb ... failed to resubmit (113) + UnicodeDecodeError

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.

closed time in 18 days

ymollard

issue commentblueman-project/blueman

urb ... failed to resubmit (113) + UnicodeDecodeError

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:

ymollard

comment created time in 18 days

pull request commentblueman-project/blueman

Updating the translators list

...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

wtuemura

comment created time in 18 days

pull request commentblueman-project/blueman

Updating the translators list

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
wtuemura

comment created time in 18 days

delete branch blueman-project/blueman

delete branch : weblate-stable

delete time in 18 days

push eventblueman-project/blueman

Christopher Schramm

commit sha 5d5377bebc9f94a77934f475171415f070e78bf4

Add weblate workflow for 2-1-stable

view details

push time in 18 days

push eventblueman-project/blueman

push time in 18 days

push eventblueman-project/blueman

Christopher Schramm

commit sha f79274dc0eb72d0e5d6a2c153e387729d4db11a7

TEMPORARY Add weblate workflow for 2-1-stable

view details

push time in 18 days

delete branch blueman-project/blueman

delete branch : weblate

delete time in 19 days

push eventblueman-project/blueman

Christopher Schramm

commit sha 3520ee2fb85b5f8809ef832078efb3ee5f005a89

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

view details

push time in 19 days

PR merged blueman-project/blueman

Improve weblate workflow

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

+1 -1

0 comment

1 changed file

cschramm

pr closed time in 19 days

push eventblueman-project/blueman

Christopher Schramm

commit sha 766286b4584fe3796f3709406e113897091ea7fd

Add weblate workflow for 2-1-stable

view details

push time in 19 days

push eventblueman-project/blueman

Christopher Schramm

commit sha f7c87a004254f537ad5544076f5613c0faa2078f

Add weblate workflow for 2-1-stable

view details

push time in 19 days

push eventblueman-project/blueman

Christopher Schramm

commit sha 9ae34e443325b1aff3242b9fafb558c400cccbc4

Add weblate workflow for 2-1-stable

view details

push time in 19 days

push eventblueman-project/blueman

Christopher Schramm

commit sha 377ccd20a621743cfa4959aac1b2b7c61ca09215

Add weblate workflow for 2-1-stable

view details

push time in 19 days

push eventblueman-project/blueman

Christopher Schramm

commit sha ca9a15cf612dee62e27b7f8e17bb9ac40f7446c1

Add weblate workflow for 2-1-stable

view details

push time in 19 days

push eventblueman-project/blueman

Christopher Schramm

commit sha 5dccc5763f703843c13512d49a8054fe23287c38

Add weblate workflow for 2-1-stable

view details

push time in 19 days

push eventblueman-project/blueman

Christopher Schramm

commit sha 5016681eb17f1ba67164da0b207cca22f01cf985

Add weblate workflow for 2-1-stable

view details

push time in 19 days

push eventcschramm/blueman

Christopher Schramm

commit sha 5016681eb17f1ba67164da0b207cca22f01cf985

Add weblate workflow for 2-1-stable

view details

push time in 19 days

create barnchcschramm/blueman

branch : weblate-stable

created branch time in 19 days

PR opened blueman-project/blueman

Reviewers
Add weblate workflow for 2-1-stable
+27 -0

0 comment

1 changed file

pr created time in 19 days

PR opened blueman-project/blueman

Reviewers
Improve weblate workflow

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

+1 -1

0 comment

1 changed file

pr created time in 19 days

create barnchblueman-project/blueman

branch : weblate-stable

created branch time in 19 days

create barnchblueman-project/blueman

branch : weblate

created branch time in 19 days

pull request commentblueman-project/blueman

Add stubs/gi

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

cschramm

comment created time in 19 days

pull request commentblueman-project/blueman

Add stubs/gi

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:

cschramm

comment created time in 19 days

more