search

b4j4 / indicator-kdeconnect

AppIndicator for KDE Connect
GNU Lesser General Public License v2.1
372 stars 38 forks source link

Use mconnect #38

Closed hotice closed 7 years ago

hotice commented 7 years ago

mconnect is a KDE Connect protocol implementation in Vala/C. Since indicator-kdeconnect is for using KDE Connect outside of KDE, and KDE Connect comes with a large number of KDE dependencies, maybe you could use mconnect instead.

b4j4 commented 7 years ago

Interesting, but is missing the most important thing, an API over DBUS,

rodneyrod commented 7 years ago

@Bajoja DBus support is being worked on in this branch: https://github.com/bboozzoo/mconnect/tree/bboozzoo/dbus-support

Might want to reopen the issue.

b4j4 commented 7 years ago

@rodneyrod it's a little complicate to join both project, one of the way is use the same namespaces that kdeconnect use to his DBus API, secound is i can offer to help them build a new indicator and integrated to the mconnect as indicator-mconnect if they work on the DBus API.

rodneyrod commented 7 years ago

@bajoja so it wouldn't be possible to poll for both at launch and have the indicator auto select whichever one is installed? Either way, @bboozzoo would be able to help better than I could.

rodneyrod commented 7 years ago

@Bajoja I've learned that @bboozzoo is using the interface exposed by the old, pre forked indicator-kdeconnect that @vikoadi was working on, so really it shouldn't be hard to get mconnect working with your current indicator.

b4j4 commented 7 years ago

@rodneyrod is not good idea use the interface of vikoadi because that one is deprecated, change the inteface to the new kdeconnect interface API was one of the first things i do, so he have to do it based on my fork.

rodneyrod commented 7 years ago

@Bajoja I'm not the developer, @bboozzoo is, you will need to get in contact with him to convey what changes have been made. You should get in contact with him yourself.

b4j4 commented 7 years ago

@rodneyrod if he is interested on this we can talk, but he is not response this messages I imagine he is not.

andyholmes commented 7 years ago

@rodneyrod @Bajoja If someone wanted to take this on, it would probably be better to lobby the KDE Connect developers (ping @albertvaka) for a MPRIS-style DBus standard. KDE Connect has two "interfaces", the protocol for communicating with devices and the DBus interface. A DBus spec like MPRIS could present devices without restricting any daemon<->device communication.

rodneyrod commented 7 years ago

@andyholmes You think that you could push some code to mconnect to facilitate this?

andyholmes commented 7 years ago

@rodneyrod it's possible, at the moment bboozzoo is only just starting a DBus interface and I'm still trying to get an extension to work with what's there.

But basically, it goes like this: an application can publish it's internal classes/methods/properties/signals as an interface, under it's own bus name (eg. org.mconnect or org.kde.kdeconnect), but bus names are "owned" so you can't just use someone else's. MPRIS specifies a Bus Name template (org.mpris.MediaPlayer2.<application-name>) so they can be found, and interfaces that a publishing application must/should/can support. Thus mconnect and kdeconnect would have to agree on a bus name template like org.mobile.MobileDeviceManager.<kdeconnect/mconnect> or org.mobile.MobileDevice.<actual-device-name> and interfaces a device/device manager must/should/can publish.

I hope I'm not just telling you things you know already, but the work to be done is probably to first convince the KDE Connect devs to support such an interface, then get mconnect on board and maybe something freedesktop.org-y could come out of it.

b4j4 commented 7 years ago

Yes, they are proprietary, but one of the solution is just use the same nomenclature as KDE but replacing KDE for mconnect, from that way is simple to port this to mconnect.

andyholmes commented 7 years ago

@Bajoja that's true, but I think the kdeconnect interface could be a little better. I think it's weird how all plugins but battery and notifications get their own bus path, for example.

b4j4 commented 7 years ago

@andyholmes Yup, it is a little complicate, when i start to maintain this was a little difficult to understand it, the first think i said is "Dam was really necessary make it by that way"

rodneyrod commented 7 years ago

@Bajoja There's a D-Bus support branch in mconnect now if you want to have a look at that: https://github.com/bboozzoo/mconnect/tree/bboozzoo/dbus-support

rodneyrod commented 6 years ago

@Bajoja There's been many improvements to the DBus API. You might want to revisit your decision and support mconnect. It's certainly a lot easier to get running on distros that have broad depends on KDE Connect like Arch.