Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Tone Kastlunger wrote: > Strictly speaking, I don't see any problem with this - from a syncml > client / server > perspective; was the socket owned by the bluetooth manager also for bluez4 > as well? No, the problem is with Qt5 - There was a totally different mechanism and the service interface was removed in favor of profile. Anyway - the problem is even not there, but in the kf5bluezqt implementation of profile I guess. I was not looking further anymore. > If so, in this regard, there should be no change in responsibility for > the syncmlclient/server. > > About the KF5BluezQt, I totally agree - hoarding abstractions won't make > problems disappear; > I believe the extent of changes should be the driving force for the final > choice (i.e. the least complex > solution which requires the least changes). Less is more ;) > > Just my 2 cents. Thank you for the moral support. I do not know what is more or less. There are these 2-3 classes that need to be reworked anyway. I am happy with this POC for now, but I wish I had the time to do it in qt bluetooth now. The background is that I asked and Chris suggested to choose one and that kf5bluezqt was used in other projects. I did not know either qt5 bluetooth or kf5bluezqt. The latter seemed appealing and this is how I decided to use it. Then Chris mentioned @blam was more into bluetooth, who was sober reviewing the changes on buteo-syncfw and was wondering why I would use qt5 dbus instead kf5bluezqt. I am now convinced this was a good choice and I'll look forward to find the time and do a second PoC with qt5 bluetooth - just for the exercise. They offer QBluetoothSocket which seems to be more appropriate than a LocalSocket and perhaps also the low level c-style socket functions will disappear. I will not push a MR for now - will do the second PoC and we'll see. At the end we may end at DBus again :D regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
>These might be useful for another applications that may be using dbus, but >not for the syncml code that relies solely on filedescriptors outside dbus. Strictly speaking, I don't see any problem with this - from a syncml client / server perspective; was the socket owned by the bluetooth manager also for bluez4 as well? If so, in this regard, there should be no change in responsibility for the syncmlclient/server. About the KF5BluezQt, I totally agree - hoarding abstractions won't make problems disappear; I believe the extent of changes should be the driving force for the final choice (i.e. the least complex solution which requires the least changes). Less is more ;) Just my 2 cents. On Sun, Aug 4, 2019 at 11:31 PM deloptes wrote: > Chris Adams wrote: > > > Hi, > > > > (Sorry for top posting, OWA doesn't quote properly...) > > > > That old PR is actually mine, if you're referring to > > https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 > > > > I think it had some issues (e.g. didn't do UUID matching properly between > > client and server, so it was more of an "import" rather than a true > "sync" > > IIRC), which is why it wasn't merged. Subsequent syncs might cause > > duplication, or changes might not be propagated properly, in one > direction > > or the other. I don't recall precisely. > > > > Going forward: my personal opinion is that if you can make the required > > changes to the stack to get everything working, we'd definitely like to > > integrate those changes, as it would ensure that we have more parts of > our > > stack up-to-date, and less dead-code. > > > > That said, at this stage I don't believe that it's high priority > > internally, so not sure how much time/effort sailors will be able to > spend > > helping with this effort, unfortunately. Definitely can review and test, > > but may not be able to help with active development day to day. But am > > always happy to discuss etc (ping chriadam on freenode IRC in .au > > timezone, or perhaps flypig or pvuorela in .fi timezone). > > > > Best regards, > > Chris. > > > > > Hi, so I finished updating and testing, but I feel miserable, because > KF5BluezQt was looking very promissing in the beginning and at the end it > turned out to be of no big advantage to pure Qt5 DBus. > I am not sure if I should not remove KF5BluezQt and write everything only > with Qt5 - despite @blam advocating how good KF5BluezQt is. > > The biggest advantage perhaps is that it initializes when the adapter setup > is completed, but - there seems to be always a but and here come the > disadvantages. > The first disadvantage is that in the background bluetooth is going through > all known devices and registering services that are known to have been > supported to each device. > So at the time I can access the adapter I still do not know if I have to > register the service or not. So if I restart msyncd while BT is on it > crashes like "BUG: scheduling while atomic: kworker/0:1/12981/0x0002". > There is no issue, when msyncd is restarted if BT is off, because the > application is down - nothing on DBus. > > The second big disadvantage of KF5BluezQt is the profile handling. It does > support many profiles, but not the syncml server and client and creating > own profile turned to be very hard, because the profile should handle a > socket/file descriptor, which turns out problematic because of using > QDBusUnixFileDescriptor and QSharedPointer in combination. > These might be useful for another applications that may be using dbus, but > not for the syncml code that relies solely on filedescriptors outside dbus. > > For the moment the solution works fine, but in the area of the above I see > it as a work around over KF5BluezQt limitations. > It might be also me misinterpreting documentation or limited skills. > > The fact is I don't know what to do now. The time window I had for working > on this closes. The results are not bad - I can sync two most important - > contacts and calendar+todo like I was doing on the N9, but I wish I would > have the time to try Qt Bluetooth or go it directly via DBus. > > The question is to push or not to push :) > > Sorry for the long message, but I am not sure what to do next. I'll update > the PoC with what I have on the PC now. > > Ideas? > > regards > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Chris Adams wrote: > Hi, > > (Sorry for top posting, OWA doesn't quote properly...) > > That old PR is actually mine, if you're referring to > https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 > > I think it had some issues (e.g. didn't do UUID matching properly between > client and server, so it was more of an "import" rather than a true "sync" > IIRC), which is why it wasn't merged. Subsequent syncs might cause > duplication, or changes might not be propagated properly, in one direction > or the other. I don't recall precisely. > > Going forward: my personal opinion is that if you can make the required > changes to the stack to get everything working, we'd definitely like to > integrate those changes, as it would ensure that we have more parts of our > stack up-to-date, and less dead-code. > > That said, at this stage I don't believe that it's high priority > internally, so not sure how much time/effort sailors will be able to spend > helping with this effort, unfortunately. Definitely can review and test, > but may not be able to help with active development day to day. But am > always happy to discuss etc (ping chriadam on freenode IRC in .au > timezone, or perhaps flypig or pvuorela in .fi timezone). > > Best regards, > Chris. > Hi, so I finished updating and testing, but I feel miserable, because KF5BluezQt was looking very promissing in the beginning and at the end it turned out to be of no big advantage to pure Qt5 DBus. I am not sure if I should not remove KF5BluezQt and write everything only with Qt5 - despite @blam advocating how good KF5BluezQt is. The biggest advantage perhaps is that it initializes when the adapter setup is completed, but - there seems to be always a but and here come the disadvantages. The first disadvantage is that in the background bluetooth is going through all known devices and registering services that are known to have been supported to each device. So at the time I can access the adapter I still do not know if I have to register the service or not. So if I restart msyncd while BT is on it crashes like "BUG: scheduling while atomic: kworker/0:1/12981/0x0002". There is no issue, when msyncd is restarted if BT is off, because the application is down - nothing on DBus. The second big disadvantage of KF5BluezQt is the profile handling. It does support many profiles, but not the syncml server and client and creating own profile turned to be very hard, because the profile should handle a socket/file descriptor, which turns out problematic because of using QDBusUnixFileDescriptor and QSharedPointer in combination. These might be useful for another applications that may be using dbus, but not for the syncml code that relies solely on filedescriptors outside dbus. For the moment the solution works fine, but in the area of the above I see it as a work around over KF5BluezQt limitations. It might be also me misinterpreting documentation or limited skills. The fact is I don't know what to do now. The time window I had for working on this closes. The results are not bad - I can sync two most important - contacts and calendar+todo like I was doing on the N9, but I wish I would have the time to try Qt Bluetooth or go it directly via DBus. The question is to push or not to push :) Sorry for the long message, but I am not sure what to do next. I'll update the PoC with what I have on the PC now. Ideas? regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Damien Caliste wrote: > Ah, I see, when looking at the page of your project > (https://git.merproject.org/deloptes/bluez5_buteo-syncfw), it is not > defined as fork from mer-core. I guess, you created a new project and > push there from your computer. For Gitlab to know it's a fork, you have > to click on the fork button in the mer-core project page > (https://git.sailfishos.org/mer-core/buteo-syncfw). This will create a > new project under your login that is linked to mer-core. You can > directly push there since the local copy on your machine was cloned from > the mer-core one. So: > - click on fork in mer-core ; > - add a remote on your computer ; > - push to this new remote, then you can submit merge requests. > > Hope it helps, > > Damien. Damien, thank you for the help, really appreciated. I have a first win now. MR was created successfully. * Updated to use bluez5 !39 I will create one for the plugins next regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Damien Caliste wrote: > Strange, when you visit the branch page of your project > (https://git.merproject.org/deloptes/bluez5_buteo-syncfw/branches) do > you see "merge request" button for each branch ? Is it still returning > error 403 when you click on one ? > > Ah, I see, when looking at the page of your project > (https://git.merproject.org/deloptes/bluez5_buteo-syncfw), it is not > defined as fork from mer-core. I guess, you created a new project and > push there from your computer. For Gitlab to know it's a fork, you have > to click on the fork button in the mer-core project page > (https://git.sailfishos.org/mer-core/buteo-syncfw). This will create a > new project under your login that is linked to mer-core. You can > directly push there since the local copy on your machine was cloned from > the mer-core one. So: > - click on fork in mer-core ; > - add a remote on your computer ; > - push to this new remote, then you can submit merge requests. > > Hope it helps, Thank you, Damien. I think this might be the problem. First time always a fail :) I will check in the evening. regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Hello, Le 2019-07-30 11:00, deloptes a écrit : OK, thank you again. I read the documentation [1] and [2] now and tried it accordingly, but when I click the New merge request from bluez5_buteo-syncfw it goes to a new page "403" saying " You don't have the permission to access this page. Strange, when you visit the branch page of your project (https://git.merproject.org/deloptes/bluez5_buteo-syncfw/branches) do you see "merge request" button for each branch ? Is it still returning error 403 when you click on one ? Ah, I see, when looking at the page of your project (https://git.merproject.org/deloptes/bluez5_buteo-syncfw), it is not defined as fork from mer-core. I guess, you created a new project and push there from your computer. For Gitlab to know it's a fork, you have to click on the fork button in the mer-core project page (https://git.sailfishos.org/mer-core/buteo-syncfw). This will create a new project under your login that is linked to mer-core. You can directly push there since the local copy on your machine was cloned from the mer-core one. So: - click on fork in mer-core ; - add a remote on your computer ; - push to this new remote, then you can submit merge requests. Hope it helps, Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Chris Adams wrote: > Usually you don't push to the main repository, but instead you create a > private fork of the repository, push your changes there (e.g. to > deloptes_bluez5 branch or something) and then create a merge request from > your private fork to the upstream repository. > > Then the MR will undergo review/testing etc until it's deemed ready for > merge and tag. OK, thank you again. I read the documentation [1] and [2] now and tried it accordingly, but when I click the New merge request from bluez5_buteo-syncfw it goes to a new page "403" saying " You don't have the permission to access this page. Please contact your GitLab administrator to get permission. " The URL is https://git.merproject.org/deloptes/bluez5_buteo-syncfw/merge_requests/new What can be this? Thank you in advance (for kickstarting) regards [1] https://git.sailfishos.org/help/user/project/merge_requests/index.md [2] https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Hi, Usually you don't push to the main repository, but instead you create a private fork of the repository, push your changes there (e.g. to deloptes_bluez5 branch or something) and then create a merge request from your private fork to the upstream repository. Then the MR will undergo review/testing etc until it's deemed ready for merge and tag. Best regards, Chris. From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes [delop...@gmail.com] Sent: Monday, July 29, 2019 3:05 AM To: devel@lists.sailfishos.org Subject: Re: [SailfishDevel] SyncML topic revived (further downthe rabbit hole) Chris Adams wrote: > Again sorry for top posting, using OWA which doesn't quote properly. > > It sounds like you're making good progress which is fantastic! > Please tag me in any merge requests (using @chriadam on github etc) so > that I get notified of them, and then I can review etc. > > Best regards, > Chris. > Hi, I think the work is done now. I asked how should I proceed, but no one responded. It looks like I do not have permissions or do not know something buteo-syncfw$ git push --set-upstream origin feat/bluez5v2 Username for 'https://git.merproject.org': deloptes Password for 'https://delop...@git.merproject.org': remote: You are not allowed to push code to this project. fatal: unable to access 'https://git.merproject.org/mer-core/buteo-syncfw.git/': The requested URL returned error: 403 Who can help? BTW buteo-sync-plugins is also ready https://git.sailfishos.org/deloptes/poc-bluez5-buteo-syncml-plugins I did not test Notes, but Contacts, Calendar and Tasks are working in terms that sync works. There are bugs I noticed in Contacts and Calendar, but I render them as not that critical and would open issues, when code is in place. My local setup is Phone Sailfish X with openobex 1.5.x. - I may test with jolla default version next I was just not sure if it works and new that it does with 1.5 Desktop TDE the tdepim plugins from Syncevolution sources Syncevolution 1.5.x Any plugin for Syncevolution - Gnome or KDE5 - would work, however I can not verify this. I think I tried Akonadi years ago For the setup I used the n900 template and the instructions on the Syncevolution web site. I run it like this SYCNEVOLUTION_DEBUG=3 syncevolution -r loglevel=6 xperiax addressbook calendar+todo Let me know what you think regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Chris Adams wrote: > Again sorry for top posting, using OWA which doesn't quote properly. > > It sounds like you're making good progress which is fantastic! > Please tag me in any merge requests (using @chriadam on github etc) so > that I get notified of them, and then I can review etc. > > Best regards, > Chris. > Hi, I think the work is done now. I asked how should I proceed, but no one responded. It looks like I do not have permissions or do not know something buteo-syncfw$ git push --set-upstream origin feat/bluez5v2 Username for 'https://git.merproject.org': deloptes Password for 'https://delop...@git.merproject.org': remote: You are not allowed to push code to this project. fatal: unable to access 'https://git.merproject.org/mer-core/buteo-syncfw.git/': The requested URL returned error: 403 Who can help? BTW buteo-sync-plugins is also ready https://git.sailfishos.org/deloptes/poc-bluez5-buteo-syncml-plugins I did not test Notes, but Contacts, Calendar and Tasks are working in terms that sync works. There are bugs I noticed in Contacts and Calendar, but I render them as not that critical and would open issues, when code is in place. My local setup is Phone Sailfish X with openobex 1.5.x. - I may test with jolla default version next I was just not sure if it works and new that it does with 1.5 Desktop TDE the tdepim plugins from Syncevolution sources Syncevolution 1.5.x Any plugin for Syncevolution - Gnome or KDE5 - would work, however I can not verify this. I think I tried Akonadi years ago For the setup I used the n900 template and the instructions on the Syncevolution web site. I run it like this SYCNEVOLUTION_DEBUG=3 syncevolution -r loglevel=6 xperiax addressbook calendar+todo Let me know what you think regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Tone Kastlunger wrote: > I think it'd be important to add it next to bluez4 dbus stuff (and hence > straightforward perhaps). > > I mean, adding bluez5 next to bluez4 support *might* just be easier (i.e. > less changes) than moving to Y.A.L. Bluez4 is beeing removed, but yes this is what I mean - Y.A.L. In this case can be easily avoided. Unfortunately as you know bluez5 is different and code needs to be reworked. In the case of bueto-sync-plugins - I will stick to kf5bluezqt - it saves a lot of work. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
>May be it is better using QDbus and not linking against kf5bluezqt and thus >making buteo-syncfw depend on this library for couple of operations >required to handle the sync profile. I think it'd be important to add it next to bluez4 dbus stuff (and hence straightforward perhaps). I mean, adding bluez5 next to bluez4 support *might* just be easier (i.e. less changes) than moving to Y.A.L. Just my 2 cents. best, tk On Fri, Jul 26, 2019 at 7:54 PM deloptes wrote: > Damien Caliste wrote: > > > What about buteo-syncfw ? > > May be it is better using QDbus and not linking against kf5bluezqt and thus > making buteo-syncfw depend on this library for couple of operations > required to handle the sync profile. > > I am still thinking about it and I'm not sure. > > Let me know what you think. > > regards > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Damien Caliste wrote: > What about buteo-syncfw ? May be it is better using QDbus and not linking against kf5bluezqt and thus making buteo-syncfw depend on this library for couple of operations required to handle the sync profile. I am still thinking about it and I'm not sure. Let me know what you think. regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Chris Adams wrote: > It sounds like you're making good progress which is fantastic! > Please tag me in any merge requests (using @chriadam on github etc) so > that I get notified of them, and then I can review etc. > Yes indeed, it works perfectly well. There are still some open questions and bugs as you mentioned before that are only visible in the logs - but nothing critical. However I will ask in different thread or via gitlab - creating issues that can be followed up. I think it is more or less ready to become an official WIP MR now. Can someone instruct me on how to proceed with this from now on - are there rules, guides on creating MRs. I do not want to cause troubles and I am not a pro in git. - What is the best way to create a MR out of my PoC. I mean I have many commits for backup purposes in the PoC, which not necessarily need be pushed, but if I do a big single one - then the many changes forth and back are confusing. It should be a series of commits that one can easily review. - Should I create a new, or push on top of your MR? I build upon it, I think it makes sense to push on top. What do you, experts, do in such case? What is your advise? Thank you in advance regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Damien Caliste wrote:
> Can you point out where did you push your modifications to buteo stack ?
> I would like to give a look and test.
>
> I guess that
> https://git.sailfishos.org/deloptes/poc-bluez5-buteo-syncml-plugins is a
> fork of buteo-sync-plugins with your changes. What about buteo-syncfw ?
>
> What client are you using on desktop side to test the plugin in phone ?
>
Hi,
yes indeed - this is the link - I was just doing PoC and Tone asked to
share.
The buteo-syncfw is not uploaded anywhere. I guess I will push MR to the
original repo. I can only offer the attached patch for now.
regards
diff --git a/libbuteosyncfw/common/TransportTracker.cpp b/libbuteosyncfw/common/TransportTracker.cpp
index 35097ec..3cff6d8 100644
--- a/libbuteosyncfw/common/TransportTracker.cpp
+++ b/libbuteosyncfw/common/TransportTracker.cpp
@@ -32,6 +32,8 @@
#include
#include
+#include
+
using namespace Buteo;
TransportTracker::TransportTracker(QObject *aParent) :
@@ -65,16 +67,24 @@ TransportTracker::TransportTracker(QObject *aParent) :
#endif
// BT
-// Set the bluetooth state
-iTransportStates[Sync::CONNECTIVITY_BT] = btConnectivityStatus();
-if (!iSystemBus.connect("org.bluez",
-"",
-"org.bluez.Adapter",
-"PropertyChanged",
-this,
-SLOT(onBtStateChanged(QString, QDBusVariant
+// Initialize BluezQt
+btManager = new BluezQt::Manager(this);
+if (btManager != 0) {
+BluezQt::InitManagerJob *initJob = btManager->init();
+initJob->start();
+connect(initJob, ::InitManagerJob::result,
+this, ::initBluez5ManagerJobResult/*,
+Qt::QueuedConnection*/);
+LOG_DEBUG("BT manager init started");
+// wait to complete
+while (!btManager->isOperational())
+{
+QCoreApplication::processEvents(QEventLoop::AllEvents, 100);
+}
+}
+else
{
-LOG_WARNING("Unable to connect to system bus for org.bluez.Adapter");
+LOG_CRITICAL("BT manager init failed");
}
// Internet
@@ -97,6 +107,7 @@ TransportTracker::TransportTracker(QObject *aParent) :
TransportTracker::~TransportTracker()
{
FUNCTION_CALL_TRACE;
+
}
bool TransportTracker::isConnectivityAvailable(Sync::ConnectivityType aType) const
@@ -116,16 +127,24 @@ void TransportTracker::onUsbStateChanged(bool aConnected)
updateState(Sync::CONNECTIVITY_USB, aConnected);
}
-void TransportTracker::onBtStateChanged(QString aKey, QDBusVariant aValue)
+void TransportTracker::onBtStateChanged(bool aValue)
{
FUNCTION_CALL_TRACE;
-if (aKey == "Powered")
+if (aValue)
{
-bool btPowered = aValue.variant().toBool();
-LOG_DEBUG("BT power state " << btPowered);
-updateState(Sync::CONNECTIVITY_BT, btPowered);
+// If BT was enabled, give the framework 2sec to complete
+LOG_DEBUG("BT state changed" << aValue << "(sending update in 2sec)");
+QTime dieTime= QTime::currentTime().addSecs(2);
+while (QTime::currentTime() < dieTime)
+QCoreApplication::processEvents(QEventLoop::AllEvents, 100);
}
+else
+{
+// else update state immediately
+LOG_DEBUG("BT state update - new state:" << aValue );
+}
+updateState(Sync::CONNECTIVITY_BT, aValue);
}
void TransportTracker::onInternetStateChanged(bool aConnected, Sync::InternetConnectionType aType)
@@ -142,7 +161,6 @@ void TransportTracker::updateState(Sync::ConnectivityType aType,
{
FUNCTION_CALL_TRACE;
-
bool oldState = false;
{
QMutexLocker locker();
@@ -158,57 +176,39 @@ void TransportTracker::updateState(Sync::ConnectivityType aType,
}
}
-bool TransportTracker::btConnectivityStatus()
-{
-FUNCTION_CALL_TRACE;
+void TransportTracker::initBluez5ManagerJobResult(BluezQt::InitManagerJob* job) {
-bool btOn = false;
-QDBusMessage methodCallMsg = QDBusMessage::createMethodCall("org.bluez",
-"/",
-"org.bluez.Manager",
-"DefaultAdapter");
+FUNCTION_CALL_TRACE;
-QDBusMessage reply = iSystemBus.call(methodCallMsg);
-if (reply.type() == QDBusMessage::ErrorMessage)
-{
-LOG_WARNING("This device does not have a BT adapter");
-return btOn;
+if (job->error()) {
+LOG_CRITICAL("BT manager init error:" << job->errorText());
+return;
}
-QList adapterList = reply.arguments();
-// We will take the first adapter in the list
-QString adapterPath = qdbus_cast(adapterList.at(0)).path();
+// @todo do we need to act on btManager status change?
+//connect(btManager, ::Manager::operationalChanged,
+//this, ::onBtStateChanged);
+// Make sure to
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Hello, Le 2019-07-23 13:41, deloptes a écrit : As my previous posts were not showing on the dev list, I write here to test if it works. In any case I'll be glad to receive some advises and review on the progress done. What I did is to - rebase btcalendar on current master and add latest changes - remove bluez4 from buteo-syncfw and buteo-sync-plugins - replace what needed with bluez5 and - had "a lot of fun" getting the plugins running. Now it works, but has few things to polish and of course to test. It will be indeed wonderful if someone could help with review and advise in the process. Can you point out where did you push your modifications to buteo stack ? I would like to give a look and test. I guess that https://git.sailfishos.org/deloptes/poc-bluez5-buteo-syncml-plugins is a fork of buteo-sync-plugins with your changes. What about buteo-syncfw ? What client are you using on desktop side to test the plugin in phone ? Thank you, Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Again sorry for top posting, using OWA which doesn't quote properly. It sounds like you're making good progress which is fantastic! Please tag me in any merge requests (using @chriadam on github etc) so that I get notified of them, and then I can review etc. Best regards, Chris. From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes [delop...@gmail.com] Sent: Tuesday, July 23, 2019 9:41 PM To: devel@lists.sailfishos.org Subject: Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole) Chris Adams wrote: > Hi, > > (Sorry for top posting, OWA doesn't quote properly...) > > That old PR is actually mine, if you're referring to > https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 > > I think it had some issues (e.g. didn't do UUID matching properly between > client and server, so it was more of an "import" rather than a true "sync" > IIRC), which is why it wasn't merged. Subsequent syncs might cause > duplication, or changes might not be propagated properly, in one direction > or the other. I don't recall precisely. > Do you mean the calendar part? We'll test for sure all of this before approaching you with MR. > Going forward: my personal opinion is that if you can make the required > changes to the stack to get everything working, we'd definitely like to > integrate those changes, as it would ensure that we have more parts of our > stack up-to-date, and less dead-code. > Thumbs up and fingers crossed! Thank you! > That said, at this stage I don't believe that it's high priority > internally, so not sure how much time/effort sailors will be able to spend > helping with this effort, unfortunately. Definitely can review and test, > but may not be able to help with active development day to day. But am > always happy to discuss etc (ping chriadam on freenode IRC in .au > timezone, or perhaps flypig or pvuorela in .fi timezone). As my previous posts were not showing on the dev list, I write here to test if it works. In any case I'll be glad to receive some advises and review on the progress done. What I did is to - rebase btcalendar on current master and add latest changes - remove bluez4 from buteo-syncfw and buteo-sync-plugins - replace what needed with bluez5 and - had "a lot of fun" getting the plugins running. Now it works, but has few things to polish and of course to test. It will be indeed wonderful if someone could help with review and advise in the process. Thank you in advance ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Chris Adams wrote: > Hi, > > (Sorry for top posting, OWA doesn't quote properly...) > > That old PR is actually mine, if you're referring to > https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 > > I think it had some issues (e.g. didn't do UUID matching properly between > client and server, so it was more of an "import" rather than a true "sync" > IIRC), which is why it wasn't merged. Subsequent syncs might cause > duplication, or changes might not be propagated properly, in one direction > or the other. I don't recall precisely. > Do you mean the calendar part? We'll test for sure all of this before approaching you with MR. > Going forward: my personal opinion is that if you can make the required > changes to the stack to get everything working, we'd definitely like to > integrate those changes, as it would ensure that we have more parts of our > stack up-to-date, and less dead-code. > Thumbs up and fingers crossed! Thank you! > That said, at this stage I don't believe that it's high priority > internally, so not sure how much time/effort sailors will be able to spend > helping with this effort, unfortunately. Definitely can review and test, > but may not be able to help with active development day to day. But am > always happy to discuss etc (ping chriadam on freenode IRC in .au > timezone, or perhaps flypig or pvuorela in .fi timezone). As my previous posts were not showing on the dev list, I write here to test if it works. In any case I'll be glad to receive some advises and review on the progress done. What I did is to - rebase btcalendar on current master and add latest changes - remove bluez4 from buteo-syncfw and buteo-sync-plugins - replace what needed with bluez5 and - had "a lot of fun" getting the plugins running. Now it works, but has few things to polish and of course to test. It will be indeed wonderful if someone could help with review and advise in the process. Thank you in advance ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Hi, (Sorry for top posting, OWA doesn't quote properly...) That old PR is actually mine, if you're referring to https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 I think it had some issues (e.g. didn't do UUID matching properly between client and server, so it was more of an "import" rather than a true "sync" IIRC), which is why it wasn't merged. Subsequent syncs might cause duplication, or changes might not be propagated properly, in one direction or the other. I don't recall precisely. Going forward: my personal opinion is that if you can make the required changes to the stack to get everything working, we'd definitely like to integrate those changes, as it would ensure that we have more parts of our stack up-to-date, and less dead-code. That said, at this stage I don't believe that it's high priority internally, so not sure how much time/effort sailors will be able to spend helping with this effort, unfortunately. Definitely can review and test, but may not be able to help with active development day to day. But am always happy to discuss etc (ping chriadam on freenode IRC in .au timezone, or perhaps flypig or pvuorela in .fi timezone). Best regards, Chris. From: Devel [devel-boun...@lists.sailfishos.org] on behalf of Damien Caliste [dcali...@free.fr] Sent: Saturday, July 20, 2019 9:16 PM To: devel@lists.sailfishos.org Subject: Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole) Hello, Le Samedi 20 juillet 2019, Tone Kastlunger a écrit : > buteo-sync-plugin tho, > so I suppose expectations for a more extensive changeset to be merged > upstream should be kept low? I'm afraid it's a question of poking. Submitter should ask for reason of silence or rejection up to getting an answer. I agree it's not nice. But Pekka or Chris always gave answers to my MRs in the past. Sometimes rejecting them but always with reasons and after discussion. So for this case, we can be optimistic! Have a nice day, Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Hello, Le Samedi 20 juillet 2019, Tone Kastlunger a écrit : > buteo-sync-plugin tho, > so I suppose expectations for a more extensive changeset to be merged > upstream should be kept low? I'm afraid it's a question of poking. Submitter should ask for reason of silence or rejection up to getting an answer. I agree it's not nice. But Pekka or Chris always gave answers to my MRs in the past. Sometimes rejecting them but always with reasons and after discussion. So for this case, we can be optimistic! Have a nice day, Damien. pgp3SZ8pHCtNx.pgp Description: OpenPGP digital signature ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Theres a dangling mr pending for over a year (for calendar sync) in the buteo-sync-plugin tho, so I suppose expectations for a more extensive changeset to be merged upstream should be kept low? On Saturday, July 20, 2019, Damien Caliste wrote: > Hello, > > Le Samedi 20 juillet 2019, deloptes a écrit : >> 5. 1.7 uses cmake and thus building does not work > You can build cmake projects in SDK also. Sailfish-office is one example, Calligra another one, while the latter is a bit complicated due to KF5 dependencies. > > In a nutshell, ssh into SDK, > - go to ~/share/... the project directory, > - create a tmp directory and enter it, > - enter target emulation with 'sb2 -t Sailfishos-xxx' (use TAB to complement), > - issue 'cmake ..', > - issue make. > > You can automate this in a spec file to create RPMs of course. > >> To me it looks like the whole stack is left unmaintained and I am not sure >> how the following components are going to be brought to a working state >> without a proper support. I mean even if community can do the work, how big >> are the chances that all the changes in following packages get merged into >> mainstream??? > I'm coming back from vacations next week, and I can help you building everything or modernize what is required. I'm sure Chris Adams or Pekka Vuorela will review any patch and be happy to merge everything making the stack up to date, when patches look good. > > Have a nice day, > > Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Hello, Le Samedi 20 juillet 2019, deloptes a écrit : > 5. 1.7 uses cmake and thus building does not work You can build cmake projects in SDK also. Sailfish-office is one example, Calligra another one, while the latter is a bit complicated due to KF5 dependencies. In a nutshell, ssh into SDK, - go to ~/share/... the project directory, - create a tmp directory and enter it, - enter target emulation with 'sb2 -t Sailfishos-xxx' (use TAB to complement), - issue 'cmake ..', - issue make. You can automate this in a spec file to create RPMs of course. > To me it looks like the whole stack is left unmaintained and I am not sure > how the following components are going to be brought to a working state > without a proper support. I mean even if community can do the work, how big > are the chances that all the changes in following packages get merged into > mainstream??? I'm coming back from vacations next week, and I can help you building everything or modernize what is required. I'm sure Chris Adams or Pekka Vuorela will review any patch and be happy to merge everything making the stack up to date, when patches look good. Have a nice day, Damien. pgpkgYlNevKXa.pgp Description: OpenPGP digital signature ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Chris Adams wrote: > Hi, > > Yes, I suspect that the Buteo plugins weren't updated when the rest of the > stack was upgraded to BlueZ 5. > I assume that you can simply update the code in that repository to use the > appropriate interfaces and APIs to begin the porting effort. I don't > believe that we mean to keep BlueZ 4 support working, so no need to have > two separate codepaths with ifdefs depending on version, instead can just > port directly to BlueZ 5 APIs. > > The two repositories with code that will probably need to be updated are: > https://git.merproject.org/mer-core/buteo-syncfw/ > https://git.merproject.org/mer-core/buteo-sync-plugins/ > Hi Chris, all, this "you can simply update the code" turns out to be not so simple. Down the rabbit hole I hit on openobex. I am basically doing some analyses and PoC, so here are my findings 1. buteo-syncml and buteo-sync-plugins use openobex library 2. openobex library provided is openobex-0.1.4-1.2.1.jolla.armv7hl 3. on mer openobex is 1.7 4. in sailfish git reference is set to mer 5. 1.7 uses cmake and thus building does not work 6. in 1.7 significant change was done, so that all relaying code needs to be migrated/upgraded. On my desktop PC I still use 1.5.2 which seems to be stable and working with older applications 7. in sailfish git in rpm/openobex.yaml "Requires" is set to bluez-libs-devel, which breaks other dependencies. Why is it set to require bluez-libs-devel? IMO it should be removed put it all together this obex stuff that I desperately need for advancing on syncml is totally creepy. The way I go now is use openobex 1.5.2 which builds properly with sailfish. Please, let me know what you think and how this can be corrected for the future. To me it looks like the whole stack is left unmaintained and I am not sure how the following components are going to be brought to a working state without a proper support. I mean even if community can do the work, how big are the chances that all the changes in following packages get merged into mainstream??? - buteo-syncfw - buteo-syncml - buteo-sync-plugins - openobex Thank you in advance and kind regards PS: It is a pleasure to use the SDK - works smoothly :) ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
