[systemsettings] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off

2021-02-02 Thread Claudius Ellsel
https://bugs.kde.org/show_bug.cgi?id=432107

--- Comment #13 from Claudius Ellsel  ---
Your use cases for the already existing options also apply to the ones I am
suggesting, though.

On a multi-user system, a user might want to restore his previous used state
(and this cannot be done at login screen level).

I understand now, though that apart from those use cases it might be better to
have the functionality implemented somewhere else, although I am not sure
whether it can be done at a central point, so all distributions can benefit,
maybe SDDM? But that would be off-topic.

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off

2021-02-01 Thread Wolfgang Bauer
https://bugs.kde.org/show_bug.cgi?id=432107

--- Comment #12 from Wolfgang Bauer  ---
(In reply to Claudius Ellsel from comment #11)
> (In reply to Wolfgang Bauer from comment #10)
> > (In reply to Claudius Ellsel from comment #9)
> > > Then this issue still remains relevant for KDE in my opinion. Basically I
> > > think it will be beneficial to for example have a fourth option that will
> > > use the BIOS setting (or/and another one that restores this setting from 
> > > the
> > > previous session).
> > I'm not sure it's possible from the KDE/Plasma side, and I don't see why
> > Plasma should change it to be different than on the login screen.
> > 
> > That's my opinion, of course.
> 
> It already is possible to set the setting to "on" and "off", so "remember"
> or "use BIOS value" might also work.

That's the question.
But why do it on the Plasma level?

Actually "Don't change" is supposed to do that IMHO.

> If Plasma shouldn't change it to be different from the login screen than
> even the already existing options are a bit pointless. But if it can be
> already done at login screen level, that would be even better, I guess.
I wouldn't consider them pointless.

On a multi-user system, one user could choose to have a different setting than
all others do, and might not even have the rights to change them on a system
level.

Again, my opinion of course.

But I'm sure there is a reason why it was implemented like this years ago.

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off

2021-02-01 Thread Claudius Ellsel
https://bugs.kde.org/show_bug.cgi?id=432107

--- Comment #11 from Claudius Ellsel  ---
(In reply to Wolfgang Bauer from comment #10)
> (In reply to Claudius Ellsel from comment #9)
> > Then this issue still remains relevant for KDE in my opinion. Basically I
> > think it will be beneficial to for example have a fourth option that will
> > use the BIOS setting (or/and another one that restores this setting from the
> > previous session).
> I'm not sure it's possible from the KDE/Plasma side, and I don't see why
> Plasma should change it to be different than on the login screen.
> 
> That's my opinion, of course.

It already is possible to set the setting to "on" and "off", so "remember" or
"use BIOS value" might also work.

If Plasma shouldn't change it to be different from the login screen than even
the already existing options are a bit pointless. But if it can be already done
at login screen level, that would be even better, I guess.

> > Ideally openSUSE would "upstream" the things they do for this and then use
> > the setting from KDE instead of relying on a hidden service for this.
> That has no relevance to KDE though. It's a service that runs on boot and
> also affects text mode.

I agree that the service itself has no relevance. But the NumLock features are
something I'd really like to see in KDE as well. But I might be wrong here and
getting that correct is up to every distribution, because it has to be done at
a lower level (unfortunately both distros with KDE that I have used, Manjaro
and Tumbleweed, currently don't seem to get this right, so I thought a more
centralistic solution might help).

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off

2021-02-01 Thread Wolfgang Bauer
https://bugs.kde.org/show_bug.cgi?id=432107

--- Comment #10 from Wolfgang Bauer  ---
(In reply to Claudius Ellsel from comment #9)
> Then this issue still remains relevant for KDE in my opinion. Basically I
> think it will be beneficial to for example have a fourth option that will
> use the BIOS setting (or/and another one that restores this setting from the
> previous session).
I'm not sure it's possible from the KDE/Plasma side, and I don't see why Plasma
should change it to be different than on the login screen.

That's my opinion, of course.

> Ideally openSUSE would "upstream" the things they do for this and then use
> the setting from KDE instead of relying on a hidden service for this.
That has no relevance to KDE though. It's a service that runs on boot and also
affects text mode.

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off

2021-01-26 Thread Nate Graham
https://bugs.kde.org/show_bug.cgi?id=432107

Nate Graham  changed:

   What|Removed |Added

   Assignee|k...@davidedmundson.co.uk|plasma-b...@kde.org
   Target Milestone|1.0 |---
 CC||n...@kde.org
  Component|general |kcm_keyboard
Product|plasmashell |systemsettings

-- 
You are receiving this mail because:
You are watching all bug changes.