Re: [SailfishDevel] SyncML topic revived
Finally we might get contacts sync via BT \o/ Good luck warrior! tortoisedoc On Sat, Jun 8, 2019 at 5:55 PM deloptes wrote: > > Hi Slava, > > > Slava Monich wrote: > > > Hi, > > > >> Hi, > >> thank you for answering. I see both available in the SDK (I still have > >> 3.0.2.28) > >> > >> kf5bluezqt-bluez5-5.24.0+git15-1.3.2.jolla.i486 > >> libbluez-qt5-0.1.26-1.3.2.jolla.i486 > >> > >> but I can not find source for libbluez-qt5 on mer. I find a note in > >> Changelog for SFOS 2.2.1 > >> > >> Can someone point to the repo used? > > > > > > https://git.merproject.org/mer-core/libbluez-qt > > > > > > thank you very much! I now see this is a library for bluez4. Thanks again! > > > >> When I clone the source bluez-qt5 from KDE, I see that the the version is > >> more mature than what is being used in kf5bluezqt-bluez5-5.24.0, but it > >> also states dependency on Qt-5.10. > > > > > > This could be a reasonable first step - to find out whether the latest > > stuff really depends on Qt 5.10 or somebody was like "oh, I've just > > switched to Qt 5.10, let's bump the dependency". I find it hard to > > imagine that anything Qt 5.10 specific would be actually required by a > > simple D-Bus wrapper. > > > > > > Hmm, yes indeed using the KDEs bluez-qt than what is in mer > kf5bluezqt/bluez-qt seems to be of advantage. Perhaps kf5bluezqt/bluez-qt > need to be lifted to KDEs bluez-qt one. It looks like they dropped support > for bluez4 and added more features from bluez5. > As it is coming from KDE, it might be that 5.10 is the version of Qt they > are using. But indeed investigation is needed if it would work. This adds > on top of what was originally intended :). However now at least the path is > more or less clear kf5bluezqt/bluez-qt -> buteosyncfw -> > buteo-sync-plugins. Wish me joy! > > >> Can you please comment on when new Qt version is expected? On the road > >> map it says 5.9 will expire LST next year and we are stuck at 5.6. I know > >> there was discussion in the past, but can't recall the details. > > > > > > I don't know much about that either, just that it's a licensing/legal > > issue. It's not technical. > > > > Yes, indeed I recall reading the same, but was interested in what is planned > for the future. > > Thanks and 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
Hi Slava, Slava Monich wrote: > Hi, > >> Hi, >> thank you for answering. I see both available in the SDK (I still have >> 3.0.2.28) >> >> kf5bluezqt-bluez5-5.24.0+git15-1.3.2.jolla.i486 >> libbluez-qt5-0.1.26-1.3.2.jolla.i486 >> >> but I can not find source for libbluez-qt5 on mer. I find a note in >> Changelog for SFOS 2.2.1 >> >> Can someone point to the repo used? > > > https://git.merproject.org/mer-core/libbluez-qt > > thank you very much! I now see this is a library for bluez4. Thanks again! >> When I clone the source bluez-qt5 from KDE, I see that the the version is >> more mature than what is being used in kf5bluezqt-bluez5-5.24.0, but it >> also states dependency on Qt-5.10. > > > This could be a reasonable first step - to find out whether the latest > stuff really depends on Qt 5.10 or somebody was like "oh, I've just > switched to Qt 5.10, let's bump the dependency". I find it hard to > imagine that anything Qt 5.10 specific would be actually required by a > simple D-Bus wrapper. > > Hmm, yes indeed using the KDEs bluez-qt than what is in mer kf5bluezqt/bluez-qt seems to be of advantage. Perhaps kf5bluezqt/bluez-qt need to be lifted to KDEs bluez-qt one. It looks like they dropped support for bluez4 and added more features from bluez5. As it is coming from KDE, it might be that 5.10 is the version of Qt they are using. But indeed investigation is needed if it would work. This adds on top of what was originally intended :). However now at least the path is more or less clear kf5bluezqt/bluez-qt -> buteosyncfw -> buteo-sync-plugins. Wish me joy! >> Can you please comment on when new Qt version is expected? On the road >> map it says 5.9 will expire LST next year and we are stuck at 5.6. I know >> there was discussion in the past, but can't recall the details. > > > I don't know much about that either, just that it's a licensing/legal > issue. It's not technical. > Yes, indeed I recall reading the same, but was interested in what is planned for the future. Thanks and regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Hi, Hi, thank you for answering. I see both available in the SDK (I still have 3.0.2.28) kf5bluezqt-bluez5-5.24.0+git15-1.3.2.jolla.i486 libbluez-qt5-0.1.26-1.3.2.jolla.i486 but I can not find source for libbluez-qt5 on mer. I find a note in Changelog for SFOS 2.2.1 Can someone point to the repo used? https://git.merproject.org/mer-core/libbluez-qt When I clone the source bluez-qt5 from KDE, I see that the the version is more mature than what is being used in kf5bluezqt-bluez5-5.24.0, but it also states dependency on Qt-5.10. This could be a reasonable first step - to find out whether the latest stuff really depends on Qt 5.10 or somebody was like "oh, I've just switched to Qt 5.10, let's bump the dependency". I find it hard to imagine that anything Qt 5.10 specific would be actually required by a simple D-Bus wrapper. Can you please comment on when new Qt version is expected? On the road map it says 5.9 will expire LST next year and we are stuck at 5.6. I know there was discussion in the past, but can't recall the details. I don't know much about that either, just that it's a licensing/legal issue. It's not technical. Thank you in advance again regards Cheers, -Slava ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
