Hello Stanislav,

On Tue, Jan 15, 2002 at 07:54:36PM +0300, Stanislav Ievlev wrote:
>
> Yury Umanets wrote:
> 
> >Stanislav Ievlev wrote:
> >
> >>Привет!
> >>
> >>Теперь я посмотрел инсталлятор несколько более подробнее:
> >>Вот возникло несколько мыслей:
> >>
> >>1) Архитектура очень интересная, особенно касательно плагинов 
> >
> >
> >
> >>
> >>2) Но вот на примере плагина welcome - как я понял графика там жестко 
> >>прошита. То есть хотелось бы такой же
> >
> >
> >Пока да, но это не недостаток архитектуры. Это мой недосмотр. Это как 
> >раз то о чем говорил Жуков. То есть инициализания самого плугина будет 
> >отдельно от инициализации самого плугина.
> 
> ???
> 
> Может быть в описании каждого плугина два символа :
> init_as_text
> init_as_gui

Лучше иметь глобальную корзину с параметрами, в которой и
устанавливать выбранный frontend, уровень вдумчивости настроек и т.п.

> >Вы это имели ввиду? Или вы говорите о том, что было бы неплохо весь 
> >внешний вид описать в xml? Тогда лучше уж заюзать мозильное ядро и 
> >сделать инсталяху на html :))

Mozilla, конечно, перебор. Но насчет XML стоит подумать. В случае
инсталлятора у нас имеется ограниченный набор управляющих элементов --
статический текст, поля ввода, списки, галки, максимум --
деревья. Несложный набор layout'ных примитивов, хватит одной таблицы
либо даже вертикальных/горизонтальных разбиений. Или даже только
вертикальных отбивок в стиле <hr>.
Для GTK эти описания теоретически можно транслировать в glade с
помощью XSLT. Для ncurses -- придется исхитряться.

> >
> >>легкости ив переключении с тектового на графический интерфейс. Это 
> >>понятно сложнее, да и сделать виджеты одинаково для обоих режимов 
> >>очень тяжело, но иначе надо как я понял писать две версии интерфейса 
> >>для каждого модуля (см. п. 7) 
> >
> >
> >Постараемся избежать, но довольно трудно. Кроме того интерфейс это не 
> >очень большая часть. 
> 
> Да, тяжело, посмотрите что мне пришлось накручивать ;))
> 
> >
> >
> >>
> >>3) Не совсем я также разобрался зачем нужен extraseg. Я если честно 
> >>опасаюсь нестандартностей 
> >
> >
> >Он нужен для того, чтобы получить один бинарник и не париться с тем 
> >куда положить модули, где их программа должна искать и т.д. Ну это 
> >такая тяга к компактности. Записал на дискетку бинарник и все :))
> >
> >А на счет нестандартности, так вроде все нормально. Добавили мы одну 
> >секцию в elf ну и что? Это позволительно. Компилятор вон их сколько 
> >пихает для всякой чепухи :) В остальном - нормальный lds скрипт, для 
> >elf32-x86.
> >Мы ж можем проверять архитектуру и пихать нужный скрипт. В конце 
> >концов можно от него отказаться. Его вполне можно заменить dlopen-ом 
> >на свой бинарник, но из-за этого инсталяшка линкуется на libdl, что 
> >при статической линковке не дает экономию в несколько десятков килобайт.
> >
> >Кроме всего прочего можно эту "фичу" вообще не использовать, если 
> >смущает. А можно использовать для чего-нибудь миниатюрного.
> 
> Я как понял это замена символов. Может кстати это позволит лучше 
> застрипать плагины.
> 
> >
> >>
> >>4) Мне показалось, что слишком сильная привязка на gtk. Но может я не 
> >>прав. 
> >
> >
> >Согласен.
> >
> >Когда я уберу зависимость GUI от кода плугинов зависимость на gtk 
> >уменьшится. Ну а вообще, нужно ж на что-то завязываться. Нужно 
> >подумать, как завязаться по минимуму 
> 
> 
> >
> >
> >>
> >>5) Инсталлятор будет постоянно усложняться. Может лучше его написать 
> >>на C++? Современные инсталляторы от MDK и RH это многие килограммы 
> >>кода в которых разбираться не очень просто. 
> >
> >
> >Писал на C по нескольким причинам.
> >1. Инициализация быстрее.
> >2. Компиляция быстрее (несущественно)
> >3. был выбран gtk по причине легкости и GPL-ности
> >4. gtk-шная c++-ная реинкарнация не поспевает за c-шной 

Насколько я в курсе, за стабильной -- поспевает.

> Мне кажется это вообще изврат - эмуляция C++ через C ;)

Зато ABI libgtk+.so не зависит от версии компилятора, флагов и т.п.
Объектно-ориентированное программирование не обязательно требует
объектно-ориентированного языка :)

> 
> >
> >5. многие считают с++ не совсем подходящим языком для таких задач 
> >(несуущественно) 
> 
> C++ идеален для больших проектов (как инсталлятор+конфигуратор).  Gnome 
> наглядный пример что приходится накручивать для эмуляции возможностей C++.
> Прикрутить обычный gtk к C++ это не проблема.
> 
> Можно оставить С на двух первых стадиях, а самую интеллектуальную часть 
> сделать на C++.

Тогда лучше был бы Python. И проще, и красивее, и с потенциальными
frontend'ами интегрируется. Даже не сильно накладно могло бы
получиться, особенно если скомпилировать в .pyo и выкинуть исходники.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Going to church does not make a person religious, nor does going to school
make a person educated, any more than going to a garage makes a person a car.