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
