[devel] Torque Installer - первый взгляд

[Yury Umanets]

Stanislav Ievlev wrote:

> Привет!
>
> Теперь я посмотрел инсталлятор несколько более подробнее:
> Вот возникло несколько мыслей:
>
> 1) Архитектура очень интересная, особенно касательно плагинов 


>
> 2) Но вот на примере плагина welcome - как я понял графика там жестко 
> прошита. То есть хотелось бы такой же

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

> легкости ив переключении с тектового на графический интерфейс. Это 
> понятно сложнее, да и сделать виджеты одинаково для обоих режимов 
> очень тяжело, но иначе надо как я понял писать две версии интерфейса 
> для каждого модуля (см. п. 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-шной
5. многие считают с++ не совсем подходящим языком для таких задач 
(несуущественно)

>
> 6)  Есть ли какие идеи по поводу устройства загрузочной дискеты? 

Этим занимает Жуков. мы с ним прорабатывали эти моменты некоторое время 
назад. У него есть опыт, да и не только. На сколько я понял, он это взял 
на себя полностью. У него не просто идеи, у него уже есть рабочий 
вариант. На сколько я знаю, он использует busybox.  Уточните у него 
пожалуйста.

>
>
>
> Повторю, что это был первый взгляд, возможно ошибочный.
>
> 7) Предлагаю посмотреть мои идеи по поводу конфигуратора (там внутри 
> есть маленькая документация)
>       http://linux.ru.net/~inger/Config-Dialog-b6.tar.bz2 

Обязательно посмотрю.

>
> Возможно они пригодятся или их как-то можно будет интегрировать в 
> инсталлятор.

Посмотрим. Может какую идею сворую :))

>
> К сожалению у меня все написано на C++, но с другой стороны можно 
> легко портировать на gtk (сейчас qt и newt). 

:)) c++ не проблема.

>
Принципиальные возражения есть? Например Вы принципиально против gtk?

>
>
>
> _______________________________________________
> Devel mailing list
> Devel на altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel



-- 
Yury Umanets,
ALT Linux Team