Bug 3114

ЗЫ Используется KDE. Другие DE еще не пробовал.

Хочу поменять описание ошибки.
Как я понимаю, проблем в том, что под виндой при вызове справочника товаров(например) буфер клавиатуры не сбрасывается, т.е. появляется окно справочника и все нажатые до этого клавиши обрабатываются. Под линуксом клавиши начинают обрабатываться только с момента появления окна со справочником товаров.

PS Сейчас в качестве терминального сервера под линуксом используется Core2QUAD 9400/2048 Gb. Проблема наблюдается и в терминальном режиме, и в локальном. Пробовал за это время: KDE3.5, GNOME, E17, KDE4.1.3 xfce, blacbox. Кажись ни в чем не ошибся;).
Преимущественно использую KDE 3.5 и KDE 4.1.3.

Думаю, что проблему можно решить если ускорить процесс создания окон.

Задержки, которые сейчас наблюдаются, связаны с более долгой отрисовкой иконок в wine по сравнению с windows. Это видно по мигающему заголовку окон.

Скорее всего, проблема не столько в буфере клавиатуры, сколько в посылке сооющения WM_KEYDOWN еще не созданному окну.

(In reply to comment #4)
> Скорее всего, проблема не столько в буфере
> клавиатуры, сколько в посылке сооющения
> WM_KEYDOWN еще не созданному окну.
Понятно.
А как-то можно это обойти, вставив некоторую паузу (например, что-то около 1/10 секунды)? Чтобы в итоге клавиши обрабатывались в уже появившемся окне.

Еще момент: такая проблема наблюдается не только при появлении окна, но и при начале редактирования строки в табличной части документа, например. Т.е. я думал временно обойти, используя поле типа не "Справочник.Товары", а "Строка". В итоге проблема аналогична: при нажатии ins - клавиши, нажатые до появления новой строки (и начала ее редактирования?) также пропадают.

ЗЫ Спасибо за оперативность. Буду ждать решение. Пока это основная проблема. Странно, что ее раньше не было (если я не пропустил).

Проблема, думаю, была всегда.
Постараемся решить её. Одной из идей было переключать фокус ввода до начала перерисовки окна.
В крайнем случае можно не вынимать сообщения от клавиатуры до окончания перерисовки.

(In reply to comment #6)
> Проблема, думаю, была всегда.
Виноват. Не так выразился - не было (не нашел) в багах.

Выложил два патча.

Первый откатывает патч на отступ в меню для 1с7. Эта проблема должна решиться, если иконки будут отрисовываться быстрее.

Второй - хак, запрещающий масштабировать иконки для 1с7.

Дело в том, что 1с сначала масштабирует иконки 16x16 в 32x32, а потом перед каждой отрисовкой обратно из 32x32 в 16x16. Операция масштабирования долгая, поэтому и вывод иконок так тормозит. Собственно, из-за этих иконок тормозит и создание окна, поскольку пока Non Client область не обновится, CreateWindow управленияне вернет.

У этого решения возможны негативные последствия, но если это будут незначительные визуальные недачеты, думаю, ускорение 1с того стоит.

(In reply to comment #8)
> Выложил два патча.
> 
> Первый откатывает патч на отступ в меню для
> 1с7. Эта проблема должна решиться, если
> иконки будут отрисовываться быстрее.
> 
> Второй - хак, запрещающий масштабировать
> иконки для 1с7.
Несколько вопросов:
1. Как их скачать? Не нашел. Или это для внутреннего использования?
1а. Проблема в открытой части wine@etersoft? Т.е. можно ли компилировать самому?
2. Когда можно будет погонять вариант с патчем?
3. А по "буферу клавиатуры" ( http://bugs.etersoft.ru/show_bug.cgi?id=3114#c6 ) пока еще никаких сдвигов?

Спасибо.

(In reply to comment #9)

> 1. Как их скачать? Не нашел. Или это для
> внутреннего использования?
> 1а. Проблема в открытой части wine@etersoft? Т.е.
> можно ли компилировать самому?
> 2. Когда можно будет погонять вариант с
> патчем?

Вам надо подождать выхода версии 1.0.10 или обновления для 1.0.9, если оно будет.

> 3. А по "буферу клавиатуры" (
> http://bugs.etersoft.ru/show_bug.cgi?id=3114#c6 ) пока еще
> никаких сдвигов?

Нет. Вероятнее всего, проблему удастся решить этими патчами.

Изменил на Fixed. 

Если проблема должным образом не решится текущим патчем, надо переоткрыть.

Сборка 40/17
Заявленной проблемы нет

Извиняюсь за задержку (почти месяц был в командировке, потом решал накопившуюся текучку).
Все-таки проблема до конца не решена (1.0.9 41/17, локальная версия, т.к. на сетевую закончилось время тестирования). Отображение стало быстрее, но не достаточно. Возможно это связано с размером справочника товаров - у нас порядка 12 000 - 13 000 позиций сейчас. Ведь время уходит не только на отображение, но и на чтение базы.
Думаю, что все-таки нужно копать в сторону буфера клавиатуры.

PS Лично мне это и не заметно, но фактуровщик у нас с этим сталкивается. :(

Выложил патч.

На самом деле, как выяснилось, буфера клавиатуры в wine нет. Все сообщения WM_KEYDOWN попадают в очередь сообщений, из которой потом извлекаются и обрабатываются через hook'и.

В данном случае проблема была в том, что пока создается новое окно фокус теряется, т.е. новое окно его еще не получило, а предыдущее уже потеряло. Из-за этого вместо WM_KEYDOWN сообщений генерировались WM_SYSKEYDOWN. Дальше для их обработки вызывался hook и их обрабатывало активное окно, т.е. предыдущее.

Решение заключается в добавления буфера, в который заносятся все клавиши нажатые, пока нет окна с фокусом. Дело в том, что эти сообщения в любом случае должны быть извлечены из очереди сообщений, иначе программа не сможет работать дальше. После этого как только приходит сообщение WM_TIMER - этот буфер извлекается в окно, имеющее фокус.

(In reply to comment #14)
> Выложил патч.
> 
> На самом деле, как выяснилось, буфера
> клавиатуры в wine нет. Все сообщения WM_KEYDOWN
> попадают в очередь сообщений, из которой
> потом извлекаются и обрабатываются через
> hook'и.

....
> 

Вообще данную функциональность должен обеспечивать диспетчер очереди сообщений. Насколько я помню алгоритм такой (помню смутно, надо проверять):
- Перед созданием окна, создать и зарегистрировать диспетчер и очередь сообщений
- Помещать сообщения в очередь
- После создания окна соединить диспетчер и окно
- Начинать извлекать сообщения из очереди.

Выложил [TRY 2].

Скорее всего, это решение более корректно. Вместо добавления буфера, теперь игнорируются сообщения WM_SYSKEYDOWN, в случае, когда окна с фокусом ввода нет. Т.е. вместо того чтобы это сообщение обрабатывало активное окно (так должно происходить согласно MSDN), мы ждем, когда появится окно с фокусом ввода.

(In reply to comment #16)
> Выложил [TRY 2].
> 
> Скорее всего, это решение более корректно.
> Вместо добавления буфера, теперь
> игнорируются сообщения WM_SYSKEYDOWN, в случае,
> когда окна с фокусом ввода нет. Т.е. вместо
> того чтобы это сообщение обрабатывало
> активное окно (так должно происходить
> согласно MSDN), мы ждем, когда появится окно с
> фокусом ввода.
> 

Данное исправление вызывает вот такой баг: http://bugs.etersoft.ru/show_bug.cgi?id=3827

Текущее решение приводит к баге 3827, поэтому переоткрываю.

Была идея ввести флаг определяющий, что окно еще не созданно и не готово принимать сообщения от клавиатуры. Идея оказалась не очень удачной - сначала создается окно, затем приходят сообщения WM_KEYDOWN, затем создается нужный контрол. Определить закончило ли приложение создавать контролы в окне достаточно сложно.

(In reply to comment #19)
> Была идея ввести флаг определяющий, что
> окно еще не созданно и не готово принимать
> сообщения от клавиатуры. 

С виду всё корректно...

> место добавления буфера, теперь
> игнорируются сообщения WM_SYSKEYDOWN, в случае,
> когда окна с фокусом ввода нет.
А как узнать что существует? Каково поведение этих "псевдоменю", может возможны хаки для подобных случаев? Правда, ещё неизвестно, помог ли этот патч автору бага...

Проблема решена. См. комментарий #2 на багу #3827.

Откатил патч:

commit f6623544a352687d5a724d61f9663706f3236184
Author: Ilya Shpigor <shpigor@etersoft.ru>
Date:   Sun Jan 11 16:14:09 2009 +0300

    user32/winex11.drv: Skip the icons stretching for 1c7 (eterbug #3114)

Перед патчем изменились имена переменных. Придётся патч переделать.

Также откатил последующий патч:

commit 5208c1aeeb56caa17f62971bc4c15e2cbb96cfff
Author: Ilya Shpigor <shpigor@etersoft.ru>
Date:   Thu Feb 26 10:58:11 2009 +0300

    user32: Add the correct redrawing for minimized windows (eterbug #1011)

Надо его не забыть потом приложить.

Изменения касаются только репозитория eterhack.

(В ответ на comment #22)
> Откатил патч:
> 
> commit f6623544a352687d5a724d61f9663706f3236184
> Author: Ilya Shpigor <shpigor@etersoft.ru>
> Date:   Sun Jan 11 16:14:09 2009 +0300
> 
>     user32/winex11.drv: Skip the icons stretching for 1c7 (eterbug #3114)

Не уверен, что icons stretching влияет на буфер клавиатуры. Возможно, это опечатка Ильи в заголовке коммита.

(В ответ на comment #23)
> (В ответ на comment #22)
> > Откатил патч:
> > 
> > commit f6623544a352687d5a724d61f9663706f3236184
> > Author: Ilya Shpigor <shpigor@etersoft.ru>
> > Date:   Sun Jan 11 16:14:09 2009 +0300
> > 
> >     user32/winex11.drv: Skip the icons stretching for 1c7 (eterbug #3114)
> 
> Не уверен, что icons stretching влияет на буфер клавиатуры. Возможно, это
> опечатка Ильи в заголовке коммита.

Так оказалось что я отвечал в эту багу :)

Посмотри комментарий номер 8 от Ильи, по-моему он тут как раз про иконки и говорит в нём, а так же указывает патч об этом...

(В ответ на comment #24)
> Посмотри комментарий номер 8 от Ильи, по-моему он тут как раз про иконки и
> говорит в нём, а так же указывает патч об этом...

Да, спасибо. Это именно про него.

Но winex11 в текущем вайне настолько изменён, что я не уверен, что патч просто так может быть переделан и приложен. Создал другую багу по вопросу иконок, чтобы не забыть о том, что у нас было такое решение.

Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.