From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [devel] gtk engines smooth From: =?koi8-r?Q?=F7=D1=DE=C5=D3=CC=C1=D7_?= =?koi8-r?Q?=E4=C9=CB=CF=CE=CF=D7?= To: ALT Devel discussion list In-Reply-To: <20040907110723.GH27133@pyro.hopawar.private.net> References: <1094405260.1319.86.camel@alpha.tirs.ru> <20040906142008.GG27133@pyro.hopawar.private.net> <1094502670.5807.63.camel@alpha.tirs.ru> <20040907110723.GH27133@pyro.hopawar.private.net> Content-Type: text/plain; charset=KOI8-R Date: Tue, 07 Sep 2004 17:35:54 +0400 Message-Id: <1094564154.12359.53.camel@alpha.tirs.ru> Mime-Version: 1.0 X-Mailer: Evolution 1.5.8 (1.5.8-alt0.5) Content-Transfer-Encoding: 8bit X-Spam: Not detected X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 13:36:38 -0000 Archived-At: List-Archive: List-Post: 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 бывает, но > > выглядит и управляется одинаково и это плюс, который следует перенять. > Как это связано с вопросами пакетизации? Связано тем, что хоть-какой нибудь механизм нужно реализовать. Самый дешевый способ - пакеты+зависимости. Самый правильный, пожалуй, - писать всеобщий модульный переключатель тем. -- Вячеслав Диконов