Closed sl-service-account closed 8 months ago
Nicky Dasmijn commented at 2022-03-06T23:17:32Z
This seems to be a side effect of:
commit 83127d22992e055b40298724d0cac0de108b6116 Author: Mnikolenko ProductEngine mnikolenko@productengine.com Date: Thu Jan 21 19:02:18 2021 +0200
SL-14720 FIXED Undo function is incorrect on German Mac keyboard
reverting this commit restores the old behavior.
Katarin Kiergarten commented at 2022-03-07T01:35:41Z, updated at 2022-03-07T01:36:45Z
I can reproduce this. The version which the viewer updated itself to before I tested this just now is below. (It does not match the version reported as current for this issue, though I see that the release notes link matches.)
Second Life Release 6.5.3.568554 (64bit) Release Notes
You are at [redacted] Second Life Server 2022-02-10.568388 Release Notes
CPU: Apple M1 (2400 MHz) Memory: 8192 MB OS Version: Mac OS X 10.16.0 Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Oct 12 18:33:38 PDT 2021; root:xnu-7195.141.8~1/RELEASE_ARM64_T8101 x86_64 Graphics Card Vendor: Apple Graphics Card: Apple M1
OpenGL Version: 2.1 Metal - 71.7.1
Window size: 2162x996 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 200m Bandwidth: 3000kbit/s LOD factor: 1.625 Render quality: 3 Advanced Lighting Model: Enabled Texture memory: 512MB Disk cache: Max size 1996.0 MB (100.3% used) HiDPI display mode: 0
J2C Decoder Version: KDU v7.10.4 Audio Driver Version: FMOD Studio 2.02.03 Dullahan: 1.12.3.202111032211 CEF: 91.1.21+g9dd45fe+chromium-91.0.4472.114 Chromium: 91.0.4472.114 LibVLC Version: 3.0.16 Voice Server Version: Not Connected Packets Lost: 91/4189 (2.2%) March 06 2022 17:34:13
Dan Linden commented at 2022-03-07T19:38:55Z
Thank you for the report, Anastasia!
Anastasia Horngold commented at 2022-07-30T22:29:47Z
Any progress on this one? It continues to affect all us Mac users.
Dan Linden commented at 2022-08-03T02:29:12Z
This is marked as fixed in Maint Izarra, https://releasenotes.secondlife.com/viewer/6.6.2.573282.html
Let us know if it's still broken there, and we'll reopen this bug.
Whirly Fizzle commented at 2022-09-15T22:18:26Z
I have reopened this issue. TatianaRuiz reports that this bug still reproduces on the current Mac build of the default LL Viewer which should contain the Izarra fix. Her language is set to Portugese This is the screenshot she sent me: https://gyazo.com/5665b06628543cbe34efe6c75fcf28b6
I will get her to comment here now this issue is reopened.
Gwyneth Llewelyn commented at 2022-09-16T00:52:38Z
Thanks @Whirly Fizzle for reopening the issue, since, unfortunately, it continues to plague us native non-English-speakers on a Mac.
To be more precise, the issue is not exactly if Option-E produces something or not. That is certainly the case, and it works well; in other words, if you press a key simultaneously with a modifier key (shift, alt, ctrl, fn, option, cmd...), then the expected key will, indeed, be produced.
The problem appears when you have to press a sequence of keys (usually two, on accented Western European languages, which are basically all except English and possibly Dutch...). The accent comes from a different key (traditionally, on the right side of the keyboard, because that's where old mechanical keyboards used to place them...), which is pressed first (usually briefly showing what accent was typed with an underscore or similar mark to show that the input is waiting), followed by another key. So, instead of pressing two or more keys {}simultaneously{}, when typing accented characters, the convention (again, coming from mechanical typewriters...) is to type a {}sequence{}, usually of just two keys (note: Asian and/or Arab keyboards may have more complex rules).
To give an example, in German, if you wish to get the vowels with a trema ({}Umlaut{} in German), you press the key for the trema first, producing a {}¨
{}, and then press a vowel, say, {}u
{}, to get the final {}ü
{}. A Portuguese keyboard (which is what I've got as well) will have at least four accents (as well as the trema is actually also included, since the ü
still appears in a handful of words, especially on Brazilian Portuguese); I understand that at least the French and Spanish keyboards have those four additional keys as well (even if each country has them on slightly different places).
Note that before the mentioned revision, accented characters worked flawlessly on any part of the viewer that accepted Unicode characters — text chat (including IMs, group IMs, etc.), notecards, scripts, and on the land and user profiles. Things like object names and descriptions, as well as inventory entries, have always been ASCII and not Unicode, so there was no way to add accented characters there.
But, as said, the issue is not about supporting Unicode characters typed via the keyboard — those that can be produced via modifier keys pressed simultaneously with a key will work. Similarly, you can copy & paste Unicode characters (including all possible accented characters!) from outside the viewer into those areas accepting Unicode, and that will work as well. Loading/saving scripts to an external editor will also allow Unicode characters, produced externally, to be saved back into the script via the SL Viewer. All that works well, and, to the best of my knowledge, never stopped working.
It's just combination of keys that is broken. Note that the SL Viewer did not always support such combinations. It is present on the Windows version since time immemorial (or rather when Unicode replaced ASCII on notecards, Display Names, etc.), but on the Mac, I'd say it's something that appeared a little over a decade ago, and which worked well over the many upgrades...
As reported elsewhere, interestingly, the Firestorm Viewer did also incorporate the 'broken' revision — a few days after it has been released — and therefore also suffers from the same problem. They refer to this issue internally, in the sense that 'it will be fixed when Linden Lab fixes their own Viewer'.
Second Life Release 6.6.4.575022 (64bit) Release Notes
CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (2800 MHz) Memory: 16384 MB OS Version: Mac OS X 10.16.0 Darwin 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 29 04:31:06 PDT 2022; root:xnu-7195.141.39~2/RELEASE_X86_64 x86_64 Graphics Card Vendor: NVIDIA Corporation Graphics Card: NVIDIA GeForce GT 750M OpenGL Engine
OpenGL Version: 2.1 NVIDIA-16.0.13
Window size: 2806x1614 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 64m Bandwidth: 10000kbit/s LOD factor: 0.5 Render quality: 0 Advanced Lighting Model: Disabled Texture memory: 512MB Disk cache: Max size 1996.0 MB (23.0% used) HiDPI display mode: 1
J2C Decoder Version: KDU v7.10.4 Audio Driver Version: FMOD Studio 2.02.06 Dullahan: 1.12.4.202209142017 CEF: 91.1.21+g9dd45fe+chromium-91.0.4472.114 Chromium: 91.0.4472.114 LibVLC Version: 3.0.16 Voice Server Version: Not Connected September 15 2022 15:44:51
mariaa Barbosa commented at 2022-09-16T16:29:58Z, updated at 2022-09-16T17:03:27Z
Hello,
Few things to add after the excellent post from Gwyneth. I'd like to remember that this issue affects all Mac users with almost all western languages but english. I'm spanish, we use accents and there are words with different meanings with/without accent.
These issue lasts for the last 4-6 months, three Firestorm releases ago.
For instance, "sólo" (only) or "solo" (alone), "ésta" (pronoun) or "esta" (adjective) or "está" (he/she/it is) or "inglés" (native from England) , "ingles" (crotches)
Thank you :)
JIRAUSER342662 commented at 2022-09-16T19:58:37Z
Exactly, I also agree with Mariaa Barbosa.
And as I said to Whirly Fizzle, also in LL viewer I still don't have graphic accents in Portuguese (Brazil).
The accents acute (´), grave (), circumflex (^), backtick (
), umlaut (ü), quotation marks ("), cedilla (ç).
All are substantially needed in our language and others as I am reading here.
Please fix this, thank you!
AndreyK ProductEngine commented at 2022-12-13T11:35:29Z
Is this still an issue? I press option-e then a and get á in viewer's chat.
Whirly Fizzle commented at 2022-12-13T18:20:41Z
This bug still reproduces, please see BUG-233073
Whirly Fizzle commented at 2022-12-13T18:22:14Z
You should all be able to comment on this issue now :)
mariaa Barbosa commented at 2022-12-13T18:33:11Z
After being the thread reopened for comments, I'm able to answer to AndeyK Productions.
(Thanks!)
The issue is about the way that western languages (all but english) users write on the keyboard. We press the accent (diacritical sign) key and immediately the letter we want to appear accented.
This has been working for years on Mac systems and suddenly stopped working. Please read the Gwyneth comment, which is a fantastic reporting of what's happening and why.
This issue is still happening and at the time I'm writing I'm not able to write accented letters.
Please keep in mind the big importance of that for western languages other than english, because there are many words with different meanings with/without the accents.
JIRAUSER342662 commented at 2022-12-13T20:27:53Z
yes it still happens nothing has been resolved
AndreyK ProductEngine commented at 2022-12-14T13:26:58Z, updated at 2022-12-14T17:33:06Z
Ok thank you, I can print things like ü and ñ that require option key without issues in viewer 6.6.8.576863 on MacOS's German 'input'. But now I see that í doesn't work in viewer.
mariaa Barbosa commented at 2022-12-14T18:53:24Z, updated at 2022-12-14T18:57:35Z
Again, that's not an issue about the Mac "option key". The issue is about writing diacritical accents in the way we use the keyboard in every single application. We press the diacritical sign key (`, ´. ¨, ^) immediately followed by the vowel we want to be accented (á, à, â, ä, etc). We press the sign key and immediately the vowel, no "option key" is needed. That's not working on SL chat window nor general chat input textbox (in fact anywhere we can type in).
Please, read the comment from Gwyneth in this very thread, it fully explains the problem and, I guess, some of the causes.
These are the keys that don't work. For example, to write "ò" first we press the "`"key and then "o"
AndreyK ProductEngine commented at 2022-12-14T21:22:31Z, updated at 2022-12-15T22:23:38Z
The problem is that I can input a sequence like ¨ then u to get ü on German layout, and it works. Gwyneth's explanation specifically covers ü. I assume people who looked into this before me just couldn't reproduce the issue as well. But I managed to repro with other symbols (I assume it's the same issue).
Please check, hopefully this fixes it: https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/108698/946651/Second_Life_Test_6_6_9_577303_x86_64.dmg
Gwyneth Llewelyn commented at 2022-12-16T01:14:37Z
@AndreyK ProductEngine success!
Whatever magic you have worked into 6.6.9.577303 has fixed things for me :) Thank you so much!
You can scroll down to the bit I marked on the snapshot below, showing the accents as I've typed them — and I did type them out as a sequence of accent + character, not merely done a copy & paste :D
I really hope that others have the same experience, and that this Jira report can be successfully closed! What a nice Christmas present ;)
![Accents work again.png](Accents work again.png)
P. S. I deliberately left the Help > About Second Life
dialogue box opened, in case you wish to confirm things such as the hardware type, graphics card, macOS version, drivers, software components, etc. — so that at least you guys know that there is a specific combination of all of those things that does work.
AndreyK ProductEngine commented at 2022-12-16T14:30:17Z, updated at 2022-12-16T14:33:57Z
Thanks for the confirmation, fix will go into DRTVWR-570, but I doubt it will get deployed this year.
mariaa Barbosa commented at 2022-12-16T16:56:40Z
Thank you, AndreyK!
The beta version you offer worked also for me, typing with a spanish keyboard. I hope this fix will be included in your next public release.
Now the problem I'm facing is with Firestorm, where the problem persists. As far as I understand Firestorm is built around the LL APIs. So... that means that they won't be able to fix it until LL publishes the new version?
I know this is now a Firestorm issue, but I'd appreciate you explain it so I could get a time expectation for this being solved.
AndreyK ProductEngine commented at 2022-12-16T17:17:49Z
So... that means that they won't be able to fix it until LL publishes the new version? As far as I know, Firestorm developers often merge fixes long before LL releases them. There is a chance Firestorm will pick this up early.
I hope this fix will be included in your next public release. There likely will be at least one other viewer release before this fix goes out (release process might take a while). Fix is likely to be released as SL-18384 in release notes.
mariaa Barbosa commented at 2022-12-16T17:22:57Z
Thank you very much, Andrey K for replying so quickly.
Dan Linden commented at 2023-01-13T19:16:21Z
This fix is in the Maint-Q RC viewer which is available on https://releasenotes.secondlife.com/viewer/6.6.9.577418.html
Gwyneth Llewelyn commented at 2023-01-27T17:06:32Z
Just to report (as shown on the picture I've posted earlier) that using diacritocs/accents now work perfectly on all versions of the SL Viewer I tested, as well as on Firestorm — so it seems that this correction (actually, a reversion) has been picked up by all current projects relying on the 'main' codebase.
Thanks for looking into this, and I'm sure this ticket can now be closed and marked 'fixed' :)
What just happened?
On the current SL viewer, I tried to type the usual key combinations for accented letters, and the accents were not produced. For instance, option-e followed by a letter should produce a letter like this: é or á. Instead, just e or a are produced.
What were you doing when it happened?
Typing accented letters in a chat field.
What were you expecting to happen instead?
I was expecting to be able to type accented letters as usual.
Other information
This worked on previous viewer versions, but I don't know when the change occurred.
[It is likely that the fix for BUG-230013 caused this regression. -Dan Linden]
Attachments
Links
Related
Duplicates
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-231889 | | Summary | [MAINT G+H] Key combinations for diacritical marks are not working | | Type | Bug | | Priority | Unset | | Status | Closed | | Resolution | Cannot Reproduce | | Reporter | Anastasia Horngold (anastasia.horngold) | | Created at | 2022-03-06T20:35:22Z | | Updated at | 2023-01-27T19:57:57Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2022-03-06T17:17:32.176-0600', "Is there anything you'd like to add?": "This worked on previous viewer versions, but I don't know when the change occurred.\r\n\r\n", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'On the current SL viewer, I tried to type the usual key combinations for accented letters, and the accents were not produced.\r\nFor instance, option-e followed by a letter should produce a letter like this: é or á. Instead, just e or a are produced. ', 'What were you doing when it happened?': 'Typing accented letters in a chat field.', 'What were you expecting to happen instead?': 'I was expecting to be able to type accented letters as usual.', 'Where': 'In any chat field.', } ```