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 в качестве языка описания GUI это слегка компенсирует. Но все равно XML это не скриптовый язык. > то свойства все свойства виджета для конструктора не указываются. Эти > свойства > (если не устраивают дефолтные значения) меняют с помощью доп. ф-й. Что еше хуже. Поскольку вместо одной строчки - вызова конструктора, тебе потребуется десять. > > > Xview и Tk позволяют в одном вызове конструктора видгета указать ровно > > те свойства, которые тебе нужны, а остальные получат некоторые дефолтные > > значения (заметим, зависящие от текущих значений ресурсов) сами. > > > > В gtk с этим гораздо сложнее. > > Ты в нем не разобрался. Разобрался настолько, чтобы понять, что мне лениво писать на нем без билдеров, а билдеров я не перевариваю, считая что они, как и любые костыли, только мешают ходить. > > > Производителям коммерческого софта хочется использовать компилируемые > > > языки > > > > В данном случае (хотя в этом же треде я яростно отстаивал их интересы > > против АЕН) - на них плевать. У них есть Motif, пускай пишут на нем. > > > На мой взгляд, самым вредным в GNOME и KDE является принцип "все программы > > должны использовать только наш тулкит". > > Ну, не очень уж это и вредит. Это их проблемы и их время - пускай делают что > хотят. Это и наши проблемы, постольку поскольку появляются программы, которые были бы полезными, если бы могли нормально жить в среде XWindow в отрыве от всяких KDE и GNOME, на которые откровенно жалко ресурсов. -- 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