> On April 17, 2015, 12:41 p.m., Lamarque Souza wrote: > > kded/bluetoothmonitor.h, line 41 > > <https://git.reviewboard.kde.org/r/123388/diff/2/?file=361568#file361568line41> > > > > Is passing connectionName really necessary? The old code queries BlueZ > > to get the device name and use it as connectionName. That is something > > simular to using essid as connection name for wifi connections. Besides > > this particular change breaks compatibility with old Bluedevil versions. Is > > there a good reason for breaking compatibility here? > > David Rosca wrote: > Old Bluedevil is using Bluez 4 and this code is for Bluez 5, so it's > broken already. > I'd rather make sure that it will be called for valid device from > Bluedevil, besides Network Manager won't add connection for invalid device. > > Lamarque Souza wrote: > I mean, using bluetooth device name for connection name is usefull, why > just remove this feature alltogether instead of porting it to Bluez 5? > > David Rosca wrote: > The connection name will be provided by caller (Bluedevil) and it will be > "Device name Network" (same name as connection automatically added by Network > Manager)
That's what I thought. Ok then. Just update the copyright headers and this patch is good to go. - Lamarque ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123388/#review79116 ----------------------------------------------------------- On April 17, 2015, 11:40 a.m., David Rosca wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123388/ > ----------------------------------------------------------- > > (Updated April 17, 2015, 11:40 a.m.) > > > Review request for Solid, Jan Grulich, Lukáš Tinkl, and Lamarque Souza. > > > Repository: plasma-nm > > > Description > ------- > > This patch removes all Bluez related code from BluetoothMonitor. > It was used only to check if the device with specified address exists and if > it supports nap/dun profile. > The addBluetoothConnection method is currently not used anywhere, so this > shouldn't be an issue. If the check is important, we can do one call on > Bluedevil DBus interface. > > Bluedevil was using this method in Bluez 4 versions, but it got killed during > porting to Bluez 5. > NAP connections are now automatically added on successful pairing with the > device. > > I plan to bring the functionality back in Bluedevil, so that user can > manually add a network connection (DUN/NAP) for Bluetooth devices. > > lxr search: > http://lxr.kde.org/search?v=kf5-qt5&_filestring=&_string=%22addBluetoothConnection%22 > > > Diffs > ----- > > kded/bluetoothdbustype.h 1eeb3b2 > kded/bluetoothdbustype.cpp 4eee8af > kded/bluetoothmonitor.h f5e74ec > kded/bluetoothmonitor.cpp 9d833d2 > kded/dbus/org.freedesktop.DBus.ObjectManager.xml fa58c72 > kded/dbus/org.freedesktop.DBus.Properties.xml a71f409 > kded/CMakeLists.txt 51aa370 > kded/monitor.h ae89d3e > kded/monitor.cpp e33b918 > > Diff: https://git.reviewboard.kde.org/r/123388/diff/ > > > Testing > ------- > > Works as before, mobile connection wizard appears when trying to add dun > connection. > > > Thanks, > > David Rosca > >
_______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel