Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 6 hrs ago - more...
| The Following 28 Users Say Thank You to Modulebaan For This Useful Post: | ||
243kof, abyzthomas, acrux, BentL, borghal, Bundyo, claustn, eekkelund, Feathers McGraw, HtheB, imaginaryenemy, jakibaki, Jordi, juiceme, karlos devel, klinglerware, lal, Merienth, mosen, mrsellout, olf, P@t, pacman, peterleinchen, rcolistete, sbock, taixzo, Wikiwide | ||
|
2018-01-29
, 23:34
|
|
Posts: 339 |
Thanked: 1,623 times |
Joined on Oct 2013
@ France
|
#2
|
Originally Posted by Modulebaan
Hi,
Transponder is a full blown messaging client for Sailfish OS with multiple providers using Python plugins
Thanks for taking this project !
As you are developing something new, I imagine it is to overcome problems of the existing solutions (at least in desktop world) like Pidgin (https://developer.pidgin.im/wiki/ThirdPartyPlugins) or Telepathy ?
| The Following 5 Users Say Thank You to Zeta For This Useful Post: | ||
|
|
2018-01-30
, 07:06
|
|
Posts: 24 |
Thanked: 142 times |
Joined on Jan 2017
@ \
|
#3
|
Indeed, I want to overcome these issues by using as much as possible the offical SDKs from each provider.
| The Following 3 Users Say Thank You to Modulebaan For This Useful Post: | ||
|
|
2018-01-30
, 08:31
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#4
|
I am not an expert in the area and started reading about messaging just few days ago after porting to the latest release which disabled hangouts. Hence my understanding can be patchy.
From reading about telepathy framework and your proposal, I am wondering whether its better to focus on already developed telepathy and develop around it. From the look of it, you should be able to make new plugins for new network types and make it all accessible through the whole system. As far as I can see, its possible to make modules in python as well via PyGObject, if you wish.
Taking into account closed source components, you would probably need to implement Accounts and Messager. But the whole lot of work on making parts work together, designing API for communication and implementing it, has been done already.
There is a mention of issues regarding telepathy. Which particular issues do you have in mind?
Do I miss something vital here that makes it better approach to start developing a new framework from scratch?
From reading about telepathy framework and your proposal, I am wondering whether its better to focus on already developed telepathy and develop around it. From the look of it, you should be able to make new plugins for new network types and make it all accessible through the whole system. As far as I can see, its possible to make modules in python as well via PyGObject, if you wish.
Taking into account closed source components, you would probably need to implement Accounts and Messager. But the whole lot of work on making parts work together, designing API for communication and implementing it, has been done already.
There is a mention of issues regarding telepathy. Which particular issues do you have in mind?
Do I miss something vital here that makes it better approach to start developing a new framework from scratch?
|
|
2018-01-30
, 12:42
|
|
Posts: 24 |
Thanked: 142 times |
Joined on Jan 2017
@ \
|
#5
|
Originally Posted by rinigus
I understand your concerns but I want to keep Transponder separated from the integrated Telepathy stuff for several reasons:
I am not an expert in the area and started reading about messaging just few days ago after porting to the latest release which disabled hangouts. Hence my understanding can be patchy.
From reading about telepathy framework and your proposal, I am wondering whether its better to focus on already developed telepathy and develop around it. From the look of it, you should be able to make new plugins for new network types and make it all accessible through the whole system. As far as I can see, its possible to make modules in python as well via PyGObject, if you wish.
Taking into account closed source components, you would probably need to implement Accounts and Messager. But the whole lot of work on making parts work together, designing API for communication and implementing it, has been done already.
There is a mention of issues regarding telepathy. Which particular issues do you have in mind?
Do I miss something vital here that makes it better approach to start developing a new framework from scratch?
- Telepathy integration doesn't play well with Harbour and I really require this.
- Depending on Telepathy implementation in SFOS, porting to UT, Plasma, ... is more difficult
Jolla's Telepathy doesn't support properly group chats, files sending like it should. Transponder should reach the state of Sailorgram (in the future)
| The Following 8 Users Say Thank You to Modulebaan For This Useful Post: | ||
|
|
2018-01-30
, 14:41
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#6
|
Also if I remember correctly, there is still the closed source UI layer, so even if community implemented all the backend stuff, someone from Jolla would have to do the UI bits to actually make it useful, which is unfortunately very unlikely to happen given similar cases in the past.
(IIRC, SIP support is basically in place backend wise, but the UI is missing and the community has been waiting for Jolla to do something about it for years and can't do anything due to UI being closed source. And there are many other similar cases.)
So while I would also, like rinigius, want to have a full featured unified messaging UX (it worked very well on the N900!) I'm afraid it's not really possible to do with Telepathy and the closed UI. At least unless there would be a concrete promise from Jolla to help with the UI bits or ideally to finally open source the relevant UI bits.
(IIRC, SIP support is basically in place backend wise, but the UI is missing and the community has been waiting for Jolla to do something about it for years and can't do anything due to UI being closed source. And there are many other similar cases.)
So while I would also, like rinigius, want to have a full featured unified messaging UX (it worked very well on the N900!) I'm afraid it's not really possible to do with Telepathy and the closed UI. At least unless there would be a concrete promise from Jolla to help with the UI bits or ideally to finally open source the relevant UI bits.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
| The Following 8 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2018-01-30
, 14:51
|
|
Posts: 959 |
Thanked: 3,427 times |
Joined on Apr 2012
|
#7
|
One of the features I've been trying to integrate into Saera is the ability to read texts aloud as they come in, or to send them with dictation. Will Transponder have a method to allow other apps to communicate with it?
__________________
Saera: A Siri clone for the N900, N9(50) and Jolla
Follow me on Twitter: twitter.com/taixzo
Saera: A Siri clone for the N900, N9(50) and Jolla
Follow me on Twitter: twitter.com/taixzo
| The Following 4 Users Say Thank You to taixzo For This Useful Post: | ||
|
|
2018-01-30
, 15:03
|
|
Posts: 287 |
Thanked: 618 times |
Joined on Jan 2011
@ Estonia
|
#8
|
Originally Posted by Modulebaan
Modern XMPP/Jabber support with at least Message Carbons and Message Archive Management and multiple accounts and multiuser chat.
Any feedback or ideas on this project are more then welcome!
Most of this is missing in stock Sailfish xmpp account framework making it very limited.
I know that the probably best Linux desktop xmpp application Gajim is heavily based on python but not sure it can be any use in your project...
| The Following 3 Users Say Thank You to acrux For This Useful Post: | ||
|
|
2018-01-30
, 15:51
|
|
Posts: 24 |
Thanked: 142 times |
Joined on Jan 2017
@ \
|
#9
|
Originally Posted by taixzo
In the future this is possible, however I like my privacy so retrieving and sending messages would need some kind of authorization between Transponder and other apps.
One of the features I've been trying to integrate into Saera is the ability to read texts aloud as they come in, or to send them with dictation. Will Transponder have a method to allow other apps to communicate with it?
|
|
2018-01-30
, 18:06
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#10
|
Originally Posted by Modulebaan
According to Plasma Mobile page they also use Telepathy. From some old docs, looks like Ubuntu Touch used Telepathy.
I understand your concerns but I want to keep Transponder separated from the integrated Telepathy stuff for several reasons:
- Telepathy integration doesn't play well with Harbour and I really require this.
- Depending on Telepathy implementation in SFOS, porting to UT, Plasma, ... is more difficult
Jolla's Telepathy doesn't support properly group chats, files sending like it should. Transponder should reach the state of Sailorgram (in the future)
I don't know about the differences in implementation between Plasma/SFOS/UT. Are there any examples?
What looks to me as a main advantage is that you can hook yourself to the existing components and expand as you progress. As for Store, I would suggest to be more critical in having it and not to spend too much time in playing by its rules. They are quite limiting and should not lead to bad design.
Originally Posted by MartinK
This proposed messaging client will have to implement UI for messaging, UI for accounts, API to link multiple backends with the frontend, and battery-efficient backends. In that sense, using existing API and having to work with "just" UI is a simple undertaking, isn't it?
Also if I remember correctly, there is still the closed source UI layer, so even if community implemented all the backend stuff, someone from Jolla would have to do the UI bits to actually make it useful, which is unfortunately very unlikely to happen given similar cases in the past.
I agree with @Modulebaan in terms of keeping development easily relocatable - with significant closed source components we should be ready to move out from SFOS as a platform. So, having functional alternative UI would be handy.
Originally Posted by taixzo
@taixzo, what was the stumbling block? From all the overviews of Telepathy API it seems that it was designed to have multiple components interacting and it should support such feature out of the box.
One of the features I've been trying to integrate into Saera is the ability to read texts aloud as they come in, or to send them with dictation. Will Transponder have a method to allow other apps to communicate with it?
As always, its up to the main dev to choose the direction and there are many factors in the equation, including learning-by-doing component. One aspect that I would like to bring out is that its a lot you could learn when working on bigger project that has its Q&A for the code and contributions well developed. Don't know much about telepathy, but I surely did learn much by working with the others and contributing to larger projects.
Whatever way you choose, good luck!
 |
| Tags |
| messaging, native, python, sailfish os, telepathy |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 18:49.
Transponder is a full blown messaging client for Sailfish OS with multiple providers using Python plugins
Purpose
Transponder wants to fix the lack of messaging clients on Sailfish OS by providing a modular architecture which can be used with multiple providers like Matrix.org, Telegram, IRC, Hangouts, ... as long as their is a Python SDK for it.
Why Python?
I know, C++ with Qt is a nice combination and faster then Python, but Python has already a SDK for a lot of messaging providers which will make the integration and maintaining of a large group of providers possible.
Status
The development of Transponder is in it's early stages.
Donations
You can support me by buying me a coffee: PayPal.me link
Any feedback or ideas on this project are more then welcome!
Last edited by Modulebaan; 2018-05-10 at 14:54.