Проблемы с исправлением неправильной раскладки клавиатуры в 6.0 под линукс

[McAaron]

Перезапустил xneur, чтобы сыпал log в терминал.

В окошке, где я сейчас набираю текст,  переключение приводит к выдаче
[DBG] 20:06:27 Получен выделенный текст 'QWERTY'
[DBG] 20:06:27 Обработка строки 'QWERTY'
...
[DBG] 20:06:49 Получен выделенный текст 'ЙЦУКЕН'
[DBG] 20:06:49 Обработка строки 'QWERTY'

То же самое выходит в 5.4.5. В 6.0.2 выход следующий

[DBG] 20:10:18 Получен выделенный текст 'QWERTY'
[DBG] 20:10:18 Обработка строки 'QWERTY'
...
[DBG] 20:10:20 Получен выделенный текст '|ЙЦУКЕ'
[DBG] 20:10:20 Обработка строки '|QWERT'
...
[DBG] 20:10:24 Получен выделенный текст '|/QWER'
[DBG] 20:10:24 Обработка строки '|/QWER'
...
[DBG] 20:10:25 Получен выделенный текст '|/.ЙЦУ'
[DBG] 20:10:25 Обработка строки '|/.QWE'
...
[DBG] 20:10:26 Получен выделенный текст '|/.юQW'
[DBG] 20:10:26 Обработка строки '|/..QW'

[tagezi]

Перезапустил xneur, чтобы сыпал log в терминал.

По этому логу видно только то, что xneur не правильно обрабатывает строку. То есть, он её правильно копирует из текста, и где-то во внутренностях у себя, делает её не правильной. То есть, проблема не в ЛО.

Чтобы просить команду QA и разработчиков ЛО это рассмотреть, нужно делать Бибисект (статья по русски).

[McAaron]

Установил версию 5.3.7 из дистрибутива FC26.
Version: 5.3.7.2.0+
Build ID: 5.3.7.2-8.fc26
CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk3; Layout Engine: new;
Locale: ru-RU (ru_RU.UTF-8); Calc: single

У нее такие же проблемы, как у 6.0.2 -- текст портится и портится совершенно так же.
К сожалению, у меня нет ванильной версии 5.3.7, а на сайте либреоффиса не нашел.
Итак, в результате экспериментов с теми офисами, что у меня есть, имеем:
5.3.3 ванильная -- полет нормальный
5.3.6 ванильная -- полет нормальный
5.3.7 федорина -- плохо
5.4.1 ванильная -- полет нормальный
5.4.2 ванильная -- полет нормальный
5.4.5 ванильная -- полет нормальный
6.0.1 ванильная -- плохо
6.0.2 ванильная -- плохо

Похоже, что в 6-й либреоффис федорин коммит приняли:-)

[McAaron]

Перезапустил xneur, чтобы сыпал log в терминал.

По этому логу видно только то, что xneur не правильно обрабатывает строку. То есть, он её правильно копирует из текста, и где-то во внутренностях у себя, делает её не правильной. То есть, проблема не в ЛО.

Из логов видно, что xneur получает и отдает все правильно. Если бы это было не так, то портилось бы везде. Но портится только в либреоффисе и только в некоторых версиях, например, в федориной 5.3.7 и ванильных, начиная с 6.0. Я с 4-й версии сижу на ванильном офисе и во всех версиях с xneur все было нормально вплоть до 6.0-й.
Так что вот так.
...
Кстати, проверил в импрессе 6.0.2  -- xneur все отлично корректирует.
Calc 6.0.2 -- тоже ...
Writer 6.0.2 в полях ввода различных диалогов и панелей -- тоже все отлично "дружит" с xneur, а вот на странице и в колонтитулах увы. Странный нотауэрбаг, не находите?

[tagezi]

Перезапустил xneur, чтобы сыпал log в терминал.

По этому логу видно только то, что xneur не правильно обрабатывает строку. То есть, он её правильно копирует из текста, и где-то во внутренностях у себя, делает её не правильной. То есть, проблема не в ЛО.

Из логов видно, что xneur получает и отдает все правильно. Если бы это было не так, то портилось бы везде. Но портится только в либреоффисе и только в некоторых версиях, например, в федориной 5.3.7 и ванильных, начиная с 6.0. Я с 4-й версии сижу на ванильном офисе и во всех версиях с xneur все было нормально вплоть до 6.0-й.
Так что вот так.
...
Кстати, проверил в импрессе 6.0.2  -- xneur все отлично корректирует.

нужно делать Бибисект (статья по русски).

[McAaron]

... нужно делать Бибисект (статья по русски).

Для какой версии? У ванильных 5.4 все в порядке, у 6.0 -- проблемы. У федориной 5.3.7 -- проблемы.

[kompilainenn]

для 6.0

[McAaron]

для 6.0

Сделал
$ git clone git://gerrit.libreoffice.org/bibisect-linux-64-6.0
Клонирование в «bibisect-linux-64-6.0»...
remote: Counting objects: 72435, done.
...
Завтра посмотрим...

[McAaron]

$ git bisect bad
ec8c939006ea8e236c333ec3fe20c2eeff4487e9 is the first bad commit
commit ec8c939006ea8e236c333ec3fe20c2eeff4487e9
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Fri Sep 8 11:32:30 2017 +0200

   source sha:9ca0f91b02822a5c0b28a651f82821cd11d9f6ed
   
   source sha:9ca0f91b02822a5c0b28a651f82821cd11d9f6ed

:040000 040000 29c55770875ca25abd8f14e93653bb528185d14f 339bdbe3a2b0fdc4427d675a861898b397e21647 M   instdir

$ git bisect log
# bad: [fd1c16d808bbd9d21d7731966489e4452e785a69] source sha:a1b3ae95e35fe0669bcc9df020fa606e6a3cca75
# good: [b9d78ce81dc3481fccb0cb75d76fcb6ac939cbd5] source sha:9feb7f7039a3b59974cbf266922177e961a52dd1
git bisect start 'fd1c16d808bbd9d21d7731966489e4452e785a69' 'oldest'
# good: [71f5bf7091db688cdfd816e6ebf5676b73d4f72a] source sha:2721b5391c692e0068e596a029ea5c40d6e90409
git bisect good 71f5bf7091db688cdfd816e6ebf5676b73d4f72a
# bad: [350091072a544687b5a42ca6ccce8832eae51c7d] source sha:6f065a7aff86528e5c780dccb50aeaecdb7896fb
git bisect bad 350091072a544687b5a42ca6ccce8832eae51c7d
# bad: [080df8b09c038b2a366a5497d3f2cd051ea179c2] source sha:9e81e845d8299f117e96c30e8b40fcf602e9ca2c
git bisect bad 080df8b09c038b2a366a5497d3f2cd051ea179c2
# bad: [5451e1d97f6658e465c02b93b2234985c86f2c68] source sha:71d48c3d5c81f9637705de2212ef860bf8a9b4fd
git bisect bad 5451e1d97f6658e465c02b93b2234985c86f2c68
# bad: [290bdd673d9e68e69ebf868e8eadcf1695197efd] source sha:4f2a06379dde3839a71a52e81c2ca09aaa9a41c9
git bisect bad 290bdd673d9e68e69ebf868e8eadcf1695197efd
# bad: [2359cbfb11a1d25dcbd161f96a6c331c04f029a0] source sha:bb2258f7e4bcf078810cf1e40fdec2f17576c3b2
git bisect bad 2359cbfb11a1d25dcbd161f96a6c331c04f029a0
# good: [c11c24165b80b4b54ca4dd96cd31989d48481b37] source sha:fe4c6063ec493c986f810ba676e2b12fe7dab7a9
git bisect good c11c24165b80b4b54ca4dd96cd31989d48481b37
# good: [3b1772fe1f716f3db5f98bfd83a45d8f403f0898] source sha:41a85500a70533e1c9791c3a4f8b6c24f2143682
git bisect good 3b1772fe1f716f3db5f98bfd83a45d8f403f0898
# good: [d4bfdb5c68dbb3b9b61e3bb38b3ed9749ecd4300] source sha:01cc6e5107c706760939c2331ca57247bd02cb77
git bisect good d4bfdb5c68dbb3b9b61e3bb38b3ed9749ecd4300
# good: [941f8524dc9d2eee7a770c50a057e1443298a36a] source sha:554a79d793ee9546f71802643b79001749c3c695
git bisect good 941f8524dc9d2eee7a770c50a057e1443298a36a
# good: [94ac457e7677fac3267f146c70b42870a0b9db99] source sha:8e8c789742874ac823e68f6154050c64b6fc5b85
git bisect good 94ac457e7677fac3267f146c70b42870a0b9db99
# good: [5f42e5b679d2b764adf02706a5590a3984d3e8c4] source sha:7b9cb381702a408c3cf54bfaa1f8a7b2c30882a7
git bisect good 5f42e5b679d2b764adf02706a5590a3984d3e8c4
# bad: [3fcdbcb086e32ab60e128a0b099a9390bcdaf30e] source sha:c799497959f82c84ddaf032b096d1a3f8d6e2bcd
git bisect bad 3fcdbcb086e32ab60e128a0b099a9390bcdaf30e
# bad: [ec8c939006ea8e236c333ec3fe20c2eeff4487e9] source sha:9ca0f91b02822a5c0b28a651f82821cd11d9f6ed
git bisect bad ec8c939006ea8e236c333ec3fe20c2eeff4487e9
# first bad commit: [ec8c939006ea8e236c333ec3fe20c2eeff4487e9] source sha:9ca0f91b02822a5c0b28a651f82821cd11d9f6ed
user@host bibisect-linux-64-6.0]$


Запускал в --safe-mode, поскольку включенный из коробки OpenGL/CL валит программу.
После появления окна выбирал вордпроцессор.
В документе набирал QWERTY<Enter>
Выделял QWERTY слева направо клавиатурой и нажимал Shift + PauseBreak
Если раскладка переключалась, считал случай good, если нет, то bad, не обращая внимания на эффект "залипания" после переключения один или более раз.

Залипание в случаях "good".
В релизах 5.4.x выделенный участок текста перекодируется сколько угодно раз из кириллицы в латиницу и обратно. В коммитах из репозитория это не так.
Бывают ситуации, когда выделенный участок текста перекодируется фиксированное количество раз и на этом прекращает, словно xneur не работает совсем. Если выделение сбросить и выделить опять, то текст перекодируется опять фиксированное количество раз. Каждый коммит ведет себя по разному -- один может при первом выделении один раз переключиться и залипнуть, следующее выделение переключится два или три раза, а то и шесть. Другой коммит ведет себя так же, только в последовательности выделений до залипания будет другое количество переключений. А вот все случаи "bad" переключают пока содержимое не заменится на знаки препинания, но при этом ничего не залипает и не тормозит.

[mikekaganski]

https://cgit.freedesktop.org/libreoffice/core/commit/?id=9ca0f91b02822a5c0b28a651f82821cd11d9f6ed

Ощущение такое, что xneur "не дожидается", когда событие копирования будет обработано.

Нужно писать баг... но может быть, не только нам, но и в xneur

[McAaron]

https://cgit.freedesktop.org/libreoffice/core/commit/?id=9ca0f91b02822a5c0b28a651f82821cd11d9f6ed

Ощущение такое, что xneur "не дожидается", когда событие копирования будет обработано.

5.4.x и более ранние релизы работают отлично. Проблема появилась в 6.0.

Странно то, что bibisect-linux-64-6.0 стартует с версии 5.4.0.0.alpha1+, в которой все переключается честно, но недолго -- первое выделение, например, 1 раз, второе -- 2, третье -- 6, и далее 2, 3, 3. При этом в разных запусках по разному при одних и тех же действиях пользователя.
В релизе 5.4.5.1 все переключается туда-сюда честно и бесконечно долго.
В репозитории bibisect-linux-64-6.0 нет версии 5.4.5.1, хотя она вышла в этом году, а 5.4.0.0.alpha1+ в прошлом.  Интересно, в каком это месте ветка из bibisect-linux-64-6.0 подцепила залипание?

[mikekaganski]

Ощущение, что меня не слышат. Ну что ж...

[McAaron]

Ощущение, что меня не слышат. Ну что ж...

Что им писать? Надо ли им прикладывать лог?

[mikekaganski]

Описание проблемы (что наблюдается, что ожидается), когда появилось, подробно версии и ОС, и лог - обязательно.

[tagezi]

https://cgit.freedesktop.org/libreoffice/core/commit/?id=9ca0f91b02822a5c0b28a651f82821cd11d9f6ed

Ощущение такое, что xneur "не дожидается", когда событие копирования будет обработано.

5.4.x и более ранние релизы работают отлично. Проблема появилась в 6.0.

Давайте на пальцах.
Ошибка появляется тогда, когда в LO выставляют "правильный" приоритет пользовательских процессов. Пользовательские процессы ниже по приоритету чем системные - это правильно.
Что это значит?
Возможно xneur не задумывается о приоритете процессов и не обрабатывает ситуацию корректно, если система, например, приостановила выполнение пользовательского процесса.
Не уверен, по тому что "у нас есть", мой опыт не позволяет сделать точные выводы.

А теперь следующий шаг - пишите багрепорт.
И я бы это сделал сначала в X Neural Switcher, чтобы разработчики посмотрели.
Если будите писать багрепорт в багзилу ЛО, приложите обязательно результат бибисект.
Во всяком случае, разработчикам будет проще общаться.