Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 2 days, 15 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 3 days, 11 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 5 days, 20 hrs ago - more...
| The Following 10 Users Say Thank You to otsaloma For This Useful Post: | ||
|
2018-01-30
, 20:50
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#12
|
Originally Posted by otsaloma
Very interesting reading, thank you for sharing it!
FWIW, there was a lot of discussion recently on GNOME's desktop-devel-list about Telepathy and Matrix.
- https://mail.gnome.org/archives/desk...ead.html#00047
- https://mail.gnome.org/archives/desk...ead.html#00112
Messaging is not a field I'm familiar with, but it seemed to me that people have issues with Telepathy and that Telepathy's design is not considered a success -- red flags to me regarding choosing what to build on.
|
|
2018-01-31
, 00:11
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#13
|
Originally Posted by rinigus
Well, no. From observations so far (2013-now) basically every time a community initiative hit any UI work in the closed source components only Jolla developers can do things ground to a halt and have not moved since. In some cases developers switched to alternative solutions (all the UI patches, various IM clients).
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?
Just from top of my head:
- one category in the latest coding competition was won by patch adding GPG to the email client
- SIP is still waiting for UI integration (5 years and going strong!)
- third party applications still can't put settings pages to settings
- no multituser chat support (also quested by many users from day one)
- someone even tried to submit patches to the closed calendar UI "upstream" via the mailing list, only to be ignored
- usb tethering is still more or less hidden (by not being installed by default) for years due to missing UI elements (as discussed on a community meeting a while ago)
- AFAIK no new accounts or messaging providers have been added to the build in messaging system by a thirparty since Sailfish OS launched
So given this track-record it seems to me like a totally sensible idea to develop all these UI elements as the effert will not be blocked for years by requiring overworked Jolla developers to participate in it. I'd like to be proven wrong (and everyone is certainly welcome to chime in with any counter examples!) but it really seems to me like the only way to go.
__________________
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 13 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2018-01-31
, 04:22
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#14
|
@MartinK, my point was exactly the same - UI for messaging and accounts would have to written within this project. There is no hope to rely on closed source Jolla components.
From reading Gnome list archive posted by @otsaloma, I would have considered any multi-protocol messaging program carefully. Looks like lead telepathy dev had a rather large number of issues with it. I guess, unless you handle it according to the lowest denominator, as for SMS.
@Modulebaan, you are involved in developing Matrix client, right? Do you still plan to develop it separately into the full-featured one or want to merge relevant code over into this project?
From reading Gnome list archive posted by @otsaloma, I would have considered any multi-protocol messaging program carefully. Looks like lead telepathy dev had a rather large number of issues with it. I guess, unless you handle it according to the lowest denominator, as for SMS.
@Modulebaan, you are involved in developing Matrix client, right? Do you still plan to develop it separately into the full-featured one or want to merge relevant code over into this project?
| The Following 5 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-01-31
, 07:45
|
|
Posts: 24 |
Thanked: 142 times |
Joined on Jan 2017
@ \
|
#15
|
@Everyone
I understand what you mean Rinigus: Telepathy would integrate much better and requires 'less' effort to develop the backend due the integration with the OS.
As MartinK pointed out: Waiting for Jolla is going to harm this project that's why I want to take the Python/QML approach. The UI is already written for messaging and contacts (it's a shared component between Transponder and Sailfinder).
I want to integrate the Matrix client into Transponder, the first release of Transponder will only support Matrix, for the next versions I plan Telegram and other providers. Matriski will be deprecated as soon as Transponder with Matrix hits stable.
The beauty of the Python plugin system is that other people easily can add new backends to Transponder. Only a bridge file needs to be written as with Otsaloma's Pan Transit app.
I understand what you mean Rinigus: Telepathy would integrate much better and requires 'less' effort to develop the backend due the integration with the OS.
As MartinK pointed out: Waiting for Jolla is going to harm this project that's why I want to take the Python/QML approach. The UI is already written for messaging and contacts (it's a shared component between Transponder and Sailfinder).
I want to integrate the Matrix client into Transponder, the first release of Transponder will only support Matrix, for the next versions I plan Telegram and other providers. Matriski will be deprecated as soon as Transponder with Matrix hits stable.
The beauty of the Python plugin system is that other people easily can add new backends to Transponder. Only a bridge file needs to be written as with Otsaloma's Pan Transit app.
|
|
2018-01-31
, 08:07
|
|
Posts: 201 |
Thanked: 410 times |
Joined on Dec 2013
|
#16
|
Originally Posted by Modulebaan
Very nice project. Just out of curiosity (maybe i've overread it): is transponder working in the background (e.g. daemon)?
I want to integrate the Matrix client into Transponder, the first release of Transponder will only support Matrix, for the next versions I plan Telegram and other providers. Matriski will be deprecated as soon as Transponder with Matrix hits stable.
It is a main showstopper for me using a messaging application and needing it to have it running in foreground.
|
|
2018-01-31
, 08:20
|
|
Posts: 24 |
Thanked: 142 times |
Joined on Jan 2017
@ \
|
#17
|
Originally Posted by gaelic
Indeed, that's something we definitely need. No promises for the first versions but it's almost certainly it will have some kind of daemon.
Very nice project. Just out of curiosity (maybe i've overread it): is transponder working in the background (e.g. daemon)?
It is a main showstopper for me using a messaging application and needing it to have it running in foreground.
 |
|
2018-02-03
, 17:23
|
|
Posts: 89 |
Thanked: 532 times |
Joined on Sep 2015
|
#18
|
Originally Posted by Modulebaan
Do you plan for the matrix client to be fully functional (i.e. support exchange of pictures and videos, and have VOIP)? It would be fantastic to have all this natively rather than with Alien Dalvik. (Riot.im only partially works in my hands.)
I want to integrate the Matrix client into Transponder, the first release of Transponder will only support Matrix, for the next versions I plan Telegram and other providers. Matriski will be deprecated as soon as Transponder with Matrix hits stable.
I am already a matrix patron, and I would be happy to buy you a coffee if it helps the full functionality of matrix to land on SFOS
|
|
2018-02-06
, 16:53
|
|
Posts: 24 |
Thanked: 142 times |
Joined on Jan 2017
@ \
|
#19
|
Originally Posted by pacman
Sending files and stuff is on the roadmap. VOIP isn't at the moment since I lack the knowledge and time to implement this. Also the Python SDK doesn't support this.
Do you plan for the matrix client to be fully functional (i.e. support exchange of pictures and videos, and have VOIP)? It would be fantastic to have all this natively rather than with Alien Dalvik. (Riot.im only partially works in my hands.)
I am already a matrix patron, and I would be happy to buy you a coffee if it helps the full functionality of matrix to land on SFOS
|
|
2018-02-06
, 19:32
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#20
|
Are you sure that using python is a good idea?
I'm not talking performance here. I mean the maintainability. I've worked on a 50+KLOC python project and maintaining a bigger python codebase is a nightmare.
Python linters suck. Pylint is unable to properly handle classmethods, mypy had some problems too (I don't remember what kind of). The rest of linters will only scream at your style. Unless you have a giant test suite, with a really, really big test coverage and have a CI checking it all at every commit, the project will be unmaintainable. And even with this whole infra, it's a nightmare.
I'm not a fan of C++ either (Rust FTW) but when using a statically-typed language, the compiler at least pays attention that you're not doing utter nonsense.
/edit: btw. I see gajim spewing errors from time to time because the types don't match :P
besides, if shmoose were to be integrated into transponder (not discussed this yet with the main dev) - we're using swiften, so using python here would rule out the possibility of integration
I'm not talking performance here. I mean the maintainability. I've worked on a 50+KLOC python project and maintaining a bigger python codebase is a nightmare.
Python linters suck. Pylint is unable to properly handle classmethods, mypy had some problems too (I don't remember what kind of). The rest of linters will only scream at your style. Unless you have a giant test suite, with a really, really big test coverage and have a CI checking it all at every commit, the project will be unmaintainable. And even with this whole infra, it's a nightmare.
I'm not a fan of C++ either (Rust FTW) but when using a statically-typed language, the compiler at least pays attention that you're not doing utter nonsense.
/edit: btw. I see gajim spewing errors from time to time because the types don't match :P
besides, if shmoose were to be integrated into transponder (not discussed this yet with the main dev) - we're using swiften, so using python here would rule out the possibility of integration
| The Following 3 Users Say Thank You to marmistrz For This Useful Post: | ||
 |
| Tags |
| messaging, native, python, sailfish os, telepathy |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 16:17.
Messaging is not a field I'm familiar with, but it seemed to me that people have issues with Telepathy and that Telepathy's design is not considered a success -- red flags to me regarding choosing what to build on.