WebSockets support

[marmis85]

Regarding the lack of support for websockets in GJS, I was looking around for a glib based websockets implementation that could be wrapped by some GObject Introspection magic, and by looking at libsoup's repository it seems that there will be websockets support in next release (2.50), or at least soup-websocket-connection.h and soup-websocket.h say so :)

I was exploring the idea of having a python daemon listen on the websockets connection (and maybe also handle notifications), but websockets support in libsoup should solve the problem!

btw I'd love to contribute to the project as something like this was pretty high in my weekend/nighttime projects list, and as an excuse to build some gnome related development skills :)

[sagebind]

That sounds awesome! The main reason I wanted to develop this GNOME extension was to have incoming Pushbullet notifcations integrated with GNOME's notification system. There is Pushbullet Indicator, but the developer's interest was in the other direction (sending pushes).

I'll look into libsoup; maybe I'll contact the developers about it.

[sagebind]

Feel free to contribute as well; fork & hack away. This project is very open to contribution.

[marmis85]

Since libsoup is part of GNOME and next week there should be the 3.16 release, I did a quick check and by looking at the version number used (libsoup 2.49.1 => 2.49.91.1) I'm pretty sure this is going to be included in next release! http://www.mirrorservice.org/sites/ftp.gnome.org/pub/GNOME/core/3.15/3.15.91/NEWS

Also, just in case you missed it, with 3.16 there are going to be some big changes to the whole notifications system!

I'll keep in touch! :)

[marmis85]

A quick update: I managed to set up a development VM with GNOME 3.15.92, and after some initial hiccups I got the websocket connection working! I uploaded a simple proof-of-concept here while I'm thinking how to integrate this in the extension. but it should be trivial swaping out the current polling mechanism. BTW, using the websocket API means not being able to support GNOME < 3.16, personally I use Archlinux and in a matter of weeks hopefully it will be mainlined, but I'm not sure about other distributions; what do you think about this? @coderstephen

[sagebind]

That's a valid point, as I prefer to run stable, older GNOME builds for Ubuntu (which tend to be a bit behind :) ). I'm on 3.12 still I believe, and lots of users are still on 3.10.

I think requiring 3.16 isn't a huge deal since it never really worked anyway! I never felt it was useful enough to even put on extensions.gnome.org in its current state.

[sagebind]

I will set up a Vagrant box for GNOME 3.16 that can be used for testing this thing. Perhaps this extension can become usable in the future.

[marmis85]

I also used vagrant to setup my arch development vm! This is my Vagrantfile

[marmis85]

@coderstephen I've pushed some initial work in the websocket branch For now I removed the polling and requires gnome 3.16 I refactored the notifications to use a normal MessageTray.Source instead of subclassing it because after a while the notifications would suddenly stop popping, and I found a lot of of commits of other projects doing the same, I'm not really sure about the rationale though XD I also implemented basic support for pushes dismissed/deleted on another client There is a lot of room for improvement, tell me what you think!

[sagebind]

Looks like this direction is definitely viable. I haven't had the time to test it, but I plan to have look at it soon.

[marmis85]

Cool! I gave an exhaustive look at Pushbullet's APIs and I have some wild ideas, as there should be all the necessary to build a full-fledged client, including defining you own device that can be pushed to.

The direction I'd like to take is roughly:

• Th notification area will hold NEW, ACTIVE and NOT DISMISSED pushes, and will be kept in sync by the websocket tickles. In case of defining a "GNOME Shell" device, only notification for said device will be shown.
• An shell panel button to initiate pushes (think the chrome extension button, but in the panel). That could probably also house a panel to manage push history and devices without the need of a dedicated application or logging in the website.
• As for initiating file pushes from nautilus, well it must be implemented as a nautilus extension, there a couple of projects around, of which nautilus-pushbullet seems actively developed but I totally fail to understand where launchpad hides the souces xD

I'm not a pro with GitHub but i'll try to put up a wiki page with a fancy checklist to organize ideas and status, and not clutter this thread!