https://bugs.documentfoundation.org/show_bug.cgi?id=120206
--- Comment #10 from Eyal Rozenberg <eyal...@technion.ac.il> ---
(In reply to Mike Kaganski from comment #8)
> (In reply to Eyal Rozenberg from comment #7)
> > I hope this clarifies things.
>
> No it does not.
> I didn't ask *which distributions of Linux* are configured to treat Scroll
> Lock that way. I asked *which flavor of LibreOffice* are you talking about.
The one that you download from libreoffice.org - the "TDF package"
> Linux distributions may implement the Scroll Lock involvement in the layout
> status differently; and taking the information would be implemented
> differently depending upon the software used there.
But right now it's not implemented at all. That is, LO considers at the LED
status, not the Scroll Lock presses.
Also, it's not that distributions implement the involvement in the layout;
they, at most, enable the option to use the LED indicator. The involvement in
the layout is an xkb thing. Now, it's true that, theoretically, a distribution
could ship a modified version of xkb or modified layout data for xkb, but I
think this doesn't happen except in esoteric cases.
> There would be no single
> way for LibreOffice to know if that is caused by some layout-controlling
> software, or because of user pressed the button.
Well, yes and no. LO might not know what physically happened to trigger key
press and key release event; or it might not get informed about these events at
all. But this is not a problem with the distinction between the keypress and
the LED status. If it doesn't know "for sure" (up to strange hacks which wire
keys differently in xkb) about a Scroll Lock key press, it shouldn't assume it
happened just because it notices the LED coming on.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
