Ричард Хьюс об управлении цветом в Linux и GNOME

> Цветокорекцию должна делать графическая подсистеме

ненавистный вамо x.org делает цветокоррекцию, см. например утилиту xicc. но неосиляторы-«реформаторы» из гнома не осилили.

а вот мне этот сферический colord пофигу чуть более чем полностью, поскольку как CUPS не умел просто работать, так и не умеет

и зачем тогда цветопередача ?

может все-таки поддержку принтеров обеспечить более полезно ?

P.S. Кстати почему никто не обсудил тот факт, что при печати на цветной принтер будет очень затруднительно подобрать профиль и colord в этом абсолютно не поможет

AP> На спрос

Что мешает сделать это в виде библиотеки?

> Нафига на каждый чих целый демон делать?

Все такие в порицании самых глупостей мы иногда совпадаем

> colord нужен, новость хорошая, хоть и написана безграмотно.

Функционал нужен, а не он сам

> ненавистный вамо x.org делает цветокоррекцию, см. например утилиту xicc. но неосиляторы-«реформаторы» из гнома не осилили.

Он делает только глобальную цветокорекцию, или я не прав

> ненавистный вамо x.org делает цветокоррекцию, см. например утилиту xicc. но неосиляторы-«реформаторы» из гнома не осилили.

Вообще-то xicc и g-c-m делают абсолютно то же самое: грузят профиль в атом иксов.

> P.S. Кстати почему никто не обсудил тот факт, что при печати на цветной принтер будет очень затруднительно подобрать профиль и colord в этом абсолютно не поможет

В чём затруднение?

> Что мешает сделать это в виде библиотеки?

Попробуй внимательно почитать, что именно делает colord. Мне неинтересно стопицот раз повторять то, что уже и так расжёвано до консистенции детского питания.

>Я её с удовольствием откорректирую, если ты спокойно объяснишь, что именно в ней безграмотно.

«с жёсткой зависимостью на» замени на «с жесткой зависимостью от»

Починено, спасибо

Кстати, чисто для общего образования, xicc был написан разработчиком гнома.

«Смешались в кучу кони, люди...» Жги, чувак!

> если б еще мы научились ублажая 95% одновременно не портить жизнь вот этим оставшимся 5ти...

А это возможно - хотя бы теоретически?

Ну и чтобы уже додавить тему про неосиляторов и реформаторов, вот что говорит о работе Ричарда автор xicc:

http://permalink.gmane.org/gmane.comp.gnome.desktop/45759

«Seriously, excellent work on getting this together and making the dream of proper colour management on Linux achievable. We *need* this.»

Тролли дальше :)

извините, что влезаю в научную дискуссию, но накуа там отдельный демон?????

хватит апплета, который держит в shm таблицы с настройками и либлиотеки, которая из любого приложения может эти данные прочитать. вечно все через жопу сделают, и демон повесят.

ну ладно, для cupsа еще пайп прикрутить сбоку. и все

а мне и так норм

На вас не угодишь :) Добавили библиотеку — плохо, не нужна. Сделали маленький шустрый демон — опять не так. Просто признайся: ты хочешь, чтобы линукс оставался ни на что не годной хренью для гиков.

Давай устроим опрос по теме...

На лоре как всегда, один чел делает дело, стопитсот советуют кирпичами. вывод: лорт-торт.

Удобное и интуитивное GUI? Не видел. Цеплял профиль, приготовленный в окнах.

>один чел делает дело

Все его «дело» - это гордыня и недостаток образования. Когда люди строят Храм, а один мудак в самозабвении ибошет топором направо и налево, отрубая пальцы своим коллегам и бороды заказчикам.

PS. Я подозреваю, что слово «ибошет» не вполне цензурно, но замены в словаре не нашла.

Покажи как надо, избыточно образованная (да ещё и не гордая).

Авивыч, ты какой-то нервный :)

«Solaris 10 остается единственной ОС, которая обеспечивает совместимость приложений для разных версий. Это необходимо для обеспечения непрерывной готовности современных IT-инфраструктур.»

«непрерывной готовности современных IT-инфраструктур». Эта фраз весит 8 млн. человеко-часов, затраченных на циклы разработка/тестирование/эксплуатация.

ибошет

севон ибошет под шуриком пазор намбер ван?

PS. Я подозреваю, что слово «ибошет» не вполне цензурно, но замены в словаре не нашла.

Я считаю, ивриту и идишу не место на ЛОРе.

Нет, это совсем другое. Это приложение физических сил, для преодоления внешних обстоятельств с юмором, что характерно для русского народа.

СМ. «Ветер в харю - я хуярю».

Какой задрот-некрофаг всё ещё издевается над деревьями? Хватит бумагу переводить, 21 век, Блад!

С миру по нитке - мент^вот и КДЕ на ССД начал тормозить

Ого, рандомный булшит из всех отверстий.

> «непрерывной готовности современных IT-инфраструктур». Эта фраз весит 8 млн. человеко-часов, затраченных на циклы разработка/тестирование/эксплуатация.

Исходники сановского тестового пакета для фортрановского компилятора фстудию. Поглядим на них за ведёрной чашкой чая и обсудим, на что ушли эти 8 млн. человеко-часов.

Просто создание целого демона действительно непонятно для такой задачи.

>А кстати, почему именно демон?

А кто? Принтер работает под одним юзером. Иксы под другим. Сканер под saned работает....

Как им взаимодействовать? Через Ядро?

Это не целый, это lightweight.

>Как им взаимодействовать? Через Ядро?

dbus?

AP> Попробуй внимательно почитать, что именно делает colord. Мне неинтересно стопицот раз повторять то, что уже и так расжёвано до консистенции детского питания.

Из обсуждения ясно, что colord нужен как демон для горячего подключения устройств и использования некоторых механизмов IPC для передачи данных в приложение о том, какой профиль нужно использовать. Но на фоне наличия отдельной подсистемы для устройств сия затея выглядит странной, так как приложение само может брать данные через библиотеку, в том числе и о профиле.

AP> На вас не угодишь :) Добавили библиотеку — плохо, не нужна. Сделали маленький шустрый демон — опять не так. Просто признайся: ты хочешь, чтобы линукс оставался ни на что не годной хренью для гиков.

Вообще-то большинство тут высказывается как раз за оформление в виде библиотеки. К слову: если это хозяйство в библиотеку вынести, можно и тем, кому хочется демона, эту библиотеку в нём и использовать.

>dbus?

Как вариант. Но насколько я помню dbus не все тут любят.... Да и напомните мне у dbus какие данные гонять можно? Тут вроде демон профили отдает по требованию и все. Про шину там выше писали что демон как раз через и общается. Но сидеть постоянно запущенным вынужден, а такие штуки называют демонами...

terminator> Это не целый, это lightweight.

И всё же непонятно, зачем в первую очередь демон делать.

terminator> dbus?

Это уже не такое уж и lightweight. И привязка у dbus, которым пользуются не все. К тому же помнится есть один дядя, которого звать Витус Вагнер. Он критиковал dbus, хотя и подтверждал, что шина обмена сообщениями таки нужна, но в другой реализации.

В связи с этим я считаю разумным подходом сделать сперва библиотеку.

Внезапно, colord как раз и юзает d-bus :)

> Вообще-то большинство тут высказывается как раз за оформление в виде библиотеки.

Если бы это была библиотека, вони в комментах было бы не меньше. Инфа 95%.

А если библиотека + необязательный демон?

Да у вас демонофобия, товарищ.

Отнюдь. Просто такое решение не является универсальным.

вопрос шарящим в dbus - шина может запустить некий демон, если получен определенный запрос на обработку, и точно так же его потушить, в случае простоя?

именно это и написано в вики

D-BUS также предусматривает концепцию сервисов. Сервис — уникальное местоположение приложения на шине. При запуске приложение регистрирует один или несколько сервисов, которыми оно будет владеть до тех пор, пока самостоятельно не освободит, до этого момента никакое другое приложение, претендующее на тот же сервис, занять его не сможет. Именуются сервисы аналогично интерфейсам.

Сервисы делают доступной ещё одну функцию — запуск необходимых приложений в случае поступления сообщений для них. Для этого должна быть включена автоактивация, а в конфигурации D-BUS за этим сервисом должно быть закреплено одно приложение. Тогда D-BUS сможет его запустить при появлении сообщения.

После закрытия приложения ассоциированные сервисы также разрегистрируются, а D-BUS посылает сигнал о том, что сервис закрыт. Другие приложения могут получать такие сигналы и соответствующим образом реагировать.

хотя это наверное больше к systemd задачка. будет Ъ если они все это дело интегрируют.

Systemd сам работает через dbus, он отслеживает кто-кого запустил и раскидывает процессы по контрольным группам (потомков в одну группу с родителями). Dbus запускает и завершает процессы согласно сигналам и сервисам, а systemd руководствуется гениалогией порождения процессов, он остановит потомков, если завершил работу их родитель. Во время работы системы systemd не столько пускач, сколько чистильщик от осиротевших процессов. Зато он запускает большую часть процессов во время загрузки системы, в том числе и сам dbus.

Для меня вообще допил SANE и перенос ScanKromsator на Linux - залог счастливой жизни. Нет, ScanTailor тоже недурен, конечно, но все же Kromsator рулит и разруливает. Да только не увидим мы его под Linux, похоже, поскольку bolega не открывает исходники, на что имеет полное право. А жаль.