Reply
Thread Tools
pacman's Avatar
Posts: 89 | Thanked: 532 times | Joined on Sep 2015
#31
Please guys, don't hijack this thread with general discussions about the pros and cons of different programming languages There are plenty of other places for that kind of thing.

@Modulebaan is quite right to have identified messaging as a weak point on SFOS, and his proposal to do something about it is more than welcome
 

The Following 8 Users Say Thank You to pacman For This Useful Post:
Posts: 307 | Thanked: 488 times | Joined on Sep 2010 @ USA around Chicago
#32
Will this app someday be able to take care of SMS/MMS also? Does Sailfish allow to use different app for SMS/MMS?

If this is possible, will this be able to solve the big problem of not supporting group SMS/MMS in default messaging app.
__________________
Apps for iPhone & iPad
Malayalam Keyboard for iPhoneTelugu Keyboard for iPhoneGujarati Keyboard for iPhone
 

The Following 3 Users Say Thank You to abyzthomas For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#33
Modulebaan, will you use MartinK's universal components, so that the whole thing will work on any system that support qqc2 (such as nemo)?
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following User Says Thank You to marmistrz For This Useful Post:
Posts: 24 | Thanked: 142 times | Joined on Jan 2017 @ \
#34
From all the comments I read here, building a framework is hard and that's not the purpose of Transponder.

The current architecture looks like this:
  • Transponder QML UI
  • Matrix.org daemon
  • DBus interfaces to communicate
  • C++ as main language, PyOtherSide to add Python for certain SDKs

I'm not familiar with those components and the UI is shared with Sailfinder. I will not use those, I'm sorry. Feel free to write the UI yourself.
 

The Following 3 Users Say Thank You to Modulebaan For This Useful Post:
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#35
Originally Posted by Modulebaan View Post
I'm not familiar with those components and the UI is shared with Sailfinder. I will not use those, I'm sorry. Feel free to write the UI yourself.
It's basically a component set I wrote so that modRana (and any other apps using Universal Components) can have a single QML UI codebase that is independent of Silica/Qt Quick Controls or any specififc QML components set in particular.

But it's not yet another component set in itself, it's rather a common API layer with backends selectable at runtime (currently Silica & Qt Quick Controls), so an application using Universal Controls still looks native (an UC Button is a Silica Button on Sailfish OS and a QQC Button on Fedora for example).

I'm using this even during development of modRana - I can easily test and debug the UI directly on my Fedora desktop via the QQC backend, while on my Sailfish X Xperia the same UI code will run with the Silica backend. I've also used Universal Controls for porting modRana to Android, where QQC are available as part of the Qt 5 port to Android.

So that's just some background to explain what the Universal Components project is about. Of course if you already have an existing UI codebase based on Silica and or if you plan to only target Sailfish OS then I guess using Universal Components might not bring many benefits to your usecase.

And also, thanks yet again for taking on the Transponder project! I think it really has a potential to improve the currently suboptimal native messaging situation on Sailfish OS.
__________________
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 4 Users Say Thank You to MartinK For This Useful Post:
Posts: 286 | Thanked: 615 times | Joined on Jan 2011 @ Estonia
#36
Originally Posted by marmistrz View Post
So this will wind up as writing PRs against swiften. Not saying that it's not the best solution here, I don't know the alternatives.
I think, that shmoose is hands down the best xmpp client for sailfish now if it supports at least Message Carbons XEP-0280 (needs probably to use swift 4.0 base).

But the XMPP discussion seems to drift offtopic here, sorry for that...
 

The Following 2 Users Say Thank You to acrux For This Useful Post:
Feathers McGraw's Avatar
Posts: 654 | Thanked: 2,368 times | Joined on Jul 2014 @ UK
#37
Just to add to the discussion around the use of telepathy, I did quite a lot of research myself when writing PingYou for the coding competition. I didn't get very far - mostly just re-implemented account management stuff and exposed some extra options.

The main feature I implemented that isn't supported in jolla-messages was the ability to authorise subscription requests ("accept friend request"). This functionality sat alongside the closed source jolla settings menus (i.e. it was an alternative settings menu, and changes to one would be reflected in the other). I think this is the best way to work around closed source interfaces to open source components (build an alternative/complimentary interface instead of waiting for Jolla to make the changes when it's probably not a priority for them).

One of the libraries I used was telepathy-qt, which I had problems using with qml, it was written for Qt4 and there are some types that don't transfer easily to qml (or, my qml knowlege is too poor to see how to do it). I wrote a bit about how far I got with that in the development readme.

Adding new features/XEPs to telepathy is difficult on Sailfish because you would have to push the changes upstream, and get them approved by Jolla etc, which makes rapid development quite difficult. I don't know what would happen if you built your own packages and made them dependencies on openrepos (would it break other parts of the telepathy stack? seems risky). Having researched which XEPs are available currently, and the progress of people who have implemented support for quite simple XEPs (like carbons) themselves and submitted pull requests, I have to say I think the whole process is very cumbersome and it seems to take ages to get anything done.

However, it's worth noting that it is possible in theory to write a connection manager in any language (including python), so you could write telepathy-matrix and re-use the rest of the stack.

Swings and roundabouts.
 

The Following 6 Users Say Thank You to Feathers McGraw For This Useful Post:
Posts: 24 | Thanked: 142 times | Joined on Jan 2017 @ \
#38
@MartinK Your components are pretty nice! I really like them but since I only target SFOS and I have already an UI ready, I'm not going to use them, keep it up though!

I really appreciate the feedback on Transponder, the initial design is completely gone at the moment more info and Github commits on Transponder are on the way.
 

The Following 7 Users Say Thank You to Modulebaan For This Useful Post:
Posts: 201 | Thanked: 410 times | Joined on Dec 2013
#39
Any news on the status of this project?
 

The Following 2 Users Say Thank You to gaelic For This Useful Post:
Posts: 286 | Thanked: 615 times | Joined on Jan 2011 @ Estonia
#40
Originally Posted by gaelic View Post
Any news on the status of this project?
https://github.com/DylanVanAssche/harbour-transponder
Last commit January 29th
 

The Following 4 Users Say Thank You to acrux For This Useful Post:
Reply

Tags
messaging, native, python, sailfish os, telepathy

Thread Tools

 
Forum Jump


All times are GMT. The time now is 04:43.