Re: о кривости esd (was Re:A LSA)
On Mon, 24 Jul 2000, Vlad Harchev wrote: > > Что легко сделать вручную, но неприемлемо в случаи audioserver-а, который > > должен эту задачу выполнять прозрачно для программы. > > То есть ты за то, чтобы не поддерживать ресемплирование? Поддерживать, если получится. Но лучше не поддерживать никак, чем поддерживать криво. > Уж для флайт-симулятора можно пустить отдельно X-server на :1 с нужной bpp. Это кто ж тебе позволит на X-терминале отдельный X-сервер пускать? > > Я тоже чего-то не понимаю, но почему-то мне недавно пришлось вместо > > 1280х1024х24 поставить 1152х846х32 именно из-за того, что задрали глюки > > при просмотре pdf-ов (X- 3.3.6, карточка Matrox) > > Хмм, я думал что они просто не должны были запускаться - насчет глюков я не > в курсе - я их не юзаю. Кто не должны? acroread? Он запускается но все гиперссылки почему-то едут. > > Кстати, берется она сейчас именно с ftp.x.org, так как NCD ее прекратил со > > своего сайта раздавать. > > Тогда обнови ссылки на свой homepage :) Да надо бы. > > > Не согласен по-поводу gtk - это (даже с версией 1.2) очень продвинутый > > > widget set. А вот когда 1.4 выдет (1.3.1 - его пререлиз уже доступен) он > > > будет > > > наверно самым мощным виджетсетом: высокая портабельность, базирование на > > > utf8, поддержка различных языков типа китайского (с иероглифами) и с > > > другим > > > направлением чтения, и все вроде будет double-buffered (не будет никакого > > > > Ты знаешь, Tk его по всем этим пунктам опережает года на три. > > И что, тексты с другим направлением (как иврит) поддерживает? И позволяет с Не в курсе. Надо у Samy Zafrany спросить. > умом подчеркивать всякие иероглифы? По внешнему виду Tk не сравнить с gtk. Позволяет. > И каким же образом Tk опережает года на 3 gtk? > В новом gtk text widget будет именно из Tk (или я путаю с другим виджетом, И это ли не показатель признания gtk team того, что у них много чего хуже чем в Tk? > который не будет в поставке gtk, а будет отдельно) - но GtkText в новом gtk > тоже будет очень навернутый. > > > И единственным недостатком Tk с точки зрения всех этих новомодных > > писателей Desktop-ов является его заточенность под скриптовые языки а не > > C-C++ Я тут как-то попробовал писать на Python-GTK, мне очень не > > понравилось. То, для чего в Python-Tkinter (для чистоты > > сравнения) требуется 2 строчки в Python-Gtk занимает десять. > > Во-первых, gui надо рисовать в gui-билдере glade (я подозреваю, что создавал Категорически не согласен. GUI, нарисованное в gui-билдере получается негибким. Оно имеет привычку разъезжаться при смене надписей на кнопках или дефолтных шрифтов, но даже если это побороть, (ну например SpecTcl прекрасно с этим справляетя) изменения структуры нижележащей базы данных оно не переживает. А gui генереруемое циклом в скрипте гораздо легче относится к подобным вещам, > окно типа "hello, world") во вторых, для тех десяти строк (если они не > связаны Я по-моему пытался что-то мелкое и полезное написать, типа интерактивного редактора PCMCIA-схем. > с конструированием gui, а с заполнением widget'ов данными и обработкой > событий) Естественно, с конструированием GUI. Потому что GUI надо конструировать runtime, сообразуясь с текущим разрешением экрана, количеством цветов, заданными пользователем предпочтениями в области цветов и шрифтов и др. Механизм тем для этого недостаточен. А вот механизм .Xresources при правильном использовании (с учетом вызовов препроцессора в xrdb) - достаточен. > можно сделать одну функцию и юзать ее потом. Одну нельзя. Для каждого диалогового окна придется немножко свою. Либо эта одна будет занимать не 10 строк а 200 и состоять преимущественно из проверок разных условий. > Ну и еще - может ты просто не знал gtk и поэтому писал не эффективно. Я не то чтобы не знал gtk. Я не перевариваю такую идеологию программирования GUI. Из всех чисто C-шных тулкитов меня устраивал только XView. Проблема заключается в том, что любой видгет имеет несколько десятков свойств, которые иногда хочется задать. Но обычно хочется задать не более десятка таких свойств. Xview и Tk позволяют в одном вызове конструктора видгета указать ровно те свойства, которые тебе нужны, а остальные получат некоторые дефолтные значения (заметим, зависящие от текущих значений ресурсов) сами. В gtk с этим гораздо сложнее. > Производителям коммерческого софта хочется использовать компилируемые языки В данном случае (хотя в этом же треде я яростно отстаивал их интересы против АЕН) - на них плевать. У них есть Motif, пускай пишут на нем. На мой взгляд, самым вредным в GNOME и KDE является принцип "все программы должны использовать только наш тулкит". Или пусть как честные ежики пишут не приложения, а компоненты, возможно сопровождая (открытыми и документированными) интерфейсными скриптами Пока не придумано универсального эквивалента IO Redirection для GUI (линзы pad++ все-таки не выход) интерфейс приходится отрывать от функциональности нас
Re: Еще кое-что нарыл в POTATO (ответы многи м)
On Tue, 25 Jul 2000, Victor Vislobokov wrote: > >или воспользуешься шрифтами из console-tools-cyrillic, > >то эффект будет наблюдаться ровно таки описанный. Поскольку koi2alt > >перекодирует только буквы, а символы в диапазоне 0x80-0x9F перекодирует по > >ISO-Latin1. Соответственно, и знак переноса, используемый groff туда > >попадает. Если же следовать букве rfc1489, то символ переноса, > >используемый groff отображается на какую-то псевдографику. > > Ребята! Вы о чем ей богу? > Я говорю, что groff формирует вывод, у которого вместо символа > переноса, символ псевдографики. При чем здесь шрифты и map'ы? Не символ псевдографики, а символ 0x00AD Unicode (SOFT HYPHEN), То что в koi8 на 0xAD лежит какая-то псевдографика, здесь ни при чем. Правильное решение было уже предложено - создать devkoi8r, которая будет форматировать текст считая, что его выходная кодировка koi8-r, а не 8859-1. > Что от того, что я другой шрифт загружу groff станет по другому текст > форматировать? Не смешите меня! Не станет. Но в случае несоответствия шрифта стандартам глюка может оказаться скрытой. > Я говорю, что на latin1 этот groff считает, что символом переноса > должен быть не "-", а символ с кодом 174. При чем здесь шрифты и > map'ы? Это явно КРИВАЯ работа groff'а. Это абсолютно прямо. В Latin1 173 символ это и есть знак переноса (SOFT HYPHEN). Криво - отсутствие в groff готовых девайсов для 8-битных выходных кодировок, отличных от Latin1. > >Так что шрифта Cyr_a8x16 существуют на самом деле два - один в > стандартной >поставке, другой в console-tools-cyrillic. Последний > отличается наличием >правильного unicode mapping. > > > И леший с ним. Меня пока и koi2alt вполне устраивает, правильный > он или неправильный у меня все работает. А меня нет. Я иногда читаю письма, в которых активно используется псевдографика. И многих других людей тоже - им приходится иногда смотреть на унаследованные от доса схемки псевдографикой. -- Victor Wagner [EMAIL PROTECTED] Programmer Office:7-(095)-785-09-72 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Анекдот
Привет! Собственно про wu-imap из slink. Новая версия пакета исправляет одну лишь ошибку - переносит imap папки из ~/ в каталог ~/mail Ха-Ха :( По этому поводу не мог бы кто-нибудь поделиться опытом работы с courier-imap (кажется так), который появился в потато? С wu-imap, кроме забывчивости майнтэйнера, у меня были проблемы с диалапщиками (иногда при обрыве линии оставался экземпляр imapd, который блокировал ящик). И очень уж много говорят про его дырявость. -- Best regards, Sergey Chumakov 2:450/77[.43]
Re: Еще кое-что нарыл в POTATO (ответы многим)
On Tue, 25 Jul 2000, Victor Vislobokov wrote: > >> >Сравните шрифты. > >> > >> > >> Смысл? Мы ведь про текстовую моду говорим. Шрифт Cyr_a8x16 я думаю > >> он и в Африке таковым останется, не только в RH. > > >Да, но если ты вместо koi2alt положишь туда правильную таблицу > >перекодировки, например rfc1489.map с www.ice.ru/~slobin > >или воспользуешься шрифтами из console-tools-cyrillic, > >то эффект будет наблюдаться ровно таки описанный. Поскольку koi2alt > >перекодирует только буквы, а символы в диапазоне 0x80-0x9F перекодирует по > >ISO-Latin1. Соответственно, и знак переноса, используемый groff туда > >попадает. Если же следовать букве rfc1489, то символ переноса, > >используемый groff отображается на какую-то псевдографику. > > Ребята! Вы о чем ей богу? > Я говорю, что groff формирует вывод, у которого вместо символа > переноса, символ псевдографики. При чем здесь шрифты и map'ы? > Что от того, что я другой шрифт загружу groff станет по другому текст > форматировать? Не смешите меня! > Я говорю, что на latin1 этот groff считает, что символом переноса > должен быть не "-", а символ с кодом 174. При чем здесь шрифты и > map'ы? Это явно КРИВАЯ работа groff'а. > Ну посмотрите кто-нибудь наконец хотя бы файл > /usr/share/groff/fonts/devlatin1/R > ту строчку, которая начинается на char173 и поймите, что в ней > ошибка. Ну ни в одной другой строке с описанием char нет ничего > после кавычек, а в строке char173 есть. > Словом вижу, что мы увязли, попробую написать ведущему для > начала. > > >Так что шрифта Cyr_a8x16 существуют на самом деле два - один в стандартной > >поставке, другой в console-tools-cyrillic. Последний отличается наличием > >правильного unicode mapping. > > > И леший с ним. Меня пока и koi2alt вполне устраивает, правильный он > или неправильный у меня все работает. Блин, в своем последнем письме на эту тему я уже высказал (может, завуалированную) идею о том, что в RH groff вызвается с ключем -Tascii, а в дебиане с ключем -Tlatin1. Сейчас я проверил эту идею на RH - вызвал groff с ключем -Tlatin1 и увидел (впервые) этот символ псевдографики (он есть при любом значении переменной LANG, главное чтобы была koi2alt и cyr_ шрифт). Итак, замена NROFF /usr/bin/groff -Tlatin1 -mandoc на NROFF /usr/bin/groff -Tascii -mandoc в /etc/man.config должна решить эту проблему в дебиане. Хорошо бы узнать у автора groff (James Clark) - что более идеологически правильно, или хакнуть файлы /usr/share/groff/fonts/devlatin1/* на предмет символа 174. > Виктор > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Best regards, -Vlad
Re: о кривости esd (was Re:A LSA)
On Tue, 25 Jul 2000, Aleksey Novodvorsky wrote: Добрый день, Алексей! > Влад, добрый вечер! > Vlad Harchev wrote: > > > > > > > > > Ну, не знаю насчет единственной... BSD существовала, существует и будет > > > существовать. Поэтому мне не кажется, что если есть какая-то софтина, > > > которая _уже_ имеет немалую историю жизни под BSD или MIT лицензией, > > > ее стоит отвергать _только_ на этом основании или стремиться > > > перелицензировать. Хотя по-моему юридически последний вариант проходит. > > > > Да, BSD лицензия - очень важная лицензия в компьютерном мире, и с > > логической > > точки зрения (и с точки зрения пользователя) это наилучшая лицензия для _уже > > зрелых и практически завершенных_ проектов. Такая лицензия разрешает > > использовать код в коммерческом софте, что лучше для пользователя - он > > получает качественный, пусть и коммерческий, софт, так и для > > фирмы-разработчика, которая может запросто подзаработать на этом софте. > > Стоп. Уже не понял. Фирма разработчик: Блин, письмо было написано поздно вечером, и я забыл вставить одно слово - любая фирма, разрабатывающая софт, а не разработчик софта под bsd лицензией. Извиняюсь. Из-за это несколько ваших предложений снизу оказываются не в тему. > -- прекрасно может зарабатывать и на GPL-софте; > -- может выпускать софт под двумя лицензиями (весьма распространенный, > кстати, вариант). > Но, главное: бОльшая часть свободного софта создается не фирмами! Более того, > если свободный проект > попадает "под фирму" (в виде навязчивого спонсорства, например), то его > качество часто страдает. > Типичный пример -- GNOME и Enlightenment на ранних стадиях развития. RH чуть > не угробил GNOME и почти > угробил E, благодаря своим менеджерам. Теперь это уже классика, даже RH > сделал выводы. И свободные > проекты уже избегают спонсорства одной, пусть и очень крупной фирмы. Не думаю, что это так. RH не спонсировала GNOME - GNOME разрабатывался сотрудниками RH (то есть им приказывали, промывали мозги, поощеряли акциями, могли испортить "личное дело", подгоняли сроки выхода к срокам выхода новой версии RH). В случае спонсорства - совершенно другие отношения (по-моему). > На мой взгляд, основная модель развития свободного софта предполагает только > спонсорство команд > фирмами, но не фирмы -- производители софта. Конечно, возможны варианты, > многое зависит от типа софта > etc., я говорю о типичном случае. Я думаю, что много чего спносировала лично Sun. > > Именно > > поэтому разработчики freetype по-крайне мере первые ее версии выпускали под > > BSD/MIT лицензией - чтобы позволить поддерживать ttf в как можно большем > > числе > > систем. C wine также. > > Так почему же они сделали (с Вашей точки зрения) все наоборот? Не понял - что они сделали наоборот с моей точки зрения? А насчет лицензии freetype- она все-еще BSD-like (и вроде никогда не изменится) и явно позволяет использовать этот код в коммерческих продуктах. > > > > И не следует забывать, что немалая часть кода с BSD лицензией > > разрабатывалась > > при спонсировании (пусть даже косвенном) со стороны правительственных > > органов > > (типа министерства обороны) - которые и заказывали лицензию. > > Это все -- уже история. О нашем МО я говорить не буду, а у них все далеко не > так уж однозначно. NASA > очень любит GPL. Кстати, именно Debian _GNU_/Linux летал в космос. Так просто NASA не пишет код, который может пригодится в коммерческом софте - поэтому им не заказывают BSD лицензию, IMHO. То, что они выбрали debian ни о чем не говорит (кроме как о возможно большей пригодности linux для их задач). > > > > > > Да, GPL это гарантия жизнеспособности движения (большинство людей ценят > > свое > > неоплачиваемое время, которое они затратили на разработку софта, и не хотят > > на их труде наживались просто-так другие) > > И снова, даже здесь, Вы -- о бабках! Поверьте, это далеко не главная > мотивация в использовании GPL. По-моему, главная (может еще просто неосведомленность автора о других лицензиях или промытость мозгов всякими PR). > Те, кто так действительно думает, использует "комунистическую лицензию", типа > "только не для > продажи". Кстати, MS ее очень любит. Может просто опасаются, что софт будет считаться non-free и не будет настолько распространен авторами дистрибьютивов, как GPLed. > > , но не факт что это движение - > > полезное/оптимальное/правильное. > > Оптимальное движение -- что это? Полезное? Вы испольуете Debian? gcc? Вам они > -- полезны? А полезно > ли движение -- сомневаетесь? Вот именно это я никак и не могу понять. Плевать > в колодец -- если и не > вредно, то некрасиво. "Оптимальность" - в плане технического совершенства софта, его архитектуры, гибкости (короче, вложения интеллектуальных усилий на этапе проектирования) - которые были бы очень кстати для тех, кто захочет включить части кода (или библиотеку) в свою gpled программу - иными словами обеспечение легкой утилизации кода между пусть даже f
Re: Еще кое-что нарыл в POTATO (ответы многи м)
Эпиграф: Ну царевич, ну орел Враз беду от нас отвел > Блин, в своем последнем письме на эту тему я уже высказал (может, >завуалированную) идею о том, что в RH groff вызвается с ключем -Tascii, >а в дебиане с ключем -Tlatin1. Сейчас я проверил эту идею на RH - вызвал groff >с ключем -Tlatin1 и увидел (впервые) этот символ псевдографики (он есть при >любом значении переменной LANG, главное чтобы была koi2alt и cyr_ шрифт). > Итак, замена >NROFF /usr/bin/groff -Tlatin1 -mandoc >на >NROFF /usr/bin/groff -Tascii -mandoc >в /etc/man.config должна решить эту проблему в дебиане. Хорошо бы узнать у А теперь попробуй посмотреть РУССКИЙ ман с ключем -Tascii. Вместо русских букв - угадай что? К твоему сведению, даже в mc.ext заменили -Tascii на -Tlatin1 именно по причине непоказа русских букв в случает -Tascii Виктор
Re: Еще кое-что нарыл в POTATO (ответы многи м)
>> Ребята! Вы о чем ей богу? >> Я говорю, что groff формирует вывод, у которого вместо символа >> переноса, символ псевдографики. При чем здесь шрифты и map'ы? >Не символ псевдографики, а символ 0x00AD Unicode (SOFT HYPHEN), >То что в koi8 на 0xAD лежит какая-то псевдографика, здесь ни при чем. >Правильное решение было уже предложено - создать devkoi8r, которая будет >форматировать текст считая, что его выходная кодировка koi8-r, а не >8859-1. Не UNICODE 0x00AD, а именно 0xAD. Посмотри в HEX виде. >> Я говорю, что на latin1 этот groff считает, что символом переноса >> должен быть не "-", а символ с кодом 174. При чем здесь шрифты и >> map'ы? Это явно КРИВАЯ работа groff'а. >Это абсолютно прямо. В Latin1 173 символ это и есть знак переноса (SOFT >HYPHEN). Криво - отсутствие в groff готовых девайсов для 8-битных >выходных кодировок, отличных от Latin1. Пусть будет SOFT HYPHEN. Но ты согласен, что в файлах есть ошибка или нет? Далее. Кто возьмется сделать devkoi8-r? С уважением, Виктор
Re: Еще кое-что нарыл в POTATO (ответы многи м)
On Tue, 25 Jul 2000, Victor Vislobokov wrote: > From: Victor Vislobokov <[EMAIL PROTECTED]> > Subject: Re: Еще кое-что нарыл в POTATO (ответы многим) > X-Mailer: Microsoft Outlook Express 4.72.3110.1 > > Эпиграф: > Ну царевич, ну орел > Враз беду от нас отвел > > >завуалированную) идею о том, что в RH groff вызвается с ключем -Tascii, > >а в дебиане с ключем -Tlatin1. Сейчас я проверил эту идею на RH - вызвал > groff > > А теперь попробуй посмотреть РУССКИЙ ман с ключем -Tascii. > Вместо русских букв - угадай что? И я не вижу причин, почему с -Tlatin1 результат должен быть другой. Покажите мне в стандартном определении ISO 8859-1 (которую можно взять например в /usr/lib/catdoc/8859-1.txt) хотя бы одну CYRILLIC LETTER. Мораль - русские маны надо форматировать с -Tkoi8-r. А если таковой нет, ее надо выдумать. А вот при форматировании с -Tps должна автоматически подставляться правильная таблица имен глифов в зависимости от... Даже не знаю чего. Текущей локали - как то не хочется, а в формате man-ов указание кодировки как-то не предусмотрено. > К твоему сведению, даже в mc.ext заменили -Tascii на -Tlatin1 именно > по причине непоказа русских букв в случает -Tascii Нифига не русских - немецких, французских и прочих, которые в этой самой Latin-1 _бывают_ -- Victor Wagner [EMAIL PROTECTED] Programmer Office:7-(095)-785-09-72 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: devkio8r (Re: Еще кое-что нарыл в POTATO)
Дмитрий, Вы совершенно правы в принципе. Не уверен только, что править надо именно описание шрифта, здесь может хватить ссылки devkoi8 на devlatin1. А вот tmac.koi8 создать надо. Rgrds, AEN Дмитрий Б. Сидоров wrote: > Господа, по-моему, мы не там смотрим.Очевидно, что groff имеет > насторойки на выходное устройство, на имеющийся у него набор символов, > в том числе устройство типа ascii и типа latin1. man в Debian для > вывода на консоль использует -T latin1, в результате мы и имеем на > месте переноса при загруженном русском шрифте "двойной вверх и > одиночный влево" Надо определить /usr/share/groff/font/devkoi8r и > заставить man его использовать, причем переключать man на devkoi8r > надо при загрузке шрифта, и для этого можно использовать $MANOPT А > лазить в чужой монастырь и править latin1 просто некорректно Дмитрий
Re: Еще кое-что нарыл в POTATO (ответы многи м)
>> А теперь попробуй посмотреть РУССКИЙ ман с ключем -Tascii. >> Вместо русских букв - угадай что? >И я не вижу причин, почему с -Tlatin1 результат должен быть другой. >Покажите мне в стандартном определении ISO 8859-1 (которую можно >взять например в /usr/lib/catdoc/8859-1.txt) хотя бы одну >CYRILLIC LETTER. Я вижу. Поскольку русские буквы >128, то понятно дело должны. (На UNICODE можешь не ссылаться - гадость эта UNICODE и происки врагов наших). >Мораль - русские маны надо форматировать с -Tkoi8-r. А если таковой >нет, ее надо выдумать. С одной стороны, ты вроде прав. С другой стороны, получается, что для украинцев будет -Tkoi8-u, для немцев -Tlatin-deuch и т.д. Нафига? Пусть groff смотрит локаль и с ней и работает. >А вот при форматировании с -Tps должна автоматически подставляться >правильная таблица имен глифов в зависимости от... Даже не знаю чего. >Текущей локали - как то не хочется, а в формате man-ов указание >кодировки как-то не предусмотрено. Мдя. Веселая история. Впрочем, как мне кажется, man скоро умрет. Раз уж у меня возникала идея перенести man'ы, info и т.д. в html... С уважением, Виктор
Re: Еще кое-что нарыл в POTATO
++ 25/07/00 01:27 +0900 - Fedor Zuev: > On Mon, 24 Jul 2000, Victor Vislobokov wrote: > > VV> Смысл? Мы ведь про текстовую моду говорим. Шрифт > VV>Cyr_a8x16 я думаю он и в Африке таковым останется, не только в > VV>RH. > > VV> Мне видится фича в том, что groff глядя на русскую > VV>локаль ведет себя отлично в RH и Debian. Вопрос только > VV>"почему"? > > В Debian собственный доморощенный man > (man-db). Соответственно groff вызывается с разными опциями. > У меня (из Woody) > groff 1.15.3-2 > man-db 2.3.17-1 Господа, а у меня действительно ни хрена русские маны в woody не работают. Может подскажете? Peter Novodvorsky, IPLabs Linux Team member: [EMAIL PROTECTED] Linux.RU.NET Team member: [EMAIL PROTECTED], [EMAIL PROTECTED] -- System Information Debian release: woody System: Linux lambda 2.2.14 #1 Sun Jan 16 13:48:57 EST 2000 i586 unknown pgpzUtlvFNhnQ.pgp Description: PGP signature
Re: о кривости esd (was Re:A LSA)
On Tue, 25 Jul 2000, Victor Wagner wrote:
>
> On Mon, 24 Jul 2000, Vlad Harchev wrote:
>
> > > Что легко сделать вручную, но неприемлемо в случаи audioserver-а, который
> > > должен эту задачу выполнять прозрачно для программы.
> >
> > То есть ты за то, чтобы не поддерживать ресемплирование?
>
> Поддерживать, если получится. Но лучше не поддерживать никак, чем
> поддерживать криво.
По-любому, ее хорошо бы поддерживать. Хотя бы downsampling.
> > Уж для флайт-симулятора можно пустить отдельно X-server на :1 с нужной
> > bpp.
>
> Это кто ж тебе позволит на X-терминале отдельный X-сервер пускать?
Играть, под X по сети - оригинально... Если тебе нужен этот acm - его тогда
уж проще будет попробовать хакнуть. По-любому - это к создателю aсm - так как
общее решение этой проблеммы (в X) всегда будет менее производительно чем
частное (в acm), IMO.
> > > Я тоже чего-то не понимаю, но почему-то мне недавно пришлось вместо
> > > 1280х1024х24 поставить 1152х846х32 именно из-за того, что задрали глюки
> > > при просмотре pdf-ов (X- 3.3.6, карточка Matrox)
> >
> > Хмм, я думал что они просто не должны были запускаться - насчет глюков я
> > не
> > в курсе - я их не юзаю.
>
> Кто не должны? acroread? Он запускается но все гиперссылки почему-то едут.
Тогда я не знаю - может acroread 4 (или 3) следует попробовать?
> > > > Не согласен по-поводу gtk - это (даже с версией 1.2) очень продвинутый
> > > > widget set. А вот когда 1.4 выдет (1.3.1 - его пререлиз уже доступен)
> > > > он будет
> > > > наверно самым мощным виджетсетом: высокая портабельность, базирование на
> > > > utf8, поддержка различных языков типа китайского (с иероглифами) и с
> > > > другим
> > > > направлением чтения, и все вроде будет double-buffered (не будет
> > > > никакого
> > >
> > > Ты знаешь, Tk его по всем этим пунктам опережает года на три.
> >
> > И что, тексты с другим направлением (как иврит) поддерживает? И позволяет с
>
> Не в курсе. Надо у Samy Zafrany спросить.
Спроси, расскажешь потом. Уверен, что не поддерживает.
> > умом подчеркивать всякие иероглифы? По внешнему виду Tk не сравнить с gtk.
>
> Позволяет.
> > И каким же образом Tk опережает года на 3 gtk?
> > В новом gtk text widget будет именно из Tk (или я путаю с другим виджетом,
> И это ли не показатель признания gtk team того, что у них много чего хуже
> чем в Tk?
Это не есть показатель, что там много чего хуже. Просто люди экономят свое
время.
> > который не будет в поставке gtk, а будет отдельно) - но GtkText в новом gtk
> > тоже будет очень навернутый.
> >
> > > И единственным недостатком Tk с точки зрения всех этих новомодных
> > > писателей Desktop-ов является его заточенность под скриптовые языки а не
> > > C-C++ Я тут как-то попробовал писать на Python-GTK, мне очень не
> > > понравилось. То, для чего в Python-Tkinter (для чистоты
> > > сравнения) требуется 2 строчки в Python-Gtk занимает десять.
> >
> > Во-первых, gui надо рисовать в gui-билдере glade (я подозреваю, что
> > создавал
>
> Категорически не согласен. GUI, нарисованное в gui-билдере получается
> негибким. Оно имеет привычку разъезжаться при смене надписей на кнопках
> или дефолтных шрифтов, но даже если это побороть, (ну например SpecTcl
> прекрасно с этим справляетя) изменения структуры нижележащей базы данных
Ты говоришь это, совершенно не имея компетенции. Вообще, gtk основан на
понятии контейнер (первичные table, hbox, vbox, fixed_positions и пр.) Как раз
там вообще не сохраняется информации о положении виджета, присвоенного ему gui
билдером. Посмотри как-нить код, использующий gtk - там программа, создающая
диалог "Hеllo, World" c двумя кнопками Ok, Cancel имеет вид (это программа на
С++ - как С ее не скопилишь из-за коментариев и обяхвлений переменных не в
начале):
#include
void main(int,char**)
{
gtk_init(0,NULL);
GtkWidget* wnd = gtk_window_new(GTK_WINDOW_TOPLEVEL);//создали контейнер
//окно
GtkWidget* vb = gtk_vbox_new(1,1);//создали вертикальную коробку - все что в
//нее помещаем будет расположено друг над другом, первый аргумент -
//это то, что все помещаемые в нее виджеты будут иметь равный размер
//по вертикали, второй - промежуток между ними
GtkWidiget* label = gtk_label_new("Hello, world");//статическая строка
gtk_box_pack_start(GTK_BOX(vb),label,1,1,0);//вставили строку в коробку
//сверху
GtkWidget* hb = gtk_hbox_new(1,1);//создали горизонтальную коробку -
//все что в нее помещаем будет расположено по горизонтали, с равным
//размером по горизонтали
GtkWidget* btn = gtk_button_new_with_label("OK");//создали кнопку
gtk_signal_connect(GTK_OBJECT(btn),"clicked",GTK_SIGNAL_FUNC(gtk_exit),NULL);
//теперь функция gtk_exit будет вызвана при нажатии кнопки
gtk_box_pack_start(GTK_BOX(hb),btn,1,1,0);//вставили кнопку в гор. коробку
btn = gtk_button_new_with_label("Cancel");//еще кнопка, но ничего не будет
//делать
gtk_box_pack_start(GTK_B
Re: Еще кое-что нарыл в POTATO (ответы многим)
On Tue, 25 Jul 2000, Victor Vislobokov wrote: > Эпиграф: > Ну царевич, ну орел > Враз беду от нас отвел > > > Блин, в своем последнем письме на эту тему я уже высказал (может, > >завуалированную) идею о том, что в RH groff вызвается с ключем -Tascii, > >а в дебиане с ключем -Tlatin1. Сейчас я проверил эту идею на RH - вызвал > groff > >с ключем -Tlatin1 и увидел (впервые) этот символ псевдографики (он есть при > >любом значении переменной LANG, главное чтобы была koi2alt и cyr_ шрифт). > > > Итак, замена > >NROFF /usr/bin/groff -Tlatin1 -mandoc > >на > >NROFF /usr/bin/groff -Tascii -mandoc > >в /etc/man.config должна решить эту проблему в дебиане. Хорошо бы узнать у > > А теперь попробуй посмотреть РУССКИЙ ман с ключем -Tascii. > Вместо русских букв - угадай что? Да уж, блин. Я не пробовал (нет русских у меня манов) но верю что результат неудовлетворителный :) > К твоему сведению, даже в mc.ext заменили -Tascii на -Tlatin1 именно > по причине непоказа русских букв в случает -Tascii > > Виктор > Best regards, -Vlad
Re: Еще кое-что нарыл в POTATO (ответы многим)
On Tue, 25 Jul 2000, Victor Vislobokov wrote: >[...] > Мдя. Веселая история. Впрочем, как мне кажется, man скоро > умрет. Раз уж у меня возникала идея перенести man'ы, info и т.д. в html... К слову сказать (вдруг кто не в курсе) - в Solaris все маны - в формате docbook, и никакой groff для man'ов не используется. > С уважением, Виктор Best regards, -Vlad
Re: Еще кое-что нарыл в POTATO (ответы многим)
On Tue, 25 Jul 2000, Vlad Harchev wrote: VH>On Tue, 25 Jul 2000, Victor Vislobokov wrote: VH>>[...] VH>> Мдя. Веселая история. Впрочем, как мне кажется, man скоро VH>> умрет. Раз уж у меня возникала идея перенести man'ы, info и т.д. в html... VH> VH> К слову сказать (вдруг кто не в курсе) - в Solaris все маны - в формате VH>docbook, и никакой groff для man'ов не используется. [EMAIL PROTECTED] /usr/man/man1/ls.1 /usr/man/man1/ls.1: [nt]roff, tbl, or eqn input text [EMAIL PROTECTED] -a SunOS inet 5.6 Generic_105182-19 i86pc i386 i86pc ы? -- Paul S. Romanchenko uin 609866
Re: о кривости esd (was Re:ALSA)
Влад, добрый день! Vlad Harchev wrote: > On Tue, 25 Jul 2000, Aleksey Novodvorsky wrote: > > > > проекты уже избегают спонсорства одной, пусть и очень крупной фирмы. > >Не думаю, что это так. RH не спонсировала GNOME - GNOME разрабатывался > сотрудниками RH (то есть им приказывали, промывали мозги, поощеряли акциями, > могли испортить "личное дело", подгоняли сроки выхода к срокам выхода > новой версии RH). В случае спонсорства - совершенно другие отношения > (по-моему). Это вопрос терминологии и особенностей оформления отношений. Последнее часто зависит от налогового законодательства. > > > > На мой взгляд, основная модель развития свободного софта предполагает > > только спонсорство команд > > фирмами, но не фирмы -- производители софта. Конечно, возможны варианты, > > многое зависит от типа софта > > etc., я говорю о типичном случае. > >Я думаю, что много чего спносировала лично Sun. Мне об этом не известно. > > > > > Именно > > > поэтому разработчики freetype по-крайне мере первые ее версии выпускали > > > под > > > BSD/MIT лицензией - чтобы позволить поддерживать ttf в как можно большем > > > числе > > > систем. C wine также. > > > > Так почему же они сделали (с Вашей точки зрения) все наоборот? > >Не понял - что они сделали наоборот с моей точки зрения? >А насчет лицензии freetype- она все-еще BSD-like (и вроде никогда не > изменится) и явно позволяет использовать этот код в коммерческих продуктах. Sorry, насчет freetype я не посмотрел. > > > > > > > И снова, даже здесь, Вы -- о бабках! Поверьте, это далеко не главная > > мотивация в использовании GPL. > >По-моему, главная (может еще просто неосведомленность автора о других > лицензиях или промытость мозгов всякими PR). Это сложно проверить, но я буду настивать на своем. Хотя бы потому, что все мои знакомые разработчики под GPL (их не так уж мало) ииеют совершенно другую мотивацию. Не судите ли Вы, исходя из своей мотивации, распространяя ее на всех? Хиппи и яппи всегда были и будут. > > > > > > полезное/оптимальное/правильное. > > > > Оптимальное движение -- что это? Полезное? Вы испольуете Debian? gcc? Вам > > они -- полезны? А полезно > > ли движение -- сомневаетесь? Вот именно это я никак и не могу понять. > > Плевать в колодец -- если и не > > вредно, то некрасиво. > > "Оптимальность" - в плане технического совершенства софта, его архитектуры, > гибкости (короче, вложения интеллектуальных усилий на этапе проектирования) > - которые были бы очень кстати для тех, кто захочет включить части кода (или > библиотеку) в свою gpled программу - иными словами обеспечение легкой > утилизации кода между пусть даже free софтом. > Ведь любую программу можно писать необдуманно, а можно написать > библитотеку для данной проблемной области (с не очень кривым API) и потом > юзать ее из функции main() в которую выродиться программа (я утрирую). Вы писали об оптимальности _движения_, на это я и среагировал. > > спонсоров (не тех, > > которые сейчас наводнили Москву), то GPL -- лучший выбор. То есть > > действительно амбициозный проект, > > начинающийся с нуля, _должен_ _сейчас_ быть GPL. > > Если придираться к словам - то что такое амбициозный проект? Это тот, > который никогда не заврешиться, или тот, который нужен компьютерной индустрии? Ни то, ни другое. Это проект, который удовлетворит личные амбиции автора. Свободный софт -- авторский софт. Ученый, в большинстве случаев, удовлетворяет личные амбиции (не материальные!). Здесь -- то же самое или похоже. Кто такой программист? Творец или высокооплачиваемый служащий? Каждый решает для себя. Точно так же, как и художник: некоторые работают только на заказ, некоторые -- только для вечности (и для увековечивания своего имени), некоторые -- сочетают то и другое (не всегда удачно). Люди действительно бывают очень разные. > > Вот sendmail, bind, wine и freetype и NAS и xfree и другие x servers, > festival, sphinx - очень полезные проекты - они под BSD лицензией. Очень много > научного софта под BSD лицензией, наверно больше чем gpled. > Да, GPL может быть оптимальным для группы программеров-любителей, которые > просто хотят заявить о себе и просто пописать какую-нить ерунду, или взять > много кода из другого GPLed софта, которых никто не спонсирует. Ну почему Вы _так_ думаете о людях, мотивация которых Вам чужда? Контрпримеров так много, что и гвоорить об этом странно. Скажу о своей команде. Я _никогда_ не возьму на работу того, кого сейчас принято называть "профессионалом", то есть человека, который за деньги хорошо делает указанную ему часть работы. Мне нужны -- творцы.И -- единомышленники. А профессионализма у них не меньше. > > > > > > > Вы исходите из тезисов: > > -- доминирования собственнического софта; > > Этого не хочет только ленивый/глупый/очень богатый. В таких случаях всегда думаешь: к какой категории отнести себя? Если я -- глупый, то Вы вряд ли стали бы тратить время на переписку со мной (иначе попали бы в ту же категорию).
Re: Еще кое-что нарыл в POTATO (ответы многим)
On Tue, 25 Jul 2000, Paul S. Romanchenko wrote: > On Tue, 25 Jul 2000, Vlad Harchev wrote: > > VH>On Tue, 25 Jul 2000, Victor Vislobokov wrote: > VH>>[...] > VH>> Мдя. Веселая история. Впрочем, как мне кажется, man скоро > VH>> умрет. Раз уж у меня возникала идея перенести man'ы, info и т.д. в > html... > VH> > VH> К слову сказать (вдруг кто не в курсе) - в Solaris все маны - в формате > VH>docbook, и никакой groff для man'ов не используется. > > [EMAIL PROTECTED] /usr/man/man1/ls.1 > /usr/man/man1/ls.1: [nt]roff, tbl, or eqn input text > [EMAIL PROTECTED] -a > SunOS inet 5.6 Generic_105182-19 i86pc i386 i86pc > > ы? В Solaris8 по-крайне мере. Sorry for confusion. > -- > Paul S. Romanchenko > uin 609866 Best regards, -Vlad
Re: Еще кое-что нарыл в POTATO (ответы многим)
On Tue, Jul 25, 2000 at 01:36:44PM +0400, Victor Wagner wrote: > А вот при форматировании с -Tps должна автоматически подставляться > правильная таблица имен глифов в зависимости от... Даже не знаю чего. > Текущей локали - как то не хочется, а в формате man-ов указание > кодировки как-то не предусмотрено. должно быть от LC_MESSAGES, так как язык man'а зависит от этого, но на деле $ export LC_MESSAGES=ru_RU.KOI8-R $ man -Tps rpm >rpm.ps $ gv rpm.ps приводит к конфузу. -- Alexander Kotelnikov Saint-Petersburg, Russia
Re: Еще кое-что нарыл в POTATO (ответы многи м)
On Tue, 25 Jul 2000, Victor Vislobokov wrote: > Не UNICODE 0x00AD, а именно 0xAD. Посмотри в HEX виде. В случае Latin-1 это одно и то же. Unicode коды меньше 255 по определению совпадают с соответствующими кодами Latin-1 > >Это абсолютно прямо. В Latin1 173 символ это и есть знак переноса (SOFT > >HYPHEN). Криво - отсутствие в groff готовых девайсов для 8-битных > >выходных кодировок, отличных от Latin1. > > > Пусть будет SOFT HYPHEN. Но ты согласен, что в файлах есть ошибка > или нет? Нет. Есть ошибка в дистрибутиве groff, заключающая в отсутствии каталога devkoi8-r, но ни в одном из существующих файлов ошибки нет. -- Victor Wagner [EMAIL PROTECTED] Programmer Office:7-(095)-785-09-72 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: Еще кое-что нарыл в POTATO (ответы многи м)
>> Пусть будет SOFT HYPHEN. Но ты согласен, что в файлах есть ошибка >> или нет? >Нет. Есть ошибка в дистрибутиве groff, заключающая в отсутствии каталога >devkoi8-r, но ни в одном из существующих файлов ошибки нет. Т.е. ты считаешь, что строка в файлах /usr/share/groff/font/devlatin1/* начинающаяся с char173 правильная? Тогда объясни мне, почему больше НИГДЕ во всех этих файлах нет подобных строк? Везде пишется char" а не char173 24 0 0255 Подобного "24 0 0255" хвоста больше НЕТ НИ У ОДНОЙ записи, начинающейся с "char".
Re: о кривости esd (was Re:A LSA)
On Tue, 25 Jul 2000, Vlad Harchev wrote: > > Поддерживать, если получится. Но лучше не поддерживать никак, чем > > поддерживать криво. > > По-любому, ее хорошо бы поддерживать. Хотя бы downsampling. > > > Уж для флайт-симулятора можно пустить отдельно X-server на :1 с нужной > > > bpp. > > > > Это кто ж тебе позволит на X-терминале отдельный X-сервер пускать? > > Играть, под X по сети - оригинально... Если тебе нужен этот acm - его тогда Почему бы и нет, если сеть 100mbit. > уж проще будет попробовать хакнуть. По-любому - это к создателю aсm - так как > общее решение этой проблеммы (в X) всегда будет менее производительно чем > частное (в acm), IMO. acm является типичным представителем старых Unix-овских программ. Отряхнуть с себя этого "ветхого Адама" могут позволить себе только всякие гномщики и KDE-шники, но не те, кто действительно хочет воспользоваться всем полезным, в накопленном в Unix багаже. > > > Хмм, я думал что они просто не должны были запускаться - насчет глюков > > > я не > > > в курсе - я их не юзаю. > > > > Кто не должны? acroread? Он запускается но все гиперссылки почему-то едут. > > Тогда я не знаю - может acroread 4 (или 3) следует попробовать? И тот и другой пробовал. Четвертый вообще segfault-ится. > > Категорически не согласен. GUI, нарисованное в gui-билдере получается > > негибким. Оно имеет привычку разъезжаться при смене надписей на кнопках > > или дефолтных шрифтов, но даже если это побороть, (ну например SpecTcl > > прекрасно с этим справляетя) изменения структуры нижележащей базы данных > > Ты говоришь это, совершенно не имея компетенции. Вообще, gtk основан на Имею я компетенцию, имею. Кстати, по моему мнению в Tk pack geometry manager( тот самый который эмулируется данным gtk-шным кодом) obsolete. grid - гораздо мощнее и гибче. Но в любом случае задачи динамического изменения содержания окна (скажем в зависимости от изменений в структуре базы, или от статуса пользоватлеля) GUI-билдер не решает. > понятии контейнер (первичные table, hbox, vbox, fixed_positions и пр.) Как раз > там вообще не сохраняется информации о положении виджета, присвоенного ему gui > билдером. Посмотри как-нить код, использующий gtk - там программа, создающая > диалог "Hеllo, World" c двумя кнопками Ok, Cancel имеет вид (это программа на > С++ - как С ее не скопилишь из-за коментариев и обяхвлений переменных не в > начале): И этими словами ты пытаешься доказать преимущества gtk? И ты мне предлагаешь пользоваться GUI-билдером, который даже синтаксически корректный код на всех языках поддерживаемых тулкитом сгенерить не в состоянии? > Как видишь, размер и смещение виджетов здесь не разу не было указано. > Попробуй изменить размер окна мышкой - все будет растягиваться (включая > кнопки). Присланный пример переводится на Tcl/Tk один к одному и получается раз в пять компактнее за счет необязательности указания лишних параметров и отсутствия необходимости вызова _init, создания главного окна и явного входа в цикл обработkи событий. > А из gui билдеров я использую glade - там мышкой вставляшь эти коробки друг в > друга и виджеты в них, меняешь свойства, и он генерит код (для C, С++, perl, > питона, ады, эйфеля) подобный этому. Я в последнее время склоняюсь к perl. > Не понял словосочетание "PCMCIA-схем" - каждое слово в отдельности знаю, > а вместе нет. man cardctl Это набор конфигурационных параметров, который можно переключить вручную как единое целое, например при втыкании ноутбука в другую сетку. Например, если у меня дома коаксиал, а на работе витая пара, и дома нет DHCP, я могу завести две схемы и при втыкании одной и той же сетевой карточки она поднимется либо с коаксиальным трансивером и статическим адресом, либо с трансивером TP и dhcp-клиентом, в зависимости от выбранной схемы. > всех уже запущенных приложений. Или эту адаптацию может делать > автоматически какая-либо (еще не написанная) софтина. ^ Вот, вот. И в этом основной принцип GNOME и KDE. Давайте выкинем все, что наработано с 1985 года и сделаем по своему. Неважно, что работать с этим можно будет не раньше чем через 15 лет. Зато мы круче. Поэтому кстати, и esd, а не nas. > > Из всех чисто C-шных тулкитов меня устраивал только XView. > > Ты gtk полностью не знаешь. А для gtk полно bindings для др. языков- он > специально проектировался для легкой реализации bindings. Под чисто C-шным я имею в виду "тот, с которым можно работать из чистого C" Что автоматически отсекает Qt и Fltk, и создает большой hadicap Tk. > > Проблема заключается в том, что любой видгет имеет несколько десятков > > свойств, которые иногда хочется задать. Но обычно хочется задать не более > > десятка таких свойств. > > Если ты используешь glade, то этот вопрос отпадает. Если используешь API, То есть "если ты не используешь нашу визуальную примочку, то хрен напишешь что либо полезное". Прям Borland какой-то получается. Правда, использование XML в к
remote
Hi.
Есть Debian ("server") и к нему по сети хочется подключить винду. Вопрос
доступа к серверу по telnet/ssh решается вроде бы просто, но хочется еще
иметь возможность выхода в www с виндовой машины (у сервера такой выход есть).
Что будет проще/лучше, настроить masquerading (надо ли для винды что-нибудь
особенное?), или гонять в винде Xserver(какой?) приконнектившийся к linux'у?
Спасибо,
--
Alexander Kotelnikov
Saint-Petersburg, Russia
Re: remote
On Tue, 25 Jul 2000, Alexander Kotelnikov wrote:
> From: Alexander Kotelnikov <[EMAIL PROTECTED]>
> Subject: remote
>
> Hi.
>
> Есть Debian ("server") и к нему по сети хочется подключить винду. Вопрос
> доступа к серверу по telnet/ssh решается вроде бы просто, но хочется еще
> иметь возможность выхода в www с виндовой машины (у сервера такой выход есть).
>
> Что будет проще/лучше, настроить masquerading (надо ли для винды что-нибудь
> особенное?), или гонять в винде Xserver(какой?) приконнектившийся к linux'у?
Есть еще третий вариант - поставить http прокси, например squid.
Маскарадинг - проще всего, но и меньше всего пользы приносит.
Что касается X-сервера для виндов, то после некоторой возни с Exceed и Mix
я предпочитаю наоборот делать - держать на виндах X клиента (citrix Unix
Integration Services) а монитор(ы) на машине(ах) с Linux. Правда к citrix
винды специальные нужны.
--
Victor Wagner [EMAIL PROTECTED]
Programmer Office:7-(095)-785-09-72
Communiware.Net Home: 7-(095)-135-46-61
http://www.communiware.net http://www.ice.ru/~vitus
Re: remote
On Tue, Jul 25, 2000 at 04:22:21PM +0400, Victor Wagner wrote: > > Маскарадинг - проще всего, но и меньше всего пользы приносит. Почему? > Что касается X-сервера для виндов, то после некоторой возни с Exceed и Mix > я предпочитаю наоборот делать - держать на виндах X клиента (citrix Unix > Integration Services) а монитор(ы) на машине(ах) с Linux. Правда к citrix > винды специальные нужны. А какие Винды нужны и где их взять? -- Andrey Ivaschenko nic-hdl: AI1569
Re: о кривости esd (was Re:A LSA)
On Tue, 25 Jul 2000, Aleksey Novodvorsky wrote: Добрый день, Алексей, еще раз. > Влад, добрый день! > Vlad Harchev wrote: > > > On Tue, 25 Jul 2000, Aleksey Novodvorsky wrote: > > > > > > > На мой взгляд, основная модель развития свободного софта предполагает > > > только спонсорство команд > > > фирмами, но не фирмы -- производители софта. Конечно, возможны варианты, > > > многое зависит от типа софта > > > etc., я говорю о типичном случае. > > > >Я думаю, что много чего спносировала лично Sun. > > Мне об этом не известно. Есть несколько проектов - например festival (хотя там sun была не одна). Про другие я тоже не знаю - но уверен что их будет не один десяток. > > > > > > И снова, даже здесь, Вы -- о бабках! Поверьте, это далеко не главная > > > мотивация в использовании GPL. > > > >По-моему, главная (может еще просто неосведомленность автора о других > > лицензиях или промытость мозгов всякими PR). > > Это сложно проверить, но я буду настивать на своем. Хотя бы потому, что все > мои знакомые разработчики под > GPL (их не так уж мало) ииеют совершенно другую мотивацию. Уверен, от того, что они достаточно хорошо материально обеспечены. > Не судите ли Вы, исходя из своей мотивации, распространяя ее на всех? > Хиппи и яппи всегда были и будут. Возможно. > > > > полезное/оптимальное/правильное. > > > > > > Оптимальное движение -- что это? Полезное? Вы испольуете Debian? gcc? Вам > > > они -- полезны? А полезно > > > ли движение -- сомневаетесь? Вот именно это я никак и не могу понять. > > > Плевать в колодец -- если и не > > > вредно, то некрасиво. > > > > "Оптимальность" - в плане технического совершенства софта, его > > архитектуры, > > гибкости (короче, вложения интеллектуальных усилий на этапе > > проектирования) > > - которые были бы очень кстати для тех, кто захочет включить части кода > > (или > > библиотеку) в свою gpled программу - иными словами обеспечение легкой > > утилизации кода между пусть даже free софтом. > > Ведь любую программу можно писать необдуманно, а можно написать > > библитотеку для данной проблемной области (с не очень кривым API) и потом > > юзать ее из функции main() в которую выродиться программа (я утрирую). > > Вы писали об оптимальности _движения_, на это я и среагировал. По-моему тут должно быть ясно, что движение в первую очередь порождает софт. > > > > спонсоров (не тех, > > > которые сейчас наводнили Москву), то GPL -- лучший выбор. То есть > > > действительно амбициозный проект, > > > начинающийся с нуля, _должен_ _сейчас_ быть GPL. > > > > Если придираться к словам - то что такое амбициозный проект? Это тот, > > который никогда не заврешиться, или тот, который нужен компьютерной > > индустрии? > > Ни то, ни другое. Это проект, который удовлетворит личные амбиции автора. > Свободный софт -- авторский > софт. Ученый, в большинстве случаев, удовлетворяет личные амбиции (не > материальные!). Здесь -- то же самое > или похоже. > Кто такой программист? Творец или высокооплачиваемый служащий? Каждый решает > для себя. Точно так же, как и > художник: некоторые работают только на заказ, некоторые -- только для > вечности (и для увековечивания > своего имени), некоторые -- сочетают то и другое (не всегда удачно). > Люди действительно бывают очень разные. В принципе согласен, но практика индустрии показывает, что умные (профессиональные) программисты люди основывают фирмы, пишут коммерческий софт и получают деньги. А те кто учатся новому для них API создают на нем программы и пускают под GPL. > > > > Вот sendmail, bind, wine и freetype и NAS и xfree и другие x servers, > > festival, sphinx - очень полезные проекты - они под BSD лицензией. Очень > > много > > научного софта под BSD лицензией, наверно больше чем gpled. > > Да, GPL может быть оптимальным для группы программеров-любителей, которые > > просто хотят заявить о себе и просто пописать какую-нить ерунду, или взять > > много кода из другого GPLed софта, которых никто не спонсирует. > > Ну почему Вы _так_ думаете о людях, мотивация которых Вам чужда? > Контрпримеров так много, что и гвоорить > об этом странно. Скажу о своей команде. Я _никогда_ не возьму на работу того, > кого сейчас принято называть Я сужу по качеству софта. > "профессионалом", то есть человека, который за деньги хорошо делает указанную > ему часть работы. Мне нужны > -- творцы.И -- единомышленники. А профессионализма у них не меньше. Творцы не будут писать документацию для пользователя или делать перевод каталога сообщений на русский язык. Дай Бог вам удачи в вашей деятельности. > > > > > > Вы исходите из тезисов: > > > -- доминирования собственнического софта; > > > > Этого не хочет только ленивый/глупый/очень богатый. > > В таких случаях всегда думаешь: к какой категории отнести себя? Если я -- > глупый, то Вы вряд ли стали бы > тратить время на переписку со мной (иначе попали бы в ту же категорию). > Не богатый -- это уж точно. > Ленивый? Видимо так, мог
Samba and codepages...
Не мог бы кто-нибудь ткнуть меня в доку, где описано как необходимо монтировать разделенные ресурсы с виндов, чтобы русские буквы были нормально видны... У smbmount такой параметр, похоже, отсутсвует... Спасибо, -- Миша
Re: о кривости esd (was Re:ALSA)
Влад, я думаю, что в целом наша интересная дискуссия закончена, позволю себе ответить только на несколь Ваших частных реплик. Vlad Harchev wrote: > > Вы писали об оптимальности _движения_, на это я и среагировал. > > По-моему тут должно быть ясно, что движение в первую очередь порождает софт. Нет. Софт производят программисты. Движение появляется тогда, когда есть идеология. Далеко не все члены движения ее понимают, многие трактуют неверно, но цель движения -- не создание софта, а пропаганда взглядов. > > > > > Творцы не будут писать документацию для пользователя или делать перевод > каталога сообщений на русский язык. А кто же пишет эту документацию? Тем более -- переводит? Вы думаете, что им за это -- платят? Здесь много переводчиков, спросите! Мы платим (совсем немного, увы) тем, кто переводит издаваемые нами книжки. Но, в случае Руководства по emacs, например, перевод был сделан _до_ нашего предложения и автор совсем не рассчитывал на гонорар. > > Дай Бог вам удачи в вашей деятельности. Спасибо. > > > > Все что я могу сказать - наверно люди, которые отдыхают от коммерциализиции, > достигли желаемого ими материального достатка. Ключевое слово: "желаемого ими". Но и это не всегда так. Один из авторов очень серьезной и большой работы, студент, пришел к нам абсолютно прозрачный от элементарного недоедания. Это, конечно (и слава Богу!) исключение, я просто хочу еще раз подчеркнуть, что материальные потребности далеко не у всех первичны. > > > > > > > > > -- второстепенности свободного софта; > > > > > > По причине его невысокого качества. > > > > Вы хотите сказать, что качество коммерческого софта выше? Спорить здесь > > бесполезно. > > Трактую последнее предложение как заявление что фришный софт качественнее. > Хорошо, привидите мне пример софта для рабочего места сталевара или фришный > софт для расчета давления в канализационной сети. Это не на тему. Заказной софт для частных задач был и будет. Свободный тоже, ктсати, появляется, но это, по большому счету, не его область. Равно как и игры, например. > Или софт для системы > навигации самолета boeing-747. Или высокопроизводительный проигрыватель mpeg > -video (быстрый как в винде). Или качественную систему распознавания текста. > Как видите, это специфичные области, в большинстве случаев наукоемкие. О распознавании текстов, благо я этим занимался лет двадцать назад. Весь отечественный софт этой тематики вырос из научных исследований, которые финансировались, естественно, государством. В эпоху всеобщей коммерциализации люди, владевшие знаниями, просто покупались. За копейки. Но со страшными условиями неразглашения. Сейчас мнгих уже выкинули и забыли. Это так, к слову. Конечно, такая разработка требует серьезных вложений. Будут ли они сделаны -- посмотрим. По моим сведениям вероятность этого достаточно велика. > > > > Если вы про искренность RMS - я в нее верю. Не совсем верю в теорию. Если > человек говорит искренне, то это не значит, что то, что он говорит, правильно. Несомненно. Но и я -- не о правильности его слов, а о том, что такие люди _существуют_. Спасибо за обстоятельный разговор, Влад. Надеюсь, мы вернемся к нему через некоторое время, которое нас и рассудит. Rgrds, AEN
PHP4.01pl2 и Potato
а никто не компилировал php4 под Potato? я взял исходники php4 из woody, даю debuild и получаю в ответ Unable to find required gettext library. gettext у меня стоит какую библиотеку он хочет? -- Konstantin Kubatkin KK4501-RIPE, Kherson, TriLogiC Group Fido: 2:468/[EMAIL PROTECTED]
Re: о кривости esd (was Re:A LSA)
On Tue, 25 Jul 2000, Victor Wagner wrote: > On Tue, 25 Jul 2000, Vlad Harchev wrote: > > > > > Хмм, я думал что они просто не должны были запускаться - насчет > > > > глюков я не > > > > в курсе - я их не юзаю. > > > > > > Кто не должны? acroread? Он запускается но все гиперссылки почему-то едут. > > > > Тогда я не знаю - может acroread 4 (или 3) следует попробовать? > > И тот и другой пробовал. Четвертый вообще segfault-ится. Странно. Прямо сразу при запуске или на определенной странице? Может у тебя бетта? Может есть другой бьюилд? > > > Категорически не согласен. GUI, нарисованное в gui-билдере получается > > > негибким. Оно имеет привычку разъезжаться при смене надписей на кнопках > > > или дефолтных шрифтов, но даже если это побороть, (ну например SpecTcl > > > прекрасно с этим справляетя) изменения структуры нижележащей базы данных > > > > Ты говоришь это, совершенно не имея компетенции. Вообще, gtk основан на > Имею я компетенцию, имею. > > Кстати, по моему мнению в Tk pack geometry manager( тот самый который > эмулируется данным gtk-шным кодом) obsolete. grid - гораздо мощнее и > гибче. Но в любом случае задачи динамического изменения содержания окна > (скажем в зависимости от изменений в структуре базы, или от статуса > пользоватлеля) GUI-билдер не решает. Да, но может это уже задача программера? В gtk есть table - может это тоже что и grid? > > понятии контейнер (первичные table, hbox, vbox, fixed_positions и пр.) Как > > раз > > там вообще не сохраняется информации о положении виджета, присвоенного ему > > gui > > билдером. Посмотри как-нить код, использующий gtk - там программа, создающая > > диалог "Hеllo, World" c двумя кнопками Ok, Cancel имеет вид (это программа > > на > > С++ - как С ее не скопилишь из-за коментариев и обяхвлений переменных не в > > начале): > > И этими словами ты пытаешься доказать преимущества gtk? Ты сказал, что якобы весь gui разлезется при изменении размера шрифта/темы. Этим кодом я показал, что никакие размеры/смещения не используются - gtk автоматически располагает виджеты с учетом мин. размера нужного им. > И ты мне предлагаешь пользоваться GUI-билдером, который даже синтаксически > корректный код на всех языках поддерживаемых тулкитом сгенерить не в > состоянии? На для какого языка он генерит синтаксически неправильный код? Для python? Или ты подумал, что кусок кода был сделан на билдере? Нет, тот кусок кода я ручками навскидку написал. > > > Как видишь, размер и смещение виджетов здесь не разу не было указано. > > Попробуй изменить размер окна мышкой - все будет растягиваться (включая > > кнопки). > > Присланный пример переводится на Tcl/Tk один к одному и получается > раз в пять компактнее за счет необязательности указания лишних параметров > и отсутствия необходимости вызова _init, создания главного окна и явного > входа в цикл обработkи событий. То ж Tk, а это C. На perlGtk код можно использовать вот такой код (он строит окно с кнопкой внутри): $window = new Gtk::Widget "GtkWindow", GtkWindow::type => -toplevel, GtkWindow::title=> "hello world", GtkWindow::allow_grow => 0, GtkWindow::allow_shrink => 0, GtkContainer::border_width => 10; $button = new_child $window "GtkButton", GtkButton::label=> "hello world", GtkObject::signal::clicked => "hello", GtkWidget::visible => 1; Немного похоже на Tk.. > > А из gui билдеров я использую glade - там мышкой вставляшь эти коробки > > друг в > > друга и виджеты в них, меняешь свойства, и он генерит код (для C, С++, perl, > > питона, ады, эйфеля) подобный этому. Я в последнее время склоняюсь к perl. > > > > Не понял словосочетание "PCMCIA-схем" - каждое слово в отдельности знаю, > > а вместе нет. > > man cardctl > > Это набор конфигурационных параметров, который можно переключить вручную > как единое целое, например при втыкании ноутбука в другую сетку. > Например, если у меня дома коаксиал, а на работе витая пара, и дома нет > DHCP, я могу завести две схемы и при втыкании одной и той же сетевой > карточки она поднимется либо с коаксиальным трансивером и статическим > адресом, либо с трансивером TP и dhcp-клиентом, в зависимости от выбранной > схемы. Хитро. > > > всех уже запущенных приложений. Или эту адаптацию может делать > > автоматически какая-либо (еще не написанная) софтина. > ^ > Вот, вот. И в этом основной принцип GNOME и KDE. Давайте выкинем все, > что наработано с 1985 года и сделаем по своему. Неважно, что работать с > этим можно будет не раньше чем через 15 лет. Зато мы круче. > > Поэтому кстати, и esd, а не nas. Возможно. > > > > Из всех чисто C-шных тулкитов меня устраивал только XView. > > > > Ты gtk полностью не знаешь. А дл
Re: о кривости esd (was Re:A LSA)
On Tue, 25 Jul 2000, Aleksey Novodvorsky wrote: > Влад, я думаю, что в целом наша интересная дискуссия закончена, позволю себе > ответить только на несколь Ваших > частных реплик. Да, дискуссия была интересной. > Vlad Harchev wrote: > > > > Вы писали об оптимальности _движения_, на это я и среагировал. > > > > По-моему тут должно быть ясно, что движение в первую очередь порождает > > софт. > > Нет. Софт производят программисты. Движение появляется тогда, когда есть > идеология. Далеко не все члены > движения ее понимают, многие трактуют неверно, но цель движения -- не > создание софта, а пропаганда взглядов. ..пропаганда взглядов на создание софта. Ну да ладно. > > > > > > > > > > Творцы не будут писать документацию для пользователя или делать перевод > > каталога сообщений на русский язык. > > А кто же пишет эту документацию? Тем более -- переводит? Вы думаете, что им > за это -- платят? Здесь много > переводчиков, спросите! Мы платим (совсем немного, увы) тем, кто переводит > издаваемые нами книжки. Но, в случае > Руководства по emacs, например, перевод был сделан _до_ нашего предложения и > автор совсем не рассчитывал на > гонорар. Большое им за это спасибо.. > > > > > > > > > -- второстепенности свободного софта; > > > > > > > > По причине его невысокого качества. > > > > > > Вы хотите сказать, что качество коммерческого софта выше? Спорить здесь > > > бесполезно. > > > > Трактую последнее предложение как заявление что фришный софт качественнее. > > Хорошо, привидите мне пример софта для рабочего места сталевара или > > фришный > > софт для расчета давления в канализационной сети. > > Это не на тему. Заказной софт для частных задач был и будет. Свободный тоже, > ктсати, появляется, но это, по > большому счету, не его область. Равно как и игры, например. А по-сему деланье GPLed библиотек, только для того, чтобы коммерческий софт, в котором хотят их использовать, стал gpled - утопия. > > Или софт для системы > > навигации самолета boeing-747. Или высокопроизводительный проигрыватель mpeg > > -video (быстрый как в винде). Или качественную систему распознавания текста. > > Как видите, это специфичные области, в большинстве случаев наукоемкие. > > О распознавании текстов, благо я этим занимался лет двадцать назад. Весь > отечественный софт этой тематики вырос > из научных исследований, которые финансировались, естественно, государством. > В эпоху всеобщей коммерциализации > люди, владевшие знаниями, просто покупались. За копейки. Но со страшными > условиями неразглашения. Сейчас мнгих > уже выкинули и забыли. Это так, к слову. Конечно, такая разработка требует > серьезных вложений. Будут ли они > сделаны -- посмотрим. По моим сведениям вероятность этого достаточно велика. Не знаю. Тут надо на уровне министерств разговаривать - заинтересовать их в gpled софте. > > Если вы про искренность RMS - я в нее верю. Не совсем верю в теорию. Если > > человек говорит искренне, то это не значит, что то, что он говорит, > > правильно. > > Несомненно. Но и я -- не о правильности его слов, а о том, что такие люди > _существуют_. Для Запада это не удивительно. > > Спасибо за обстоятельный разговор, Влад. Надеюсь, мы вернемся к нему через > некоторое время, которое нас и > рассудит. Спасибо и Вам, Алексей, за этот разговор и много интересной информации об iplabs. Сам хотел бы надеятся, что фришный софт будет доминировать. Но боюсь он будет низкого качества. > Rgrds, AEN > Удачи. Best regards, -Vlad
Re: о кривости esd (was Re:A LSA)
On Tue, 25 Jul 2000, Vlad Harchev wrote: > > > > > > Тогда я не знаю - может acroread 4 (или 3) следует попробовать? > > > > И тот и другой пробовал. Четвертый вообще segfault-ится. > > Странно. Прямо сразу при запуске или на определенной странице? Может у тебя > бетта? Может есть другой бьюилд? Третий - из slink, четвертый из Corel WP Office. И у Netscape все иконки в toolbar-е черно-белые были, что характерно это _известный_ глюк. > > эмулируется данным gtk-шным кодом) obsolete. grid - гораздо мощнее и > > гибче. Но в любом случае задачи динамического изменения содержания окна > > (скажем в зависимости от изменений в структуре базы, или от статуса > > пользоватлеля) GUI-билдер не решает. > > Да, но может это уже задача программера? В gtk есть table - может это тоже Да, несомненно это задача программера. А задача инструмента - помочь ему это сделать. В этом плане инструменты где переход от ручного создания GUI к программному прост и естественен и решается путем добавления парочки циклов - rules. > что и grid? На первый взгляд - похоже. Но по-моему Tk grid гибче. > > И ты мне предлагаешь пользоваться GUI-билдером, который даже синтаксически > > корректный код на всех языках поддерживаемых тулкитом сгенерить не в > > состоянии? Для C. > > На для какого языка он генерит синтаксически неправильный код? Для python? > Или ты подумал, что кусок кода был сделан на билдере? Нет, тот кусок кода я > ручками навскидку написал. Да, естественно. Мне и в голову не придет, что пишучи ручками C-шный код (т.е не содержащий ни одного места где _содержательно_ используются references, объекты, наследование) человек будет его делать несовместимым с компилятором C. > > Присланный пример переводится на Tcl/Tk один к одному и получается > > раз в пять компактнее за счет необязательности указания лишних параметров > > и отсутствия необходимости вызова _init, создания главного окна и явного > > входа в цикл обработkи событий. > > То ж Tk, а это C. На perlGtk код можно использовать вот такой код (он Тк это библиотека. Она бывает и в C. > строит окно с кнопкой внутри): > $window = new Gtk::Widget "GtkWindow", > GtkWindow::type => -toplevel, > GtkWindow::title=> "hello world", > GtkWindow::allow_grow => 0, > GtkWindow::allow_shrink => 0, > GtkContainer::border_width => 10; Особенно греют идентификаторы на полстроки. > $button = new_child $window "GtkButton", > GtkButton::label=> "hello world", > GtkObject::signal::clicked => "hello", ^ А это что? Не symbolic reference часом? > > То есть "если ты не используешь нашу визуальную примочку, то хрен > > напишешь что либо полезное". Прям Borland какой-то получается. > > Никто не заставляет его использовать. Но тот-же диалог на Tk на С писать > примерно также геморойно, как и используя gtk с С. Зато можно писать, используя _вербальные_ примочки - Python, Tcl, Scheme. Человек все же отличает от обезьяны умение выражать свои мысли словами, а тыкать пальцем обезьяна не хуже нас умеет. > > Правда, использование XML в качестве языка описания GUI это слегка > > компенсирует. Но все равно XML это не скриптовый язык. > > Зато можно cut-n-paste этого xml можно делать для быстрого редактирования > диалогов. cut-n-paste можно и C-шному коду делать. А Tcl-ный - так вообще генерить по ходу дела самим же скриптом. Я как-то писал програму на тикле, которая читала конфигурационный файл (на самом деле делала ему eval, предварительно определив все ключевые слова конфига как процедуры), и в процессе выполнения генерила еще одну программу на тикле, которая в процессе выполнения генерила программу на php. Сей процесс был мною торжественно обозван программированием высоких порядков. > Тебе просто разбираться с билдером и gtk лениво. Лучше потратить время на > изучение билдера, чем ручками все делать. Лучше найти себе средство которое будет за тебя все делать. Наилучшим известным мне средством такого рода для генерации текстов (все равно, программ, TeX-овских исходников, таблиц, HTML) являются скриптовые языки. -- Victor Wagner [EMAIL PROTECTED] Programmer Office:7-(095)-785-09-72 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: о кривости esd (was Re:A LSA)
On Tue, 25 Jul 2000, Victor Wagner wrote: > On Tue, 25 Jul 2000, Vlad Harchev wrote: > > > > > > > > > Тогда я не знаю - может acroread 4 (или 3) следует попробовать? > > > > > > И тот и другой пробовал. Четвертый вообще segfault-ится. > > > > Странно. Прямо сразу при запуске или на определенной странице? Может у тебя > > бетта? Может есть другой бьюилд? > > Третий - из slink, четвертый из Corel WP Office. > > И у Netscape все иконки в toolbar-е черно-белые были, что характерно > это _известный_ глюк. Да, блин. Вот тебе и Motif. Ничем помочь не могу. Но все-таки, может есть новые бьюилды acoread? Я бы на твоем месте поискал. > > > эмулируется данным gtk-шным кодом) obsolete. grid - гораздо мощнее и > > > гибче. Но в любом случае задачи динамического изменения содержания окна > > > (скажем в зависимости от изменений в структуре базы, или от статуса > > > пользоватлеля) GUI-билдер не решает. > > > > Да, но может это уже задача программера? В gtk есть table - может это тоже > > Да, несомненно это задача программера. А задача инструмента - помочь ему > это сделать. В этом плане инструменты где переход от > ручного создания GUI к программному прост и естественен и решается путем > добавления парочки циклов - rules. > > > что и grid? > > На первый взгляд - похоже. > Но по-моему Tk grid гибче. > > > > И ты мне предлагаешь пользоваться GUI-билдером, который даже синтаксически > > > корректный код на всех языках поддерживаемых тулкитом сгенерить не в > > > состоянии? > > Для C. > > > > > На для какого языка он генерит синтаксически неправильный код? Для python? > > Или ты подумал, что кусок кода был сделан на билдере? Нет, тот кусок кода > > я > > ручками навскидку написал. > > Да, естественно. Мне и в голову не придет, что пишучи ручками C-шный > код (т.е не содержащий ни одного места где _содержательно_ используются > references, объекты, наследование) человек будет его делать несовместимым > с компилятором C. А меня ломало об[являть все переменные перед выражениями. Я тоже человек. > > > Присланный пример переводится на Tcl/Tk один к одному и получается > > > раз в пять компактнее за счет необязательности указания лишних параметров > > > и отсутствия необходимости вызова _init, создания главного окна и явного > > > входа в цикл обработkи событий. > > > > То ж Tk, а это C. На perlGtk код можно использовать вот такой код (он > > Тк это библиотека. Она бывает и в C. Имел в виду Tcl а не Tk, sorry. > > > строит окно с кнопкой внутри): > > $window = new Gtk::Widget "GtkWindow", > > GtkWindow::type => -toplevel, > > GtkWindow::title=> "hello world", > > GtkWindow::allow_grow => 0, > > GtkWindow::allow_shrink => 0, > > GtkContainer::border_width => 10; > > Особенно греют идентификаторы на полстроки. Вообще-то можно без них. Что-то я глючу.. > > $button = new_child $window "GtkButton", > > GtkButton::label=> "hello world", > > GtkObject::signal::clicked => "hello", >^ > А это что? Не symbolic reference часом? Она. Я опять не весь код привел. Это callback был. > > > То есть "если ты не используешь нашу визуальную примочку, то хрен > > > напишешь что либо полезное". Прям Borland какой-то получается. > > > > Никто не заставляет его использовать. Но тот-же диалог на Tk на С писать > > примерно также геморойно, как и используя gtk с С. > > Зато можно писать, используя _вербальные_ примочки - Python, Tcl, Scheme. Кстати для scheme тоже bindings есть (repgtk?). > Человек все же отличает от обезьяны умение выражать свои мысли словами, > а тыкать пальцем обезьяна не хуже нас умеет. Согласен. Я просто хотел сказать, что Tk при использовании из C как минимум не намного менее гемороен чем gtk. > > > Правда, использование XML в качестве языка описания GUI это слегка > > > компенсирует. Но все равно XML это не скриптовый язык. > > > > Зато можно cut-n-paste этого xml можно делать для быстрого редактирования > > диалогов. > > > cut-n-paste можно и C-шному коду делать. А Tcl-ный - так вообще генерить > по ходу дела самим же скриптом. Я как-то писал програму на тикле, > которая читала конфигурационный файл (на самом деле делала ему eval, > предварительно определив все ключевые слова конфига как процедуры), > и в процессе выполнения генерила еще одну программу на тикле, которая > в процессе выполнения генерила программу на php. Согласен - скриптовые языки это всегда приятно. gtk из перла тоже приятно использовать (везде eval есть, однако). > > Сей процесс был мною торжественно обозван программированием высоких > порядков. > > > > Тебе просто разбираться с билдером и gtk лениво. Лучше потратить время на > > изучение билдера, чем ручками все делать. > > Лу
Re: Еще кое-что нарыл в POTATO
On Tue, 25 Jul 2000, Peter Novodvorsky wrote:
PN>++ 25/07/00 01:27 +0900 - Fedor Zuev:
PN>>
PN>>В Debian собственный доморощенный man
PN>> (man-db). Соответственно groff вызывается с разными опциями.
PN>> У меня (из Woody)
PN>>groff 1.15.3-2
PN>>man-db 2.3.17-1
PN>> псевдографики вместо переносов нет, потому что нет переносов вообще.
PN>> При запуске
PN>> gzip -d > псевдографика, правда, появляется.
PN>>
PN>> (кстати, эти версии еще русские маны правильно показывают
PN>> (добавили -Tascii8), так что советую обновить)
PN>groff: 1.15.3-2
PN>man-db: 2.3.17-1
PN>Русского вообще не показывает.
PN>Может кто подскажет?
Единственное, что в голову приходит: а переменные окружения
(LC_*, LANG) правильно выставлены? И русский ман в правильный
каталог положен (должен быть $MANPATH/$LANG, т.е /usr/share/man/ru)?
Там внутрях (man.c) такая табличка есть
struct lt {
char * lang;
char * device;
char * charset;
} lang_table[] ={
/* LESSCHARSET=latin1 means '0x80-0xff is displayable'. */
/* It does not mean 'ISO-8859-1 charset'.*/
/* roff_device=latin1 means 'groff uses ISO-8859-1 characters'. */
/* Thus 'ascii' should be used for ISO-8859-{2,3,4,...}languages.*/
/* LANG means language of manpage. However,for English manpages,*/
/* roff_device and LESSCHARSET are determined by user environment*/
/* (latin1+latin1 for ISO-8859-1 languages and ascii+ascii for */
/* non-ISO-8859-1 languages). */
/* LANG roff_device LESSCHARSET */
{ "da" , "latin1" , "latin1" }, /* Danish */
{ "de" , "latin1" , "latin1" }, /* German */
{ "en" , "latin1" , "-" }, /*English */
{ "es" , "latin1" , "latin1" }, /*Spanish */
{ "fi" , "latin1" , "latin1" }, /*Finnish */
{ "fr" , "latin1" , "latin1" }, /* French */
{ "ga" , "latin1" , "latin1" }, /* Irish */
{ "is" , "latin1" , "latin1" }, /*Icelandic */
{ "it" , "latin1" , "latin1" }, /*Italian */
{ "ja" , "nippon" , "ja" }, /*Japanese */
{ "ko" , "nippon" , "latin1" }, /* Korean*/
{ "nl" , "latin1" , "latin1" }, /* Dutch*/
{ "no" , "latin1" , "latin1" }, /*Norwegian */
{ "pt" , "latin1" , "latin1" }, /*Portuguese */
{ "sv" , "latin1" , "latin1" }, /*Swedish */
{ "*" , "ascii8" , "latin1" }, /*universal */
{ 0 , 0 , 0 } };
---
но при этом трактует он эту табличку весьма своеобразно, делая
различие между стандартными manpages в .../man/man[1-9] и
"национальными" страничками в .../man/$LANG/man[1-9] . В первом
случае, если языка нету в списке, жестко задается ascii (и любые
нелатинские символы идут лесом), во втором - устройство берется из
строчки с "*".
Кстати, обратите внимание на то, что в этой строчке указано
устройство ascii8. Это дебиановский патч к groff, вот что про него
написано в ChangeLog
---
* Applyed patch submitted by Tomohiro KUBOTA:
* Added a new device type 'ascii8', which is 8 bit clean (like
latin1) but does not use Latin-1 character for hyphenation and so
on(like ascii). This device is intended to be used for codesets
other than ASCII and ISO-8859-1. This device should be temporal
till all charsets (ISO-8859-*, KOI8-R, EUC-KR, EUC-ZH, TIS620, and
so on so on) in the world are implemented, though this is almost
impossible.
* Added a new character 'sy', which is soft hyphen. This character
is defined only for latin1 device. This 'sy' is used for
hyphenation instead of [char173], because [char173] may not be a
soft hyphen, though [char173] is a soft hyphen in ISO-8859-1.
Tomohiro KUBOTA <[EMAIL PROTECTED]> Wed, 19 Apr 200023:47:18 +0900
+This closes: #62840.
---
Re: Еще кое-что нарыл в POTATO (ответы многи м)
Я в принципе очень давно собирался этим заняться, но просто не было особой нужды... Дмитрий <[EMAIL PROTECTED]> >Далее. Кто возьмется сделать devkoi8-r? > >С уважением, Виктор
Re: remote
>Что касается X-сервера для виндов, то после некоторой возни с Exceed и Mix >я предпочитаю наоборот делать - держать на виндах X клиента (citrix Unix >Integration Services) а монитор(ы) на машине(ах) с Linux. Правда к citrix >винды специальные нужны. Повозись еще с X-Win32. Я им пользуюсь с удовольствием, несмотря на его ограничение (для триальной версии) в 2 часа непрерывной работы. По крайней мере у меня не было с ним проблем в плане отображения русских букв и цветовой палитры как в icewm так и в fvwm2 И размеры его ГОРАЗДО меньше того же Exceed Единственная трабла с вводом русских букв, но говорят, что она легко решается (сам не пробовал) запуском xrus. С уважением, Виктор
Re: Samba and codepages...
>Не мог бы кто-нибудь ткнуть меня в доку, где описано как необходимо монтировать >разделенные ресурсы с виндов, чтобы русские буквы были нормально видны... У >smbmount такой параметр, похоже, отсутсвует... Дык вроде недавно я этот вопрос подымал. Нужен специальный патч к ядру, чтобы была возможность указывать кодировку два раза: на стороне сервера и на стророне клиента С уважением, Виктор
Re: remote
"Victor Vislobokov" <[EMAIL PROTECTED]> writes: > >винды специальные нужны. > Повозись еще с X-Win32. Я им пользуюсь с удовольствием, несмотря на > Единственная трабла с вводом русских букв, но говорят, что она легко > решается (сам не пробовал) запуском xrus. Да нет там накаких траблов :) Вот же пишу по русски :) Единственное, что не работает X Selection -> Windows clipboard и то IMHO только под NT. PS: Мало того, X-Win32 в утиле имеет приличный клавиатурный редактор.
