Re: о кривости esd (was Re:ALSA)
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 <gtk/gtk.h>
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_BOX(vb),hb,1,1,0);//вставили гор. коробку в
//вертикальную
gtk_container_add(GTK_CONTAINER(wnd),vb);//вставили верт. коробку в окно
gtk_widget_show_all(wnd);//показали окно - пользователь может с ним работать
gtk_main();//запустили main loop
}
Как видишь, размер и смещение виджетов здесь не разу не было указано.
Попробуй изменить размер окна мышкой - все будет растягиваться (включая
кнопки).
А из gui билдеров я использую glade - там мышкой вставляшь эти коробки друг в
друга и виджеты в них, меняешь свойства, и он генерит код (для C, С++, perl,
питона, ады, эйфеля) подобный этому. Я в последнее время склоняюсь к perl.
Есть еще libglade - которая из xml файла созданного glade на лету генерит
gui (используя dlsym() для нахождения обработчиков сигналов) - то есть
пользователь может отредактировать gui (типа поменять местами кнопки,
отредактировать акселераторы, указать кнопку по умолчанию и еще чего-нить) и
использовать этот gui.
> оно не переживает. А gui генереруемое циклом в скрипте гораздо легче
> относится к подобным вещам,
>
> > окно типа "hello, world") во вторых, для тех десяти строк (если они не
> > связаны
>
> Я по-моему пытался что-то мелкое и полезное написать, типа интерактивного
> редактора PCMCIA-схем.
Не понял словосочетание "PCMCIA-схем" - каждое слово в отдельности знаю,
а вместе нет.
> > с конструированием gui, а с заполнением widget'ов данными и обработкой событий)
>
> Естественно, с конструированием GUI. Потому что GUI надо конструировать
> runtime, сообразуясь с текущим разрешением экрана, количеством цветов,
> заданными пользователем предпочтениями в области цветов и шрифтов и др.
> Механизм тем для этого недостаточен. А вот механизм .Xresources при
> правильном использовании (с учетом вызовов препроцессора в xrdb) -
> достаточен.
Вообще каждому виджету в интерфейсе можно дать имя. Потом в gtkrc можно
назначить свой собственный внешний вид и клавиатурные комбинации для него
(используя patterns как в .Xresources). Естественно, можно заставить
данную софтину грузить совершенно другую тему (но для этого должна быть поддержка со
стороны софта - через опцию коммандной строки - я предлагал ввести поддержку
этого в gtk_init(int argc, char** argv) который уже обрабатывает display и
всякую прочую фигню - но они молчат).
Насчет адаптации к цвету и пр. - пользователь может изменить тему на лету для
всех уже запущенных приложений. Или эту адаптацию может делать
автоматически какая-либо (еще не написанная) софтина.
Насчет Xresources - да, что-то подобное хотелось бы иметь для изменения
_поведения_ (кроме shortcuts & appearance) виджетов через gtkrc. Наверно
просто люди не захотели жертвовать производительностью (хотя ее и так нет)
- но это еще можно дописать потом.
> > можно сделать одну функцию и юзать ее потом.
>
> Одну нельзя. Для каждого диалогового окна придется немножко свою.
> Либо эта одна будет занимать не 10 строк а 200 и состоять преимущественно
> из проверок разных условий.
Используй glade. Она будет генерить гуй когда ты вызовешь
create_<windowname> - а потом ты сможешь добавить в созданный диалог то, что
тебе надо (виджеты и их содержимое).
> > Ну и еще - может ты просто не знал gtk и поэтому писал не эффективно.
>
> Я не то чтобы не знал gtk. Я не перевариваю такую идеологию
> программирования GUI.
> Из всех чисто C-шных тулкитов меня устраивал только XView.
Ты gtk полностью не знаешь. А для gtk полно bindings для др. языков- он
специально проектировался для легкой реализации bindings.
> Проблема заключается в том, что любой видгет имеет несколько десятков
> свойств, которые иногда хочется задать. Но обычно хочется задать не более
> десятка таких свойств.
Если ты используешь glade, то этот вопрос отпадает. Если используешь API,
то свойства все свойства виджета для конструктора не указываются. Эти свойства
(если не устраивают дефолтные значения) меняют с помощью доп. ф-й.
> Xview и Tk позволяют в одном вызове конструктора видгета указать ровно
> те свойства, которые тебе нужны, а остальные получат некоторые дефолтные
> значения (заметим, зависящие от текущих значений ресурсов) сами.
>
> В gtk с этим гораздо сложнее.
Ты в нем не разобрался.
> > Производителям коммерческого софта хочется использовать компилируемые языки
>
> В данном случае (хотя в этом же треде я яростно отстаивал их интересы
> против АЕН) - на них плевать. У них есть Motif, пускай пишут на нем.
> На мой взгляд, самым вредным в GNOME и KDE является принцип "все программы
> должны использовать только наш тулкит".
Ну, не очень уж это и вредит. Это их проблемы и их время - пускай делают что
хотят.
> Или пусть как честные ежики пишут не приложения, а компоненты, возможно
> сопровождая (открытыми и документированными) интерфейсными скриптами
В принципе, когда весь код открыт это не настолько важно покуда код
программы не больше 500K, а таковых - 98%. А всякие Gnome и KDE как раз и
проповедуют компоненты для оффисного софта.
> Пока не придумано универсального эквивалента IO Redirection для GUI
> (линзы pad++ все-таки не выход) интерфейс приходится отрывать от
> функциональности насильтственно, чтобы между юзером и программой можно
> было всегда другую программу вставить.
Ну, компоненты эту проблемму частично решают. А еще открытие исходного кода
для интерфейсной части может помочь.
>[...]
Best regards,
-Vlad
Reply to: