Feature Request: Gnome Shell Extension

[andyholmes]

I see this been receiving attention since the WebUpd8 post about KDE Connect. Since Ubuntu has announced the switch to Gnome Shell an extension seems like a sound approach.

[roo79x]

Agreed. I think this is the way gtk version of KDE connect needs to head. I can't code to save myself, but I am happy to help in any way I can.

[rodneyrod]

@andyholmes At the present time mconnect doesn't support DBus, which is what the kdeconnect-indicator and the Chrome KDE-Connect extension currently require.
Once DBus support is added, creating a plugin would be possible.

[andyholmes]

@rodneyrod Was your vision to make mconnect a drop in Dbus replacement as well? It's possible to use vala-dbus-binding-tool to clone KDE Connect's Dbus services but if the indicator and extension connect to org.kde.kdeconnectd is your plan to use the same namespace?

[rodneyrod]

@andyholmes I am not a developer so my knowledge on dbus and vala doesn't go beyond the core concepts. I guess that it should use a different namespace to prevent incompatibilities on the rare systems where both would be installed (e.g. a developer testing differences in behaviour etc) and it most likely wouldn't be too difficult in sending patches upstream to other projects to get them to support mconnect.

Or I could be completely wrong on how DBus works, I haven't really worked directly with it before.

[andyholmes]

@rodneyrod I think you have it right, on second thought there's no reason (other than the Chrome extension) I see to use the same DBus interface, but using DBus could mean SMS integration into telepathy and other neat things later on. On the other hand, the Gtk community as a whole could probably be covered if mconnect was made into a standalone Gtk indicator instead of a daemon with DBus, but Vala is pretty full-blown Gnome anyways...

I gather, like me, this isn't a top priority project for you, but it is still your project; what do you think?

[rodneyrod]

@andyholmes As I mentioned, I am not a developer. I don't know any C or Vala, so I won't be able to contribute anything to this project besides ideas and suggestions.

[andyholmes]

@rodneyrod Sorry, I somehow was confused into thinking this was your repository, thanks for being a sounding board :)

[rodneyrod]

@andyholmes You know, as I've said that, I've noticed that there is a d-bus support branch to this project.
https://github.com/bboozzoo/mconnect/tree/bboozzoo/dbus-support

So looks like it's on the way.

[andyholmes]

@bboozzoo I'd like to start writing a gnome-shell extension, but I'd like to know if you're going to copy the KDE Connect DBus interface, and if you will continue using flat file config. Thanks.

[bboozzoo]

I don't know if I'll have an exact copy of KDE connect's DBus interface or something that's just close enough conceptually.

In fact I have not looked at kdeconnect's DBus API, and did so only just now (used this file for reference: https://github.com/vikoadi/indicator-kdeconnect/blob/master/src/KDEConnectManager.vala). Looks like the API I started working on in https://github.com/bboozzoo/mconnect/tree/bboozzoo/dbus-support branch is quite close.

Maybe some examples. Device tree:

$ busctl --user tree org.mconnect
└─/org
  └─/org/mconnect
    ├─/org/mconnect/device
    │ └─/org/mconnect/device/0 <-- devices will appear here
    └─/org/mconnect/manager  <--- manager object

Device looks like this:

$ busctl --user introspect org.mconnect /org/mconnect/device/0 org.mconnect.Device
NAME                TYPE      SIGNATURE RESULT/VALUE             FLAGS                                                                                                       .Address            property  s         "192.168.1.103:1716"     emits-change writable
.Allowed            property  b         true                     emits-change writable                                                                                    .DeviceType         property  s         "phone"                  emits-change writable                                                                                    
.Id                 property  s         "673ac2db27d2a331"       emits-change writable                                                                                    .IsPaired           property  b         false                    emits-change writable
.Name               property  s         "Motorola Moto G Maciek" emits-change writable                                                                                    .ProtocolVersion    property  u         7                        emits-change writable

Manager:

$ busctl --user introspect org.mconnect /org/mconnect/manager org.mconnect.DeviceManager
NAME                       TYPE      SIGNATURE RESULT/VALUE FLAGS
.AllowDevice               method    s         -            -   <-- enables a device, device object path as a parameter
.ListDevices               method    -         ao           -   <-- returns of device object paths

I haven't added signals but I guess this will be something like NewDevice(s) (where string is the object path) or NewDevice(o) explicitly. (Come to think of that AllowDevice should also possibly be AllowDevice(o).

I haven't pushed the changes yet, but I started adding a sample client that does just the basic things (list, allow, show device etc).

[andyholmes]

For what it's worth KDE Connect uses the device ID as an index, which works out well since it's a mostly static and unique property. For example "/org/kde/kdeconnect/devices/[device-id]" as a device path and relevant signals return in the user data.

If it were possible to use DBus to negotiate all functionality including configuration, I think that would be ideal. Aside from indicators and stuff I think this could make for tighter, direct integration for mobile devices in Gnome Shell, rather than just proxying things through Google servers. But that's just my wishlist, I'll keep an eye on mconnect/dbus-support.

[andyholmes]

@bboozzoo What is the difference between 'paired' and 'allowed'? Is it like connected->trusted?

[bboozzoo]

allowed -> trusted (suppose the name can be changed to be in sync with kdeconnect)
paired -> keys were exchanged with the device, and it's something I'm not entirely sure of right now, as the code will attempt to pair quite frequently (covers some edge cases when device becomes unpaired or connectivity is lost)
connected -> not currently exported over dbus (TODO actually)

[andyholmes]

@bboozzoo sounds good, I pushed the beginning of an extension to andyholmes/gnome-shell-extension-mconnect, comments welcome.

[khurshid-alam]

@andyholmes Can we have indicator support for Unity/Pantheon/Mate?

[andyholmes]

@khurshid-alam I don't know anything about AppIndicators, maybe you should check out indicator-kdeconnect which may support mconnect in the future when it's more complete.

[khurshid-alam]

@andyholmes

Thanks. I can help with that but I haven't study your code (I may do that if I have time).

But for reference here is the API:

https://developer.ubuntu.com/api/devel/ubuntu-13.10/python/AppIndicator3-0.1.html (python)
https://developer.ubuntu.com/api/devel/ubuntu-13.10/c/AppIndicator3-0.1.html (c)

And here is a small example using vala (compile with valac --pkg gtk+-3.0 --pkg appindicator3-0.1):

using Gtk;
using AppIndicator;

public class IndicatorExample {
    public static int main(string[] args) {
        Gtk.init(ref args);

        var win = new Window();
        win.title = "Indicator Test";
        win.resize(200, 200);
        win.destroy.connect(Gtk.main_quit);

        var label = new Label("Hello, world!");
        win.add(label);

        var indicator = new Indicator(win.title, "indicator-messages",
                                      IndicatorCategory.APPLICATION_STATUS);
        if (!(indicator is Indicator)) return -1;

        indicator.set_status(IndicatorStatus.ACTIVE);
        indicator.set_attention_icon("indicator-messages-new");

        var menu = new Gtk.Menu();

        var item = new Gtk.MenuItem.with_label("Foo");
        item.activate.connect(() => {
            indicator.set_status(IndicatorStatus.ATTENTION);
        });
        item.show();
        menu.append(item);

        var bar = item = new Gtk.MenuItem.with_label("Bar");
        item.show();
        item.activate.connect(() => {
            indicator.set_status(IndicatorStatus.ACTIVE);
        });
        menu.append(item);

        indicator.set_menu(menu);
        indicator.set_secondary_activate_target(bar);

        win.show_all();

        Gtk.main();
        return 0;
    }
}

[andyholmes]

@khurshid-alam If Vala was the way you wanted to go, it would be best to get in touch with Bajoja on this issue. The extension I wrote is for Gnome Shell so it's written (almost) entirely in GJS/Javascript.