[FEATURE] Enable Dbus again - Ideally via a setting

[Wattos]

I have a Thingm blink(1) (See https://blink1.thingm.com/) that I would love to integrate with Super productivity.

Basically, as long as I am focusing on a task, I would love to change the color of the LED. I would be able to do that fairly easily if Super Productivity offered one of the following options:

1) Web hook support on changing of the state 2) Dbus support on changing of the state

It seems that Dbus support was once implemented, but then got commented out (but only for gnome when the gnome widget was installed). It would be really cool if it was possible to enable dbus again under a setting, so that these events are fired automatically. Any third party integration can then listen in on linux.

[johannesjo]

Thanks for creating this issue (and congrats for opening up the 200th issue!!! ;)). Almost forgot about it. I have some fuzzy memory about some issues with dbus-native on non linux systems when I was rewriting the whole application to work with angular 2+.

I'm always looking to get more people on board developing this app. Would you maybe be interested in supplying a PR yourself for the reintegration? I happily guide you along the way :)

[Wattos]

I'll try to cook something up. Ideally, I would also like to make it work on non-Linux environments, so having a "call a command line script", also an option.

Could you provide quick guidance on how you would see it within the code base? Is it okay if I just clean up the existing dbus code or would you want me to put it into features/dbus or maybe something more focused like:

features/integrations/dbus features/integrations/http features/integrations/cli

Ideally, I see these 3 generic integrations as ones that are really vital, however all of them with slightly different logic. The codebase, along with the message bus is already fairly well done, so building the logic on its own is actually not that difficult. Thanks!

[johannesjo]

That's a really interesting suggestion! Thinking about it, communication could even be 2 way, which would be a great basis for #173 , but that's probably something for later on.

I probably would call the feature and module externalInterfaces or something along those lines, as integrations sound a little too broad to me. Not sure if we need to additional modules for the interface handlers.

Most effective tool to is probably ngrx effects. Every interface should have its own effect handling actions being dispatched in the app. In the case of dbus and the client interface, things would need to be passed further on to the electron layer via this._electronService.ipcRenderer.send to maintain a clean separation between frontend and electron layer. We might just pass through the actions directly and reuse the respective classes and related enums from the frontend part in the electron layer as well.

I'm excited about this stuff! It's probably not trivial to implement, so please let me know if can help you somewhere.

[Wattos]

Well, as always, naming is not easy and there are more opinions than developers when it comes to that. I am happy to name it externalInterfaces, but this is where I would say that this does not really describe what it is, what it does.

At the end, I believe that this is really part of integration and having multiple of these, dbus, cli, http and then the list could continue, (maybe native IFTTT). However, this is your project and I will just name it that way. Do you want to have 1 module with all of these clobbed together? I would prefer to actually have 3 different modules, as then it is also much easier to deprecate, or add new modules which are similar.

Im asking these questions, as I do not really want to go about renaming these later on as this is what I find usually very troublesome with these projects.

[johannesjo]

Hmhm. You're totally right! I agree that interface or externalInterface is not really ideal neither :) Sometimes I think that good naming and coherent semantics is one of the most important and one of the most difficult thing in programming... My problem with integrations is that I use the terms "Jira-Integration" and "Git-Integration" very often. So this might be a little bit confusing. API(s) is probably correct, as we're providing an interface for other programs to hook into which does "nothing" by itself. Although this might be a little generic and misleading too. Maybe AppApis or DataApi? Thinking about it I think I would prefer API,apiorappApi` or something along those lines. I let you decide. You're probably more adept with the terms. :)

I think would prefer 4 different modules. One wrapper module and one for each api. We don't really need them atm. as I'm assuming all they contain will be a single effect handler class, but if we come to the conclusion that we need to do more complicated stuff such as initialization code, it's nice to have them completely separated from the start and the wrapper module is nice, if one quickly wants to deactivate all three and also to quickly see that they serve a similar purpose.

[johannesjo]

Hey there! Are you still interested in doing this?

[KonTy]

Very interesting discussion guys. IMHO I think this is an overkill currently to be honest because there are a lot of other features that are more important.

Also off topic blink(1) is insanely over priced! You can pick up 3pack Trinket for $10 on Aliexpress and each trinket can control not only while bunch of LEDs but also LCD screens https://www.instructables.com/id/RGB-LED-lighting-effects-with-Adafruit-Trinket/

[KonTy]

Haha with the trinket you can go nuts like this and it will still be cheaper then blink(1)

https://www.amazon.com/Adafruit-RGB-LED-Neopixel-Ring/dp/B00K9M3WXG/ref=pd_bxgy_201_img_2/133-6144336-4886060?_encoding=UTF8&pd_rd_i=B00K9M3WXG&pd_rd_r=73618cd2-fa26-48ac-a9df-d555f3229a9b&pd_rd_w=fg9Se&pd_rd_wg=llYNX&pf_rd_p=a2006322-0bc0-4db9-a08e-d168c18ce6f0&pf_rd_r=0C915JXW6RX56GTP12YT&psc=1&refRID=0C915JXW6RX56GTP12YT