InitOutput: Set ru_RU.UTF-8 locale
Failed to create the keyboard file
у меня, с линуксовым клиентом, наоборот:
keyboard file created
Модераторы: dimbor, Модераторы разделов
InitOutput: Set ru_RU.UTF-8 locale
Failed to create the keyboard file
keyboard file created
Djelf писал(а): ↑31.03.2009 21:05GDI принтеры можно попробовать покурощать вот так: http://www.samag.ru/art/05.2008/05.2008_02.html
chomper писал(а): ↑31.03.2009 17:27доброе время суток, форумчане..
не могли бы помочь в таком вопросе:
установил на debian 4 rx@etersoft 3.3.0-14 и подключаюсь клиентом nomachine с винды. В файле node.conf очистил все параметры вида COMMAND_START_XXX для того чтобы пользователь не смог запустить файловый менеджер (gnome, kde и др.). Однако если в клиенте выбрать тип desktop'а - "custom", а в нем "run the following command" и например указать gnome-session, то запускается полноценный десктоп.
как отключить эту возможность, чтобы при любых способах подключения к nx-серверу, запускался только специальный скрипт (выделенное приложение)?
заранее благодарен
dimbor писал(а): ↑01.04.2009 04:37Все думал, как бы посмешнее пошутить, и придумал - а выложу-ка очередную тестовую сборку клиента.
Сделано:
1) Наконец допилено "глобальное позиционирование" - выпадающие менюшки и окна за меню пуск не прячутся.
2) Для большинства прог (wine, "KDE-like") вернул игнор перерисовки клиентом менюшек в пределах родительского окна.
3) Убрал баг с невозможностью выбора пункта "высовывающегося" меню.
4) При запуске под сервером с подключенной локалью (крайний патч) корректно отображает заголовки окон (ОО и Ко).
5) Начальное позиционирование окон (ОО) исправлено. Пока интуитивным образом по принципу - заголовок окна "всегда виден".
6) Убрал собственный ляп с падением клиента при обработке строковых свойств нулевой длины.
7) Еще много чего. Вспомню - допишу.
Сопроводиловки пока нет. Запутался в собственных деяниях, да и лень.
Если у кого еще нет нового пакета nx под свою систему, могу выложить nxagent и рассказать, как подключить локал
P.S.: Этой теме между здесь пошел уже второй год. Капец! Я думал, что столько не живут.
P.P.S.: Сегодня звонили из Этерсофта. Предложили участвовать в разработке полностью коммерческой (без открытой части) Etersoft@wine 7. Декларируется уже полностью реализованная поддержка WinAPI по состоянию на момент выхода висты. На выбор предложили работу в отделе разработки терминальных решений, но с условием закрытия кода всех будущих проектов.
Еще предложили другой вариант: У них как раз уходит программист, который занимался патчами открытой части вайна, чтобы открытый вайн не мог запускать приложения "бизнес-сектора". Там нужно вообще виртуозно программить, но даже нижняя планка зарплаты меня приятно удивила. Вот сижу и думаю, на что соглашаться, чтобы денег платили и не напрягаться особо.
Djelf писал(а): ↑01.04.2009 01:23Мы ж не напрямую с физическим принтером работаем, мы делаем виртуальный/транзитный принтер, который расшариваем через NX и который будет работать с CUPS без foomatic, а то что реальный принтер хочет чего-то странного, ну что ж, нас при таком варианте подключения это должно мало волновать (правда только в том случае если вся эта цепочка заработает ).
Djelf писал(а): ↑01.04.2009 15:08upd: После переустановки NX-сервера из ftp://ftp.etersoft.ru/pub/Etersoft/RX@Ete...le/Ubuntu/7.04/ ситуация изменилась. "Отрывов" в меню и подсказках нет, у калькулятора пропал двойной заголовок, но при перетаскивании у него начинается "Пляска Святого Вита".
Мде... версий становится все больше, и маленький загончик в котором живут глюки постепенно расширяется
Djelf писал(а): ↑02.04.2009 01:18Но то что удалось поймать такие глюки говорит только о том, что нужно засинхронизировать какой-то номер в версиях в RX@Etersoft и NXClient@Dimbor чтоб быть уверенным что проверяется именно то, и в том сочетании, что подразумевали разработчики, иначе тестить бессмысленно, а писать о багах глупо
dimbor писал(а): ↑02.04.2009 01:39То-что быстрее работает - надеюсь. Я своей жене, когда она была совсем не женой, уделял внимания меньше чем отрисовке рутлеса.
Djelf писал(а): ↑02.04.2009 01:18Но то что удалось поймать такие глюки говорит только о том, что нужно засинхронизировать какой-то номер в версиях в RX@Etersoft и NXClient@Dimbor чтоб быть уверенным что проверяется именно то, и в том сочетании, что подразумевали разработчики, иначе тестить бессмысленно, а писать о багах глупо
Так я и говорю. Работаем по последним версиям rx и клиента. Если последнего nx под твою систему еще нет, то объясню как локали сделать. У нас уже получалось похожим манером. Десятку на один из серваков поставлю (там же можно использовать закрытую от 1.0.9?). Или один будем использовать, мой/твой - без разницы.
Оки?
dimbor писал(а): ↑02.04.2009 04:48
В новом пакете nx (alt12) кардинально поменялись пути/имена возлежания библиотек и прошитые в них ссылки-стринги.
Также обновилась libX11.so.6, и это главная причина возможной неудачи. Библиотека может не подойти под простую замену файла.
Сначала надо попросить bsavelev'a собрать пакет и под все остальные ОС (Debian?). Там что-то не срослось автоматически - одни логи лежат.
А нет, так пришли личкой свое мыло и вывод команды strings libX11.so.6 | grep "/locale" для имеющейся nx-овой либы. буду тогда слать файлы, хоть это и извращение.
Ну не трави душу, признайся в "разводе", первое число уже прошло.dimbor писал(а): ↑01.04.2009 04:37P.P.S.: Сегодня звонили из Этерсофта. Предложили участвовать в разработке полностью коммерческой (без открытой части) Etersoft@wine 7. Декларируется уже полностью реализованная поддержка WinAPI по состоянию на момент выхода висты. На выбор предложили работу в отделе разработки терминальных решений, но с условием закрытия кода всех будущих проектов.
Еще предложили другой вариант: У них как раз уходит программист, который занимался патчами открытой части вайна, чтобы открытый вайн не мог запускать приложения "бизнес-сектора". Там нужно вообще виртуозно программить, но даже нижняя планка зарплаты меня приятно удивила. Вот сижу и думаю, на что соглашаться, чтобы денег платили и не напрягаться особо.
prof писал(а): ↑02.04.2009 19:49Ну не трави душу, признайся в "разводе", первое число уже прошло.dimbor писал(а): ↑01.04.2009 04:37P.P.S.: Сегодня звонили из Этерсофта. Предложили участвовать в разработке полностью коммерческой (без открытой части) Etersoft@wine 7. Декларируется уже полностью реализованная поддержка WinAPI по состоянию на момент выхода висты. На выбор предложили работу в отделе разработки терминальных решений, но с условием закрытия кода всех будущих проектов.
Еще предложили другой вариант: У них как раз уходит программист, который занимался патчами открытой части вайна, чтобы открытый вайн не мог запускать приложения "бизнес-сектора". Там нужно вообще виртуозно программить, но даже нижняя планка зарплаты меня приятно удивила. Вот сижу и думаю, на что соглашаться, чтобы денег платили и не напрягаться особо.
В процессе дописания WM для "рутлес"-режима NXClient for Windows (nxwin) возникли вопросы, на которые хотелось бы получить ответ с высот квалификации разработчиков wine@etersoft. Речь опять идет о стилях окон программ вайна, в основном 1с-овских.
По моей информации, для линуксовых диспетчеров окон (wm) сейчас существует два подхода установки стилей оформления окна. Первый старый - стандарты Motif, свойство окна _MOTIF_WM_HINTS и пр. Второй - современный - стандарты freedesktop.org, свойство _NET_WM_WINDOW_TYPE и пр. Вайн, по результатам отладки клиента, устанавливает оба свойства.
Воспользовавшись информацией, которая прошлый раз мне здесь была выдана, мной был написана установка стилей окон Х-сервера nx-клиента путем анализа _NET_WM_WINDOW_TYPE. При запуске программ (в т.ч. 1с) под 1.0.8 стили выставляются практически идеально.
Но начиная с 1.0.9, для окон без заголовка вайном выставляется _NET_WM_WINDOW_TYPE_DIALOG вместо _NET_WM_WINDOW_TYPE_UTILITY.
Поэтому приходится использовать _MOTIF_WM_HINTS для установки стилей. Там все нормально.
Возможно ли вернуть новым вайнам старое поведение?
Вопрос не исчерпывается описанной ситуацией, ее-то можно обойти. Гораздо хуже другое: под вайнами 9,10 в рутлес-режиме при закрытии любого окна, контролируемого wm nx-клиента (overrideRedirect==0), возникает примерно 2-х секундная пауза. Это делает работу крайне некомфортной. И тоже, скорее всего, связанно с некими изменениями, сделанными в 1.0.9.
Причем под родными wm описанных проблем не существует в принципе, что позволяет сделать вывод о несовместимости вайна "вниз" - библиотеки nx-сервера построены на базе древнего XFree86.
А если фарш невозможно провернуть назад, подскажите пожалуйста хотя бы методику локализации места ошибки. Что-то пока ничего не приходит в голову.