https://bugs.kde.org/show_bug.cgi?id=440493
popov895 changed:
What|Removed |Added
See Also||https://bugs.kde.org/show_b
|
https://bugs.kde.org/show_bug.cgi?id=440493
Nate Graham changed:
What|Removed |Added
Resolution|--- |FIXED
Status|CONFIRMED
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #30 from Nate Graham ---
Right you are. It listens for sleep or shutdown/reboot, but not logout. Should
be an easy fix.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #29 from popov895 ---
Yes, it works in both cases. I guess the problem is that saveState () is only
called on shutdown and sleep, but not on logout.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #28 from Nate Graham ---
Does it work properly for you only when the config file has
`bluetoothBlocked=true` in it? Or does it also work if the config file has
`bluetoothBlocked=false` in it?
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=440493
Nate Graham changed:
What|Removed |Added
Status|REPORTED|CONFIRMED
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #26 from popov895 ---
It seems that in the case of "Remember previous status" is checked there must
be a parameter bluetoothBlocked in the ~/.config/bluedevilglobalrc.
Just checked out, and it works with bluetoothBlocked parameter as it sho
https://bugs.kde.org/show_bug.cgi?id=440493
Nate Graham changed:
What|Removed |Added
Resolution|WAITINGFORINFO |---
Status|NEEDSINFO
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #24 from popov895 ---
Still doesn't work. "Enable Bluetooth" and "Disable Bluetooth" work, but
"Remember previous status" doesn't. But I found that the
~/.config/bluedevilglobalrc is empty when the "Remember previous status" is
checked. Is t
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #23 from Nate Graham ---
> with default settings
Ohh... Can you do a test for me: change the default setting to something else,
and see if that setting works for you. Then change it back to the default
"Remember" setting, and see if it work
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #22 from popov895 ---
Created attachment 143291
--> https://bugs.kde.org/attachment.cgi?id=143291&action=edit
Log
Can be reproduced on a KDE neon Developer Edition live image with default
settings. Attached log in debug mode.
--
You are
https://bugs.kde.org/show_bug.cgi?id=440493
Nate Graham changed:
What|Removed |Added
Status|REOPENED|NEEDSINFO
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=440493
popov895 changed:
What|Removed |Added
Resolution|FIXED |---
CC||
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #19 from Nate Graham ---
I am asserting that the previous default setting (leave it up to the distro's
default configuration) was useless. Consider the following use cases:
If you wanted bluetooth active at login and your distro configured
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #18 from Krzysztof Krakowiak ---
(In reply to Nate Graham from comment #17)
> Plenty of people complained; that's why this option was added. :)
>
> I think the least invasive option is the "remember previous status" one,
> which is why it's
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #17 from Nate Graham ---
Plenty of people complained; that's why this option was added. :)
I think the least invasive option is the "remember previous status" one, which
is why it's the new default. It's hard for me to imagine a real use ca
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #16 from Krzysztof Krakowiak ---
(In reply to Nate Graham from comment #15)
> Thanks, but the problem with all of those suggestions is that they only make
> sense if you already have the concept in your mind that multiple parts of
> the syst
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #15 from Nate Graham ---
Thanks, but the problem with all of those suggestions is that they only make
sense if you already have the concept in your mind that multiple parts of the
system can affect the same setting, and also if you know what
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #14 from Krzysztof Krakowiak ---
(In reply to Nate Graham from comment #13)
> Can you come up with a wording that would make sense to a user who does not
> know about or understand the concept of a settings hierarchy and does not
> know what
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #13 from Nate Graham ---
Can you come up with a wording that would make sense to a user who does not
know about or understand the concept of a settings hierarchy and does not know
what the default value that would not be changed happens to b
https://bugs.kde.org/show_bug.cgi?id=440493
Krzysztof Krakowiak changed:
What|Removed |Added
CC||krzysztof.krakowiak@gmail.c
https://bugs.kde.org/show_bug.cgi?id=440493
Nate Graham changed:
What|Removed |Added
Version Fixed In||5.23
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=440493
Bug Janitor Service changed:
What|Removed |Added
Status|CONFIRMED |ASSIGNED
--- Comment #10 from Bug Janitor
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #9 from Nate Graham ---
Hmm, looks like the code already has the ability to save and resume enablement
state before and after suspend. I guess we just need to wire that up to login
and logout too, in conjunction with this new UI to control w
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #8 from Nate Graham ---
We could do that, though the "do not change" value has proven confusing to
users because it implies the existence of a settings hierarchy that most people
are not already familiar with.
--
You are receiving this mai
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #7 from Ilya Bizyaev ---
Not sure if it's a bug, we already have such behavior for Num Lock:
At Plasma startup
[ ] On
[ ] Off
[ ] Do not change
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #6 from Nate Graham ---
I see, so your proposal is to have a setting which simply overrides the value
in the config file, whatever it is. So if AutoEnable=true is set in the config
file but we make bluedevil able to do this, then it would si
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #5 from Ilya Bizyaev ---
I implicitly phrased my idea in the first comment ("have this checkbox ticked
for me"):
1) Plasma knows if Bluetooth is enabled or not
2) Plasma can enable Bluetooth at user's request without touching any config
fil
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #4 from Nate Graham ---
I did some investigation.
Looking through the source code at
https://git.kernel.org/pub/scm/bluetooth/bluez.git/, it would appear that this
AutoEnable option is only accessible through the global config file in /etc.
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #3 from Nate Graham ---
Hah, there's a package named "bluez-auto-enable-devices". I guess you want
that.
Needless to say, this is screaming out in terror/rage for a GUI option in
System Settings. :)
--
You are receiving this mail because:
https://bugs.kde.org/show_bug.cgi?id=440493
--- Comment #2 from Ilya Bizyaev ---
(In reply to Nate Graham from comment #1)
> I did some digging and found that this is controlled by the AutoEnable key
> in in /etc/bluetooth/main.conf. I found that my config file has
> AutoEnable=true. Does yours h
https://bugs.kde.org/show_bug.cgi?id=440493
Nate Graham changed:
What|Removed |Added
Summary|Add an option to enable |Add an option for whether
|Blue
32 matches
Mail list logo
