unixforum.org

Добавлено: **15.04.2009 09:31**

BDenis писал(а): ↑
15.04.2009 07:57
dimbor писал(а): ↑
11.04.2009 19:01
Отсутствия WM_STATE у окна не проверяется, хотя get_window_wm_state() в том-же файле имеется.

Я конечно может чего не прокачал, но мне кажется диагноз не верен. Т.е. бага действительно связанна с wm_state, но то, как она связана для меня не очевидно.
В wait_for_withdrawn_state вся катавасия происходит при, не просто наличии wm_state, а когда и до тех пор пока оно равно WithdrawnState:
Код: Выделить всё
while (data->whole_window && ((data->wm_state == WithdrawnState) == !set))
// set =false  в нашем случае
Т.е. проблема, вроде, не в отсутствии wm_state, а в том, что его никто не изменяет при закрытии (и не понятно кто ставит, если это не nx), а это бага уже другого порядка и пока никак не локализована, так что писать про нее бесполезно.
Разубедите? Может не догнал чего?

Противоречие в регистре символов: WM_STATE - свойство окна х-сервера, data->wm_state - член структуры х-клиента.
Можно сразу установить data->wm_state посредством вызова get_window_wm_state() (а оттуда XGetWindowProperty()). Этого при закрытии окна не делается, хотя по коду при отсутствии свойства, data->wm_state в Withdrawn и станет(нет, но можно исправить иначе).
Вместо этого в wait_for_withdrawn_state() (далее XCheckIfEvent) проверяется PropertyNotify. В строгом соответствии букве ICCCM проверяется факт изменения или удаления WM_STATE. Если свойства нет (как правильно замечено, его должен выставлять wm), а удалить отсутствующее нельзя, то и факта нет.

Все правильно, я же писал, что это и есть нюанс, а не бага. Чтобы от него избавиться, надо перед упомянутым циклом установить data->wm_state с помощью get_window_wm_state() и еще проверить data->wm_state на -1, тогда цикл не выполнится ни разу, и задержки не будет.

P.S. Много раз исправлял, но что-то голова плохо соображает после ночи длиною в час. Простите.

Добавлено: **15.04.2009 12:19**

dimbor писал(а): ↑
15.04.2009 09:31
еще проверить data->wm_state на -1, тогда цикл не выполнится ни разу, и задержки не будет.

Так ведь while как раз это и проверяет. Разве не так?
Блягодаря этому: ((data->wm_state == WithdrawnState) == !set) (set=false) при data->wm_state=-1 цикл не выполнится. Или я опять не вкурил?
По поводу get_window_wm_state(), не готов. Пойду маны покурю.

Добавлено: **15.04.2009 12:28**

BDenis писал(а): ↑
15.04.2009 12:19
Блягодаря этому: ((data->wm_state == WithdrawnState) == !set) (set=false) при data->wm_state=-1 цикл не выполнится.

Не-а! Только в этом случае он крутится, пока у него внутри каунт не сломается, а потом - брякнется по таймауту.

set == true, !set == false

Upd: Ошибочка вышла, причем во всем выказывании. Так я исчо не ошибался.

Добавлено: **15.04.2009 12:42**

dimbor писал(а): ↑
15.04.2009 12:28
set == true, !set == false

Да нет же! set == FALSE, !set == TRUE
Вот так вызвывается из unmap_window:
wait_for_withdrawn_state( display, data, FALSE );

Добавлено: **15.04.2009 13:42**

Ну вот! Опять посадили в большую лужу.
И действительно:

0009:trace:event:wait_for_withdrawn_state waiting for window 0x1007e/60002b to become not withdrawn

Эту строчку я только сейчас заметил.

А перевел обсуждаемый кусок кода на пацанский так:
Пока у окна есть что-то за душой и data->wm_state не withdrawn, ждем сообщения о изменении. Дождались - проверяем. Терпение кончилось - ругаемся и выходим.

Получается, из неверных предпосылок сделал рабочий патч. Вот что значит - воинствующий дилетант!

Но, с другой стороны, в ICCCM тоже так написано, как я перевел. Только выражения помягче.

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

Или вайн сам перед этим снимает этот гроханый WM_STATE, который ему клиент теперь ставит. А потом еще и ждет, пока он снимется.
Загадка природы

Добавлено: **15.04.2009 13:56**

Резюмируя: писать winehq не буду, ибо не знаю о чем. Нехай сами разбираются.

Добавлено: **15.04.2009 14:11**

dimbor писал(а): ↑
15.04.2009 12:28
BDenis писал(а): ↑
15.04.2009 12:19
Блягодаря этому: ((data->wm_state == WithdrawnState) == !set) (set=false) при data->wm_state=-1 цикл не выполнится.

Не-а! Только в этом случае он крутится, пока у него внутри каунт не сломается, а потом - брякнется по таймауту.
set == true, !set == false

Вот она - моя ошибка. Ты был прав в этом сообщении. Это я протупил.

Добавлено: **18.04.2009 16:10**

В этом колхозе праздники через день.
Опять качайте.

1) Календарь, калькулятор и прочие извращения помеченных объектов (modeless-windows) сделаны немодальными. Явных отличий от поведения нет кроме: макси/мини-мизация основного окна при их наличии блокированы. Так надо. Move и Size - работают.
Появился нефатальный, но некрасивый глюк. Если при активном modeless открыть модальное окно (предупреждение, "открыть файл", ...), а потом кликнуть по главному окну, перекрываемая им часть модального станет прозрачной. Т.е. рамка и заголовок останутся, а содержимое будет от главного. Это означает, что клиентской винде удалось втолковать, что окно нужно отображать. Но nx-серверная (а то и вайновская требуха) понимать этого не желает. Если долго биться головой о стену, она начинает болеть.
Но оно абсолютно безвредно, и восстанавливается, ели активировать modeless или его самого.

2) Реализован максимизированный запуск программ, вайновских - уж точно. (Upd 20.04.09: А с firefox пока не работает, блин) При закрытии в максимизированном состоянии и последующем запуске на не-большем разрешении экрана, окно откроется максимизированным по настоящему. Только из-за того, что хинты где-то теряются на пути, restore первоначально максимизированных окон будет по центру с половинными размерами.

На этом все хорошие новости заканчиваются.

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

Ну и в дерганиях modeless бессилен по описанным выше причинам. Тяните медленнее. Пока остается только это.

А подайте ка мне еще страшных глюков.

Upd 22.04.09: Убрал, ниже.

Добавлено: **18.04.2009 17:32**

обновил http://updates.etersoft.ru/pub/Etersoft/RX@Etersoft/Windows/

Добавлено: **18.04.2009 18:03**

dimbor писал(а): ↑
18.04.2009 16:10
В этом колхозе праздники через день.
Опять качайте.

Поздравляю с очередной несовместностью от etersoft

На nxwin_3.3.0_2_dimbor_r12.tmp8.rar c wine 1.0.10.18-12 (пре-релиз) календарь и остальные больные окна стали исчезать при потере с них фокуса, после перевода фокуса на другое приложение и возврате к nxclient окна заново появляются, на wine 1.0.10.16-11 все ок

Добавлено: **19.04.2009 02:05**

Djelf писал(а): ↑
18.04.2009 18:03
dimbor писал(а): ↑
18.04.2009 16:10
В этом колхозе праздники через день.
Опять качайте.

Поздравляю с очередной несовместностью от etersoft
На nxwin_3.3.0_2_dimbor_r12.tmp8.rar c wine 1.0.10.18-12 (пре-релиз) календарь и остальные больные окна стали исчезать при потере с них фокуса, после перевода фокуса на другое приложение и возврате к nxclient окна заново появляются, на wine 1.0.10.16-11 все ок

В колхозе опять поминки. Я худею, дорогая редакция! Второй раз те-же грабли! Новую рюшечку приделали, а все старое поломали.
Опять у клиента совместно с сервером башню сносит.

Больное окно никуда не исчезает. Исчезает его содержимое. Если кликнуть на "пустом месте", все опять нарисуется. Виндового суслика не видно, а он никуда не делся. Клиент его честно рисует поверх главного, и сообщения обрабатывает. Только (nx)сервер считает, что на этом месте главное окно поверх вылезло. Соответственно, буфер (nx-овый DIB) заполнен его содержимым. Оно и рисуется в больном.
Это следствие громкой победы Этерсофта, цитирую:

Категория: окна, фокус
* исправлено множество проблем и проведена оптимизация с фокусом,
переключением и сворачиванием окон.

Проведена вся эта неожиданность по фри-десктоповскому букварю. Для больных окон начало пролазить _NET_WM_STATE_ABOVE, а раньше _NET_WM_STATE висело пустое для красоты. Соответственно, старое руление z-порядком окон похерено. А новое NX-у по барабану. Его еще надо учить, причем учитывая, что у всех nxwin-рутлес-окошек под виндой один общий родитель - "десктоп", а все они равноценные братья. И все прочие отношения - вручную. Сплошной инцест.
В момент активации основного окна при существующем modeless теперь надо отдельно просить nx-сервер, чтобы он сделал его Above, но не активировал и фокус ввода не передавал.

Зато к пенсии буду барабанить ICCCM наизусть на языке Шекспира, если этот censored-ский вайн не добьет меня раньше.
Не могу не украсть цитату, которая очень подходит и к вайну, и к NX-у, а также к присутствующим здесь организациям и физ. лицам.

sisop писал(а): ↑
17.04.2009 08:33
Я не говорю, что её нельзя заставить нормально работать. Устройство внутреннее у неё хренпоймическое.

Добавлено: **20.04.2009 12:50**

Начал испытания Centos 5.3
С переключение alt-Shift все работает.

А вот буфер обмена из Linux окна Firefox переносит в кодах символов, вместо русского.
Вот на пример.

\u041a\u043e\u043b\u0443\u043c\u0431\u0438\u044f \u0432\u0432\u0435\u043b\u0430
тест

В linux окно Firefox переносится в другой кодировке, с тильдами и умляутами.

Win клиент пробую 3.3.0-6
freenx-server-0.7.4-eter9centos.i586.rpm
nx-3.3.0-eter8centos.i586.rpm

Вроде бы по ремонту буфера обмена производилась большая работа, что бы научить его русскому языку.

Добавлено: **20.04.2009 13:14**

Venberg писал(а): ↑
20.04.2009 12:50
nx-3.3.0-eter8centos.i586.rpm

Все требуемые патчи по клипборде там уже есть.

Venberg писал(а): ↑
20.04.2009 12:50
Win клиент пробую 3.3.0-6

Вы написали, что пользуете оригинальный клиент от номашин. Там нет русского буфера.
Как насчет поставить сборку отсюда, почитать шапку, почитать хвост темы о последних сборках?

Добавлено: **20.04.2009 14:49**

Вопрос на засыпку: В рутлесе линуксового клиента больные окна ведут себя КАК?

Добавлено: **20.04.2009 19:19**

dimbor писал(а): ↑
20.04.2009 14:49
Вопрос на засыпку: В рутлесе линуксового клиента больные окна ведут себя КАК?

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

Добавлено: **21.04.2009 21:34**

1) Допилено макс. открытие после макс. закрытия ("firefox").
2) Вылечены больные окна нового вайна. nxagent взрывом не задело. Причины болезни описаны выше. Но со своими ветеринарными навыками диагноз ставить не стал. Опять получился "avoid".
Выяснилось, что после процедуры вытаскивания наверх больных при активировании основного от пред-релиза вайна прилетает прямо противоположная команда вытащить наверх основное окно. С какого перепуга - или от недоделанности wm под вин-клиентом, или от того, что вайн положил на совместимость с Х-ами вниз - хз.
По счастью, если по джентльменски игнорировать бредовые restack-requests именно от вайна, то вроде работает.

Только не говорите мне, что в то время пока парился над этой фигней, вайно-писатели реализовали еще какую-нить пакость против терминального запуска под NX.

А в качестве полу-оффтопического брюзжания, сопровождающего выкладывание каждой сборки, скажу следующее:
Развитие ситуации с вайном смутно мне напоминает тенденции развития отеч. ПО под уиндоуз. Напимер - экземпляр BS-Клиента считается нерабочим, если в поставке отсутствует профессор криптографии. А также - обновления чудо-программы Такском случаются через день, при его неизменно-куцых возможностях, зато с необходимыми многочисленными дерганиями мышой для установки этих обновлений. Про совсем не мелкое, но все еще мягкое - вообще либо хорошо, либо ничего.
А не скоро ли сработает аксиома о том, что усложение системы до определенного предела приводит к утрате контроля над ней? Ась?

Upd: Сборка теперь дальше по тексту...

Добавлено: **21.04.2009 22:28**

dimbor писал(а): ↑
21.04.2009 21:34
А в качестве полу-оффтопического брюзжания, сопровождающего выкладывание каждой сборки, скажу следующее:
Развитие ситуации с вайном смутно мне напоминает тенденции развития отеч. ПО под уиндоуз. Напимер - экземпляр BS-Клиента считается нерабочим, если в поставке отсутствует профессор криптографии. А также - обновления чудо-программы Такском случаются через день, при его неизменно-куцых возможностях, зато с необходимыми многочисленными дерганиями мышой для установки этих обновлений. Про совсем не мелкое, но все еще мягкое - вообще либо хорошо, либо ничего.

Чего ж Вы хотите? Что эмулируем, на то и похожи...

Добавлено: **21.04.2009 22:58**

prof писал(а): ↑
21.04.2009 22:28
Чего ж Вы хотите? Что эмулируем, на то и похожи...

Мы эмулируем весьма хорошую пользовательскую ОС, уважаемый. И отрицать это - глупо.

Добавлено: **22.04.2009 00:14**

Если условно зачесть (тьфу*3) решение с больными окнами, у рутлеса NX останется одна весомая неприятность - медленное завершение рутлес сессий вайна.
Опять вопрос: задержка между завершением 1с-ки и завершением сессии зависит от типа клиента вин/лин?

Добавлено: **22.04.2009 10:21**

dimbor писал(а): ↑
21.04.2009 21:34
2) Вылечены больные окна нового вайна. nxagent взрывом не задело.

true, fixed

Похоже осталось последнее препятствие - подергивание больных окон, если удастся и это вылечить, курощение наконец удалось.

dimbor писал(а): ↑
22.04.2009 00:14
Если условно зачесть (тьфу*3) решение с больными окнами, у рутлеса NX останется одна весомая неприятность - медленное завершение рутлес сессий вайна.
Опять вопрос: задержка между завершением 1с-ки и завершением сессии зависит от типа клиента вин/лин?

В wine@etersoft 1.0.10.19/13 сейчас 1С под твоим NXWin закрывается мгновенно.

Но похоже есть какая то бага в компонентах nxserver (или wine).
В Linux, недавно, с wine 1.0.8, переводил Х-форвадинг между серверами с ssh -X на nxproxy (не nxclient т.к. установка соединения через nxproxy в разы быстрее) , заметил неприятную штуку - даже notepad, в некоторых случаях не завершает работу. Т.е. через скрипт из MC работает, в .desktop ярлыке установлено "Выполнять в окне терминала" - работает, в .desktop ярлыке НЕ установлено "Выполнять в окне терминала" - после завершения работы nxproxy не закрывается и управление не возвращается в скрипт. Так и не удалось это победить при запуске через $DISPLAY
Победил, запуская wine-программы не через nxproxy с установкой запускаемой программы в $DISPLAY, а напрямую через ssh (X-форвардинг через nxproxy при этом работает).
Кому интересно, могу выложить скрипты для X-форвардинга через nxproxy.

Добавлено: **22.04.2009 10:59**

dimbor писал(а): ↑
21.04.2009 21:34
1) Допилено макс. открытие после макс. закрытия ("firefox").
2) Вылечены больные окна нового вайна. nxagent взрывом не задело.

обновил http://updates.etersoft.ru/pub/Etersoft/RX@Etersoft/Windows/

Добавлено: **22.04.2009 12:03**

Djelf писал(а): ↑
22.04.2009 10:21
Похоже осталось последнее препятствие - подергивание больных окон, если удастся и это вылечить, курощение наконец удалось.

Курощение - это стиль жизни.

И закончится ох, нескоро. Повторно даю ссылку на мои размышлизмы на эту тему.
Из них следует, что есть три пути для решения: Первый - реализовать программу "оптоволокно - в каждый сарай". Второй - реализовать MDI под линуксом. Третий - запретить перетаскивания больных к хреням (опять здравствуй калькулятор под 1.0.8).

Первые два варианта - ненаучная фантастика. Третий - наступание на горло. Других не вижу.
Предлагайте - обсуждаемо.

Djelf писал(а): ↑
22.04.2009 10:21
В 1.0.10.19/13 сейчас 1С под NXWin закрывается мгновенно.

Опа! Похоже, пора обновить фриэныкс, а то он у меня доисторический. Может из-за него...
Хотя, 1с-то понятно - быстро. А вот сессия?

Djelf писал(а): ↑
22.04.2009 10:21
Но похоже есть какая то бага в компонентах nxserver (или wine).
В Linux, недавно, с wine 1.0.8, переводил Х-форвадинг между серверами с ssh -X на nxproxy (не nxclient т.к. установка соединения через nxproxy в разы быстрее) , заметил неприятную штуку - даже notepad, в некоторых случаях не завершает работу. Т.е. через скрипт из MC работает, в .desktop ярлыке установлено "Выполнять в окне терминала" - работает, в .desktop ярлыке НЕ установлено "Выполнять в окне терминала" - после завершения работы nxproxy не закрывается и управление не возвращается в скрипт. Так и не удалось это победить при запуске через $DISPLAY
Победил, запуская wine-программы не через $DISPLAY, а через ssh.

Ну эт мои будущие заморочки.
Поскольку чукчи нифига не читатели, а очень даже писатели, предложение такое:
Чтобы мне было не скучно одному париться, составляя сопроводиловку и переписываясь с итальянцами, сбацай ка и ты пожалуйста статейку на эту тему - у тебя хорошо получается, судя по тому, что я читал на 1с-ном сайте (инфостарте?).
Место - да хотя бы трак. Одно время DjSpike им занялся и написал там умных вещей, а сейчас все заглохло. Очень жалко, но у меня того же времени хватает или на рытье в чужом коде, или - на описание результатов процесса.

Как идеец? Все равно из этой темы долго выуживать полезную инфу, хотя здесь ее прилично. Есть еще исчезающая вероятность, что народ подтянется не только читать.

Добавлено: **22.04.2009 12:26**

dimbor писал(а): ↑
22.04.2009 12:03
сбацай ка и ты пожалуйста статейку на эту тему - у тебя хорошо получается, судя по тому, что я читал на 1с-ном сайте (инфостарте?).
...
Как идеец? Все равно из этой темы долго выуживать полезную инфу, хотя здесь ее прилично. Есть еще исчезающая вероятность, что народ подтянется не только читать.

По установке nxserver статей в интернете хватает, при использовании RX@etersoft проблем будет еще меньше (когда последние пакеты с твоими патчами под все системы сделают). Основная проблема IMHO остается в не убитых "хвостах" от различных NX-серверов/клиентов.
По nxproxy статью нарисую (информации мало и она вся кривая/странная; допилить скрипты чуток еще надо, хотя бы по поводу несовместности скриптов sh/bash, у меня пока скрипты только под bash работают, а надо универсально).

Добавлено: **22.04.2009 12:46**

dimbor писал(а): ↑
22.04.2009 12:03
Повторно даю ссылку на мои размышлизмы на эту тему.
Из них следует, что есть три пути для решения: Первый - реализовать программу "оптоволокно - в каждый сарай". Второй - реализовать MDI под линуксом. Третий - запретить перетаскивания больных к хреням (опять здравствуй калькулятор под 1.0.8).

Первые два варианта - ненаучная фантастика. Третий - наступание на горло. Других не вижу.
Предлагайте - обсуждаемо.

Самому себе подаю идею

, перехватывать клиентом перетаскивание окна и обрабатывать как перетаскивание остальных окон. В принципе, реализуемо. Но таскаться будет за любое место окна, если конечно вайн не будет этим фатально удивлен. Как-нить попробую...

Добавлено: **22.04.2009 13:14**

Место - да хотя бы трак. Одно время DjSpike им занялся и написал там умных вещей, а сейчас все заглохло. Очень жалко, но у меня того же времени хватает или на рытье в чужом коде, или - на описание результатов процесса.

Умные мысли закончились, Вдобавок к этому почти вышла новая Мандрива 2009.1, которую я долго мучал на процесс поднятие RX терминала, а она упиралась. В результате этих мучений , а так же не однократной переустановки ОС с Мандривы 2009.0 на 2009.1 и обратно, пришел к выводу что последняя сборка freenx не работоспособно под любым дистрибутивом Мандривой... В результате разместил в багзиле http://bugs.etersoft.ru/show_bug.cgi?id=3818 .
Да плюс к тому-же не дает мне покоя один модем для которого надо пробросить com порт по локалке...... об этом писал в соседней ветке....

Добавлено: **22.04.2009 14:13**

DjSpike писал(а): ↑
22.04.2009 13:14
почти вышла новая Мандрива 2009.1, которую я долго мучал на процесс поднятие RX терминала, а она упиралась

http://bugs.etersoft.ru/show_bug.cgi?id=3818 посмотрел, на Ubuntu 7.04 на nxagent-локально почти те же симптомы: "remove /tmp/.X0-lock" (не очень страшно, локальные сессии через NX редко нужны), а внешние сессии все равно запускается...
Попробуй DISPLAY_BASE=2000 в node.conf или побольше чем 2000 установить (вроде где-то кому-то помогало

).

Добавлено: **22.04.2009 20:38**

dimbor писал(а): ↑
22.04.2009 12:46
Самому себе подаю идею , перехватывать клиентом перетаскивание окна и обрабатывать как перетаскивание остальных окон. В принципе, реализуемо.

Yes! В результате активной переписки с самим собой подтверждено.

У волшебника Сулеймана - все по честному, без обмана.

А теперь прошу помощи клуба!
fake-заголовок больным окнам все-таки придется сооружать.
Внимание, вопрос: Где в исходниках вайна находится алгоритм вычисления вертикального размера заголовка "MDI" (под виндой это что-то типа GetSystemMetrics(SM_CYCAPTION))? Зависит, по идее, от вертикального разрешения экрана.

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

Добавлено: **22.04.2009 23:59**

dimbor писал(а): ↑
22.04.2009 20:38
А теперь прошу помощи клуба!
под виндой это что-то типа GetSystemMetrics(SM_CYCAPTION)

Почти также как и в винде, вот код из /dlls/user32/mdi.c

Код: Выделить всё

/**********************************************************************
 *                      MDI_CalcDefaultChildPos
 *
 *  It seems that the default height is about 2/3 of the client rect
 */
void MDI_CalcDefaultChildPos( HWND hwndClient, INT total, LPPOINT lpPos, INT delta, UINT *id )
{
    INT  nstagger;
    RECT rect;
    INT spacing = GetSystemMetrics(SM_CYCAPTION) + GetSystemMetrics(SM_CYFRAME) - 1;

Определён в /dlls/user32/sysparams.c как

Код: Выделить всё

    case SM_CYCAPTION:
        if (!spi_loaded[SPI_NONCLIENTMETRICS_IDX]) load_nonclient_metrics();
        return nonclient_metrics.iCaptionHeight + 1;

Добавлено: **23.04.2009 03:05**

Я-то думал, там все кошерно, и nonclient_metrics где-то хитрО вычисляется, а там - статика. Ну значитца и в клиенте поставил статику.

Прошел обычный здешний цикл допилки:
Сначала мне предъявили претензию. Потом долго убеждали, что это это действительно бага, и от фазы луны не зависит. Далее я нашел убедительные аргументы забить - дескать работы дофига, зубило маленькое, стенка толстая и условно-досрочное скоро. Еще чуть попозже предположил, что можно сделать подкоп, и потребовал совочек. Мне дали лопату, в конце тоннеля забрезжил свет.
Все вроде хорошо, главное чтоб не оказалось, что копали не под ту стену (такое здесь часто случалось тоже). И попали не на свободу, а - в карцер.

Ловите очередную сборку. Дергания окон задушены. Но временами Х-ам проходит то, что вроде бы не должно, и возникают любопытные визуальные глюки, вроде безобидные.

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

Upd 23.04.09 13:30: Перевыложено

Upd 24.04.09: Убрано.

Добавлено: **23.04.2009 11:33**

dimbor писал(а): ↑
23.04.2009 03:05
Ловите очередную сборку.

спасибо!
обновления там же-)

unixforum.org

Курощение nomachine клиента - за шаг до ... ((1С, wine@Etersoft, freenx, NXClient for Windows))

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...

Re: Курощение nomachine клиента - за шаг до ...