[devel] gtk engines smooth

Вячеслав Вячеслав
Вт Сен 7 17:35:54 MSD 2004


On Втр, 2004-09-07 at 18:07 +0700, Alexey Morozov wrote:
> On Tue, Sep 07, 2004 at 12:31:10AM +0400, Вячеслав Диконов wrote:
> > Вот они:
> > 1) gtk-themes-* в котором все библиотеки и gtkrc файлы тем
> > для gtk1 и gtk2. Недостаток - двойная зависимость. Достоинство -
> > простота установки и гарантированная синхронность переключения.
> Вы путаете gtk-themes и gtk-engines.
Я их не путаю а сознательно совмещаю в одном пакете на том основании,
что это - части одного целого под названием тема или семейство похожих
тем. 

Темы могут не зависеть от наличия libgtk+....so.X.Y.Z. Движки (engines)
> _линкуются_ с ними, поэтому, если вы не намерены нарушать неприличным
> образом процесс автоматического поиска зависимостей, то, GTK+-1 в
> систему попадет.
> С другой стороны, зависимость gtk-themes -> обе версии gtk-engines
> приводит к появлению непрямой зависимости на GTK обеих версий.
> 
> > Сборка gtk1 части тем может быть отключена 1 переменной в spec. Я также
> > думаю над возможностью искусственно отключить зависимоcти таких пакетов
> > от gtk (Autoreq = 0) или заставить оба gtk предоставлять общее
> > одинаковое имя и требовать уже его.
> См. выше о природе этих зависимостей. Это _правильные_ зависимости. Без
> них ничего работать не будет.
То есть? Сборочные зависимости никто не тронет. Что будет если разорвать
зависимость уже двоичного пакета со smooth-engine и gtk? Тогда тему с
библиотеками прорисовки можно установить независимо от наличия gtk1. В
случае установки gtk после темы все будет работать. Если
нужен ldconfig, то пишем триггеры.

Для запрета установки тем gtk без хотя бы одной версии gtk можно
написать в spec обеих версий gtk: 

Provides: GTK+

А в spec тем: 

Requires: GTK+

Apt наверняка можно заставить автоматически выбирать gtk2, если нет
прямого указания. Естественно, что пересборку пакетов тем, содержащих
двоичный код нужно делать при каждой пересборке gtk, как и всегда.

> > 2) gtk1-themes-* + gtk2-themes-* Для установки темы для всей рабочей
> > среды нужны _оба_ пакета и поэтому gnome-themes-* требует их вместе. Это
> > значит, что двойная зависимость никуда не делась! Чтобы избавиться от
> > нее нужны условные зависимости типа "ЕСЛИ УСТАНОВЛЕН GTK1, ТО
> > ВИРТУАЛЬНЫЙ ПАКЕТ Х ТРЕБУЕТ ПАКЕТ Y, А В ПРОТИВНОМ СЛУЧАЕ - НЕ ТРЕБУЕТ"
> > Я не согласен отказаться от зависимости на все темы в вершинных пакетах
> > типа gnome-themes или kde-themes, потому что это лишает смысла такие
> > пакеты и всю затею.
> Ну, может, и ладно? :-) 
Нет не ладно. Сейчас творится явная порнография и свалка. Темы
собираются по принципу кто во что горазд. 

> А если серьезно, то GNOME нынче уже весь GTK+-2
> Реально осталось в пределах десятка приложений, которые вообще могут
> потребовать GTK+1, да и то, прогресс по искоренению таких приложений
> идет семимильными шагами.
Пример: Sylpheed никак не могут или не хотят пересобрать на GTK2 уже
несколько лет. gtktalog, которым я пользуюсь также никак не
портируется... 

> > 3) gtk-engine-* + gtk-themes или gtk1/2-engine-* + gtk1/2-themes -
> > CСчитаю это напрасным умножением пакетов так как с точки зрения
> > пользователя устанавливающего темы существование engines - лишняя
> > головная боль.
> ? Это способ отделить "код" от "хужожеств", поскольку это вполне
> параллельно развивающиеся сущности. Не поймите меня превратно, но
> мне кажется у тем и движков совершенно разный жизненный цикл.
С этим полностью согласен, однако как прикажете собирать пакеты,
типа gtk-themes-industrial, если в пакете с
исходниками industrial-engine лежит "самая правильная" тема Industrial и
выделить ее оттуда как сделали авторы smooth никто не собирается?  

Собирать из того же srpm двоичный пакет на 300 байт? Да в нем заголовок
больше содержимого будет. А как туда добавлять сторонние темы,
тербующие Industrial? Уже теперь из 1 (!!!!!) темы должно получиться 4
(!!!) пакета (engine+theme x 2 версии gtk). Добавим к этому знаменитую
темку gorilla (тоже на базе industrial), которая есть часть _другого_
всемирно признанного пакета gnome-themes-extras со своими собственными
исходниками, automake и прочей дрянью. Ее невозможно положить в тот же
пакет что и industrial. Итого у нас 6 (!!!) пакетов для 2 тем в
стиле industrial. Теперь прибавим содержимое gnomelook freshmeat и пр.
Получаем десятки пакетов. Умножаем на количество модулей прорисовки и
добавляем зависимости для пакетов тем GNOME... Получатся сотни пакетов. 

С точки зрения конечного результата это можно сравнить с покупкой
квартиры в виде кирпичей, когда надо самому строить вместо расстановки
мебели в готовом доме. Мне такой кошмар не нужен и собирать множество
пакетов для по сути вариаций одной темы я не буду. Максимум - 2.

> > какой-то мудрец додумался приделать automake к десятку файлов gtkrc) 
> а почему нет? ;-) Это нормальный способ не думать о деталях установки
> вообще. Промышленный.
Бульдозер копает ямку для фиалки в цветочном горшке.

> Ну, вообще-то, я в smooth'е уже сделал этот самый ifdef :-)
И я его уже перенес на другие темы. Правда отключить саму
сборку gtk1-части для тех же industrial и galaxy нельзя, поэтому эффект
чисто поверхностный - возможность пересобрать не упаковывая файлы
для gtk1. 


> > > породит вопли вида:
> > > захотел поставить smooth, получил две версии библиотеки => зависимости в
> > > ALT убитые.
> > Я отчасти согласен, но это неверный вывод.
> Да? Ну тогда объясните это всем тем, кто высказывает такое мнение на
> форумах и прочих отстойниках общественного сознания.
Пошлите их в RH, Mdk, Debian, где такое тоже встречается и к авторам,
которые так все это распространяют.

> > gtk1 сам по себе невелик на фоне всего, что неизбежно будет стоять в
> > системе с графическим интерфейсом, и почти наверняка понадобится для
> > вещей типа usbview или *drake.
> У меня не стоит этих замечательных утилит. Я многое теряю?
Я не телепат %). Для графической конфигурации системы в Альте почти
ничего другого нет и это большой недостаток.
 
> > Кроме того, зависимость на gtk можно вообще убрать.
> Нет. Смотри выше, почему.
Там утверждается, что не будет работать. Я в этом неуверен.

> > Пакеты icon-themes тоже можно поставить "в пустоту".
> А вот зависимости библиотек, увы, нет. По крайней мере, если вы хотите
> этими библиотеками пользоваться :-)


> > См. вариант 2. Можно и так, но тогда будет вместо одного толстого пакета
> > орда мелких. Я как раз и хочу уменьшить этот эффект.
> Почему не предоставить машине возможность выбирать всю мелочевку,
> а человеку дать в руки "макроинструменты"?
В данном случае нежизнеспособно потому что неподъемно.

> > Идея в том, чтобы переключение темы оказывало единообразное действие на
> > все установленные программы (или максимальное их число). С какой стати
> Опс... Это значит, что мой любимый ксемакс из темно-серого на светло-сером
> опять станет черным на ярко-белом? Увы, я не очень одобряю эту идею :-)
Нормальная переключалка (которую еще написать надо (см. соседние
письма)) должна спрашивать прежде чем менять установленные пользователем
темы. Сейчас никто на на мелочь не покушается. Синхронизация есть только
между gtk1<-gtk2 и c помощью костыля (gtk-qt-engine) qt->gtk.

> > пользователей, желающих просто сделать сменить надоевшее оформление,
> > должны волновать различия версий gtk и вообще существование разных
> > библиотек? В форточках интерфейс тоже не только на MFC бывает, но
> > выглядит и управляется одинаково и это плюс, который следует перенять.
> Как это связано с вопросами пакетизации?
Связано тем, что хоть-какой нибудь механизм нужно реализовать. Самый
дешевый способ - пакеты+зависимости. Самый правильный, пожалуй, - писать
всеобщий модульный переключатель тем.

-- 
Вячеслав Диконов <sdiconov на mail.ru>




Подробная информация о списке рассылки Devel