Re: о кривости esd (was Re:ALSA)
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 vitus@ice.ru
Programmer Office:7-(095)-785-09-72
Communiware.Net Home: 7-(095)-135-46-61
http://www.communiware.net http://www.ice.ru/~vitus
Reply to: