- User Since
- Aug 24 2015, 11:06 AM (230 w, 2 d)
Thu, Jan 16
Wed, Jan 15
- Code improvements
Mon, Jan 13
Address review comments:
- Add text to the toolbutton and make it checkable
- Allow to create hotspot only if WiFi is available or it's not used as primary connection
Sat, Jan 11
Can someone please look into this review? Either try it or check the code? I would like to have this as part of Plasma 5.18 and deadline for that is in few days. @ngraham how is it going with the icon?
Thu, Jan 9
Tue, Jan 7
I don't really remember, but I can see in the userHash() it's not used so this is probably safe. In the userHash() we directly use KUser().
Mon, Jan 6
It requires networkmanager-qt from master (upcoming 5.66 version).
I used ToolButton instead of a regular button, reason is that I don't think there is enough space. If there is modem device available, there will be three checkboxes on the left and with a regular button in various languages this might not be enough space.
Use button instead of checkbox
Fri, Jan 3
There are two things which need work or I'm not sure about:
- If this should be placed as a checkbox in the applet
- We need a different icon for the hotspot, currently there is no such icon in the Plasma theme and freeze for Plasma 5.18 is soon
Thu, Jan 2
Dec 20 2019
Dec 18 2019
I will land this once Flatpak 1.6 is released. While this can be used by older Flatpak version, it will not build with older Flatpak versions.
Dec 17 2019
Fix review comments
Dec 16 2019
: - Notification might be already closed
Dec 14 2019
Dec 12 2019
Dec 9 2019
I tested this now on KWin from master and the scaling seems to work fine, but I experienced broken Plasma, which might be because I installed KWin from master. Basically all Plasma stuff (panel, notifications) were semi-transparent and unclickable.
Dec 6 2019
I tried this patch in combination with https://phabricator.kde.org/D25611 and it breaks it completely.
Dec 5 2019
Dec 3 2019
Nov 26 2019
Nov 25 2019
Nov 20 2019
Nov 19 2019
Nov 18 2019
Nov 15 2019
We were actually saving already the value of current BT state, it was just not used. Your code assumes there is just one BT adapter, while in theory there might be more of them. What I would just is just simply not add property like m_tmpBluetoothEnabled and use m_bluetoothAdapters to check if the specific BT adapter was enabled before, that's why we save the object path together with the value. This should be done in the else if (enable && m_bluetoothAdapters.value(objPath)) branch. Just check whether it was enabled before and enable it in that case.
Nov 14 2019
You are right, I didn't properly read what you do. I still think we should modify the already existing function to additionaly save the previous state, because most of the code is same. The only difference is "Set" vs "Get" method on DBus.
Nov 13 2019
There is already a method to enable/disable BT, why don't you reuse it?