Программа ДистроНавигатор Опции Поделиться

[ИВК]

Программа DistroNavigator - графический интерфейс для сборки альтовских дистрибутивов. Альфа-версия.

Навигатор для дебрей альтовского дистростроя Рассчитан прежде всего на новичков в создании собственных дистрибутивов. Работает с m-p-d и m-p (но поддержка m-p-d полнее и надёжнее). Можно создавать собственные брендинги и собирать дистрибутивы с ними.
Подробности насчёт использования программы - во встроенной в неё справке.

Пакет distronavigator устанавливается посредством apt-get , если подключен клубный репозиторий (p8 или p9).
Запуск из меню (категория "Разработка") или из консоли командой distronavigator

всё вышесказанное актуально на данный момент; в случае любых изменений эта информация будет приведена в соответствие с ними.

----------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------

Собрался всё-таки довести до ума gui для Mkimage-profiles. Напомню, что у меня уже есть gui для m-p/m-p-d, но кое-как сляпанные и привязанные к моим сборкам. На сей раз собираюсь сделать уже нормальную мордочку для m-p, с помощью которой можно было бы в любом альтовском дистре собирать любой альтовский дистр. Без помощи создателей m-p тут точно не обойтись
Сейчас прога выглядит так :  mpgui.tar.gz ( 457.86 килобайт ) Кол-во скачиваний: 11

Пишется она на Питоне (для запуска должны быть установлены пакеты python-modules-tkinter и python-module-imaging). Ей требуются, естественно, сам m-p, исходники брендинга и несколько программ - но запустить её для проверки можно и без этого.
Как в целом всё должно выглядеть - отчасти видно по секции "Брендинг", потому что она единственная более-менее готовая При установленных исходниках брендинга и другом вызываемом из той секции софте (а в моих сборках это есть "из коробки", и не так уж сложно организовать это и в других дистрах) там всё работает.
А вот за кнопками "Состав сборки", "Настройка" и "Запуск" - пустота, потому что там всё было пристёгнуто к моим сборкам, а посему теперь удалено подчистую. Вот тут мне как раз и требуются подсказки со стороны людей, которые гораздо больше меня понимают в m-p Как вообще там можно строить gui, на что опираться, что в недрах m-p необходимо изучить? Собственно, это и есть связка вопросов, без решения которых дальше двигаться нет смысла.
Что касается прочих неясностей и недоработок, то они второстепенны, но буду рад любым советам и любой критике
Несколько позже подниму эту тему и в рассылке.

[Michael Shigorin]

А я тем временем сделал простенький модуль alterator-mkimage :)

[ИВК]

А я тем временем сделал простенький модуль alterator-mkimage

Так он для тех, кто в общем-то и так "в курсе". А я пишу прогу для чайников

[Skull]

А вот за кнопками "Состав сборки", "Настройка" и "Запуск" - пустота, потому что там всё было пристёгнуто к моим сборкам, а посему теперь удалено подчистую. Вот тут мне как раз и требуются подсказки со стороны людей, которые гораздо больше меня понимают в m-p Как вообще там можно строить gui, на что опираться, что в недрах m-p необходимо изучить? Собственно, это и есть связка вопросов, без решения которых дальше двигаться нет смысла.

В юзабилити лучше опираться на рабочие процессы, а не частые действия (вспомнил-сделал).

Когда делается свой дистрибутив, то что определяется? Давайте попробуем разобраться.

1. Выясняется какой дистрибутив использовать за основу (люди ленивы и готовы чуть-чуть изменить). То есть выбирается проект (лучше, чтобы проекты были готовы, благо m-p-d позволяет).
2. Меняется название (понятное дело, это же святое!), состав пакетов, хуки и оформление. Получается четыре крупных раздела. Если юзер хочет "по приколу" собрать прям щас свежий Simply Linux, то он загружает проект и жамкает кнопку "Создать!". Потом потихоньку меняет.
3. После того, как сделали все изменения, создаём iso-образ. потому что его можно в любимой программе записать или (что вероятней при отладке) подцепить к VirtualBox.
4. При необходимости проект сохраняется и временные файлы очищаются.

Теперь по интерфейсу. Так как параметров для изменения много, простой мастер исключается. По задумке автора это будет рабочая область с левой панелью кнопок действий.

Посмотрите мой прототип интерфейса. Вкладки можно заменить на значки разделов (как в Microsoft Outlook).

Прикрепленные файлы

 mpdgui.png ( 20.77 килобайт ) Кол-во скачиваний: 22

 

[ИВК]

1. Выясняется какой дистрибутив использовать за основу (люди ленивы и готовы чуть-чуть изменить). То есть выбирается проект (лучше, чтобы проекты были готовы, благо m-p-d позволяет).

Логично. И тогда понятнее, как сочинять gui для этого дела, с чего начинать.

Теперь по интерфейсу. Так как параметров для изменения много, простой мастер исключается. По задумке автора это будет рабочая область с левой панелью кнопок действий. Посмотрите мой прототип интерфейса.

Точно, кнопки разделов должны быть вверху, причём постоянные, а кнопки действий сбоку, причём меняющиеся в зависимости от того, какой раздел активен. Зря я их смешал. Переделаю.

[Skull]

Точно, кнопки разделов должны быть вверху, причём постоянные, а кнопки действий сбоку, причём меняющиеся в зависимости от того, какой раздел активен. Зря я их смешал. Переделаю.

необязательно вверху, можно и справа. Но по поводу постоянного показа — в точку. Пользователь теряется, когда что-то исчезает. Обрати внимание, что нужно отмечать статус сборочницы (справа внизу).

[ИВК]

Вверху постоянные кнопки разделов (вероятно, такие : Проекты, Состав сборки, Настройки, Оформление, Справка). Справа : в верхней части кнопки навигации (как сейчас в разделе брендинга; но они и в других разделах понадобятся), в нижней - кнопки действий. В зависимости от выбранного проекта должно соответственно меняться содержимое других разделов (кроме Справки, естественно) - но это потом; для начала пусть в разделе Проекты будет один проект Примерно так. Пожалуй, в ближайшее время попробую как-то это реализовать

[ИВК]

Перенесено из темы "Электронный журнал про Alt linux"

А что тут такого, на Basic'ах и Pascal'ях же пишут программки и без полноценных IDE обходятся

Но вряд ли кто будет отрицать тот факт, что с gui намного удобнее

А вот по поводу мордочки вопрос: а стоит ли её делать? В смысле - самому и на чём умеешь. Может быть лучше скооперироваться с mike@ и попробовать совместно web-интерфейс разрабатывать? Честно говоря, IMO, то направление более масштабируемо и глобально более ценно для сообщества. Но дело, конечно, каждого куда вкладыват свои ресурсы, возможно тебе это важнее и по другим причинам.

Об этом поздно говорить : моя прога - в стадии доработки, и бросать её уже нет смысла. Доделаю, а уж дальше видно будет.
А вообще тут главное в том, кому вообще нужен gui для сборки альтовских дистров. Ещё недавно вроде как никому был не нужен. Сейчас лично я знаю одного человека, который в самом деле этим gui (даже недоделанным) активно пользуется, и человек этот ходит в шестой класс школы Вот на его потребности/возможности я и ориентируюсь - именно потому что это реально существующий пользователь программы, а не гипотетический. А другие потенциальные пользователи... где они? Ну не вдохновляет меня идея писать gui для гиков, которые и без него до сих пор успешно обходились (рассылку devel-distro, кстати, читаю, в том числе и обсуждение, которое начал Ildar Mulyukov... но всё равно не вдохновляет). Надо всё-таки определиться, кому требуется gui, в чём настоящий смысл его написания.

[ИВК]

Программа сейчас в таком виде :
 mpgui.tar.gz ( 398.35 килобайт ) Кол-во скачиваний: 5

Запуск командой

Код

python mpgui.py

 screenshot.jpg ( 129.18 килобайт ) Кол-во скачиваний: 20

Тестовая версия. У меня дистры успешно собирает; впрочем, баги ещё выскакивают иногда.
Прогу делал при разрешении 1280x1024; потом подгонял ещё под 1024x768 (это сейчас минимум для неё); как при других разрешениях - не знаю.
С брендингом разные нюансы, из-за которых он на других компах так просто собираться не будет (с чем попозже разберусь, поскольку это едва ли главное), а прочее по идее должно работать не только у меня.
Про всякого рода пояснительный материал. Кто-то может сказать, что его слишком мало, а кто-то - как раз наоборот. Так вот, в итоге такого материала будет намного больше, чем сейчас, но с возможностью отключить его показ.
Пока что задействовал минимум базовых дистрибутивов, фичей, параметров сборки. Думаю, без лишних мучений использовать остальное можно, лишь добавив к m-p, так сказать, интерфейс, обращённый к gui А именно : базовые дистрибутивы (то есть не включающие в себя дополнительных фичей) отдельно и со своим единообразным интерфейсом для подключения к gui; фичи - тоже отдельно и с собственным подобным интерфейсом; pkglist'ы - тоже; параметры сборки - тоже. (Понимаю шаткость границ между дистрами, фичами и pkglist'ами, но хотя бы для gui эти границы должны выглядеть чёткими). Таково (в самом общем виде) моё мнение на этот счёт; уж не знаю, насколько оно справедливо Собственно, исходя из этих соображений, чуть-чуть подправил тот экземпляр m-p, который встроен в каталог программы (по идее, конечно, на его месте должен быть симлинк на оригинальный m-p, но сейчас так не сделать).
Насчёт того, на каком языке желательно писать gui для m-p. Михаил тут говорил, что лучше веб-интерфейс. Поскольку тестовый питоновский gui теперь налицо, то можно уже более предметно обсудить вопрос о том, чем именно веб-интерфейс был бы лучше.
Насчёт того, каким сторонам программы я уделяю больше внимания, а каким меньше. Ориентируюсь прежде всего на очевидные для меня потребности конкретных людей, а не на предполагаемые запросы гипотетических пользователей. А значит, программа получается такой, какой она нужна двум людям, которые уже сейчас всерьёз ею интересуются - то есть автору и тестеру. Этими субъективными соображениями и обусловлена расстановка акцентов (выбор именно сборок с TDE в качестве базовых, особое внимание к брендингу, пояснения с картинками и т.п.) Если ещё кто-то желает использовать эту программу то давайте обсудим, какой же она должна стать в итоге и как её таковой сделать

[ksa]

Этими субъективными соображениями и обусловлена расстановка акцентов (выбор именно сборок с TDE в качестве базовых, особое внимание к брендингу, пояснения с картинками и т.п.)

Я за пояснения как можно более подробные на каждое действие (как на приложенном скрине, например). В остальном же считаю, что не принципиально, с каким DE пойдёт сборка. Хорошая работа, надеюсь доведешь до ума

Сообщение отредактировал ksa - 1.12.2012, 13:18

[kostyalamer]

Красиво смотрится, я за питон
Пробовать пока боюсь у меня сейчас в работе очередной дистр, как бы чего не сломать в сборке.
PS она у тебя и пакеты брендинга собирает ?

[ИВК]

Да, собирает и в свою репу укладывает. Но как раз секцию брендинга я пока не вполне отвязал от своей сборки.

[ИВК]

Я за пояснения как можно более подробные на каждое действие (как на приложенном скрине, например). В остальном же считаю, что не принципиально, с каким DE пойдёт сборка. Хорошая работа, надеюсь доведешь до ума

Непременно доведу. Пока на неделю или две переключусь на срочные дела, а потом опять возьмусь за эту софтину.

[ИВК]

Альфа-версия gui для m-p-d

Сделал в ней довольно много пробных сборок, по ходу дела отстреливая баги; вроде особо крупных не осталось... или я их не вижу
rpm-пакет пока не делал. Поэтому выкладываю программу просто в виде архива. .mpdgui.tar.gz надо распаковать в домашний каталог, а сам скрипт mpdgui.py положить куда угодно. Запуск пока из консоли (чтобы баги отлавливать).
Объём этого архива так велик из-за того, что как сам m-p-d (тот вариант, который Константин в декабре выложил вот здесь - чуть-чуть доработанный), так и исходники базового брендинга встроены прямо в каталог программы. Делать иначе прямо сейчас не вижу смысла (неоправданное усложнение), а дальше видно будет.
В качестве базовых дистрибутивов сейчас поддерживаются только те, которые в Makefile m-p-d фигурируют под названиями kde3.cd, kde.cd, wmsmall.cd и wmmiddle.cd (уточнение насчёт двух последних : без скелетонов). Также пробовал e17test.cd и children.cd, там что-то не пошло, пока отложил. Собственно, прикрутить к проге поддержку какого-либо дистрибутива не так уж сложно, была бы у кого-то потребность в этом.
Проектов на основе базовых дистрибутивов можно одновременно делать сколько захочется (если начнут путаться под ногами - лишние спрячьте в корзине ). Можно добавлять к сборке live- и rescue- режимы (правда, не проверял, как работают), делить пакеты дистрибутива на основной набор и группы, устанавливаемые по выбору пользователя.
Базовый брендинг пока(?) один - наш клубный (не знаю, нужны ли ещё и другие, поскольку и из этого одного легко соорудить что угодно, даже вовсе на него не похожее ). Для пробы позволено вытворять с ним что угодно в демо-режиме (в tmpfs; результаты не сохраняются). Но вообще он для создания на его основе других брендингов. Всякого рода заставки / фоновые картинки можно делать каждую отдельно или (кому лень) использовать для всех одну картинку.
Для собираемых пользователем rpm-пакетов брендинга, естественно, требуется локальный репозиторий; если он не указан пользователем, то будет создан автоматически.
Кроме основного питоновского пакета требуются ещё python-modules-tkinter и python-module-imaging. Из сторонних программ нужны (если делать свой брендинг) Gimp и (если одна картинка для всех заставок) ImageMagick (хотя его, наверное, можно чем-то заменить). Ещё используются несколько стандартных утилит, которые, видимо, есть везде.
Писал прогу при разрешении 1280x1024, под 1024x768 (а это минимум по крайней мере для данной версии программы) вроде тоже подогнал; насчёт других разрешений не знаю.
Насколько успел, снабдил программу пояснениями и картинками; кому они не нужны, тот может отключить их показ.

Когда время будет, хочу заняться ещё вот чем (перечислено примерно в порядке убывания значимости) :
Основательно потестировать программу с целью добивания уцелевших багов и недочётов.
Улучшить справочную систему.
Доработать сам интерфейс.
Прикрутить поддержку скелетонов (минискелетонов).
Нормально согласовать install- и live-режимы, когда они в одной сборке.
Реализовать подключение фичей.
Собрать rpm проги.
Придумать для неё название
Привести код в порядок (сейчас в нём много странного).
Увеличить число поддерживаемых базовых дистрибутивов.
Всерьёз заняться секцией сборочных параметров.

Кому интересно - потестируйте, пожалуйста. Не удивлюсь, если обнаружите что-то, чего я не замечаю Думаю, прога ничего не поломает; она по умолчанию работает только в своих каталогах, а это ~/.mpdgui и /tmp/.private/<имя_юзера>/mpdgui.
 sn1.png ( 200.37 килобайт ) Кол-во скачиваний: 9
 sn2.png ( 100.61 килобайт ) Кол-во скачиваний: 10
 sn3.png ( 53.25 килобайт ) Кол-во скачиваний: 8

[kostyalamer]

Кому интересно - потестируйте, пожалуйста. Не удивлюсь, если обнаружите что-то, чего я не замечаю Думаю, прога ничего не поломает; она по умолчанию работает только в своих каталогах, а это ~/.mpdgui и /tmp/.private/<имя_юзера>/mpdgui.

Мне очень интересно, но я в полнейшем swap-е - добиваю wmmiddle. Надо бы твою сборочницу в него запихать, может соберешь пакет ?
Кстати скелетон wmmiddle опять меняется в связи с переходом на новые иконки, наверное будет готов в следующие выходные ( скелетон а не wmmiddle )

[ИВК]

может соберешь пакет ?

Ну тогда несколько изменю приоритеты и постараюсь первым делом вспомнить, как вообще собираются rpm-ки Наверное, соберу. Но альфу в сборку запихивать - это уместно?

[kostyalamer]

Ну тогда несколько изменю приоритеты и постараюсь первым делом вспомнить, как вообще собираются rpm-ки Наверное, соберу. Но альфу в сборку запихивать - это уместно?

Вполне уместно сделай версию например 0.1 и спокойно собирай, если что помочь с rpm-кой - я вечером в джабере, правда завтра - сегодня уже вырубаюсь.

[ИВК]

Ясно; соберу.

[ИВК]

Вот этот пакет : mpdgui-0.1-alt1.noarch.rpm

[kostyalamer]

Вот этот пакет : mpdgui-0.1-alt1.noarch.rpm

Иван, спасибо, скачал. В клубную репу засунуть не могу так как нет src-хи, а в wmmiddle с удовольствием запихаю при помощи сборочной репы.

Сообщение отредактировал kostyalamer - 3.3.2013, 21:59

[ИВК]

В клубную репу засунуть не могу так как нет src-хи

Забыл про неё, а сейчас её так просто в инет на забросить; ну да ладно, не к спеху Следующую версию выложу вместе с src-кой

[ИВК]

А тут, оказывается, на одну из верхних кнопок текст не влазит Костя, у тебя там разрешение какое?

[kostyalamer]

А тут, оказывается, на одну из верхних кнопок текст не влазит Костя, у тебя там разрешение какое?

1024*768 , это про крайнюю правую? Скорее всего приколы Tkinterа ( он почему-то иногда игнорирует даже прописанные шрифты, таща размер или шрифт, точно не скажу, из системы ) По-этому я перешел на графические кнопки когда писал wmtrashpy .
Но в принципе понятно что у тебя там написано, так что не критично

Сообщение отредактировал kostyalamer - 6.3.2013, 21:01

[ИВК]

Ага, любопытно... но ещё любопытнее то, что у меня в том же WMMiddle (а я уже поставил его на оба компа) при том же разрешении 1024x768 текст на эту кнопку вполне влезает; и вообще не наблюдается никаких странностей с текстами - ни на кнопках, ни в самом окне. Наверное, и это различие как-то связано с тем, что у меня сборка на t6

[kostyalamer]

Наверное, и это различие как-то связано с тем, что у меня сборка на t6

Да , скорее всего у нас с тобой получились разные шрифты в сборках.

[ИВК]

Потестировав программу в WMMiddle, обнаружил, что крайне безалаберно отнёсся к её зависимостям - а в них должны быть прописаны по крайней мере hasher, mkimage, autoconf_2.60, apt-repo-tools. В следующей версии впишу. И ещё юзер должен состоять в группе hashman. И это... "rpmbuild - команда не найдена" - вроде srpm ещё и самой прогой rpm собирается А вообще убедился, что прога пока всё-таки не вполне отвязана от той среды, в которой она пишется, и первая же проверка в другой среде это наглядно показала

[kostyalamer]

Потестировав программу в WMMiddle, обнаружил, что крайне безалаберно отнёсся к её зависимостям - а в них должны быть прописаны по крайней мере hasher, mkimage, autoconf_2.60, apt-repo-tools. В следующей версии впишу. И ещё юзер должен состоять в группе hashman. И это... "rpmbuild - программа не найдена" - вроде srpm ещё и самой прогой rpm собирается А вообще убедился, что прога пока всё-таки не вполне отвязана от той среды, в которой она пишется, и первая же проверка в другой среде это наглядно показала

Как впишешь заливай куда-нибудь при удобном случае ( лучше и src-ху тоже ).
В группу hashman добавлю в клубном installer-е

[ИВК]

В группу hashman добавлю в клубном installer-е

Это будет правильно Но, имея в виду возможность использования программы в других дистрах, всё-таки добавлю проверку на на то, состоит ли юзер в hashman. Равно как и на наличие локального зеркала бранча.... чтобы по крайней мере предупредить о мелких неудобствах, связанных с его отсутствием. А то пишу прогу для чайников, а предполагаю, что всё это у них уже непременно есть; упустил эту деталь из виду

[kostyalamer]

Это будет правильно Но, имея в виду возможность использования программы в других дистрах, всё-таки добавлю проверку на на то, состоит ли юзер в hashman.

Залил в клубную репу для p6:
installer-distro-club-6.0-alt18 и installer-distro-wmmiddle-6.0-alt18 в них пользователь добавлен в группу hashman,
Теперь у того кто использует клубный инсталлер для своих сборок эта проблема возникать не должна

[ИВК]

Наверное, основная проблема тут со сборкой src брендинга; можно вообще собирать src-ку так, чтобы сборочные зависимости брендинга не превратились в зависимости моей программы? В wmmiddle получается вот что :

Код

(из каталога, где лежит branding.tar )
$ rpm  -ts  --nodeps  branding.tar
ошибка: Невозможно переименовать /home/qaz/RPM/SPECS/rpm-spec.F2jGxh в /home/qaz/RPM/SPECS/rpm-spec.F2jGxh: Нет такого файла или каталога: Нет такого файла или каталога

Пакеты rpm-build-* (во всяком случае, те, что есть в моей системе, а в ней этой ошибки нет) установлены.
Или вообще что-то не то делаю? Блуждаю в дебрях хашера (и около него)