LINUX.ORG.RU
ФорумTalks

Unix-way и просмотр изображений


0

0

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

А что если сделать по-настоящему хороший просмотрщик?

  1. Предельно простой, чтоб багов было меньше. Пусть знает всего один формат: PNM. А всё остальное пускай декодирует утилитами типа входящих в netpbm и получает через stdin.
  2. Информацию о файлах можно получать, вызывая те же утилиты из netpbm или file.
  3. С 2 мордами на Qt и GTK+ и возможностью лёгкой замены на другие тулкиты. Свести использование функций тулкита к минимуму. Пусть программа передаёт тулкиту:
    1. Содержимое меню (окна и контекстного).
    2. Само изображение-битмап.
    3. Необходимую информацию об изображении: размер, число цветов (или лучше всё гнать в 32 битах, пусть тулкит сам разбирается?), масштаб(?).
    4. Команду открыть диалог открытия файла.
    и получает от тулкита:
    1. Нажатые клавиши.
    2. Выбранные в меню функции.
    3. Сигнал об изменении размера окна, вместе с новыми размерами.
    4. Имя файла из диалога открытия.
  4. Сами морды тоже можно сделать отдельными программами и обмениваться с ними данными через stdin/stdout.
  5. Не знаю, как лучше с масштабированием. Можно осуществлять его внутри программы, средствами тулкита, найти соответствующую функцию в libnetpbm или каждый раз дёргать pamscale. Ещё варианты?
  6. Ещё нужен гуёвый конфигуратор с кучей опций. В GTK-версии, наверное, стоит сделать кнопку «Включить/выключить показ большей части настроек, которая неинтересна большинству пользователей». Хранить настройки в текстовом файле. Все настройки можно менять при запуске из командной строки.
  7. Так как понадобится много парсить stdin, имеет смысл прибегнуть к языку, хорошо умеющему обрабатывать тексты и регекспы. Перл?

Корованы? Даже не знаю куда их засунуть.

Главный вопрос: такое уже существует? Кто-нибудь пытался осуществить подобное?

★★★★★
Ответ на: комментарий от atrus

> Есть такой, aalib. :)

Не лучше ли libcaca?

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

> > feh лучше, чем все, что ты предложил

Не лучший, кол-во поддерживаемых форматов невелико. Зачем то приделан к нему интерфейс. При этом он не удобный.

> Вот ради такого ответа я вопрос и задал. Спасибо.


Есть еще Gliv (GTK+ и OpenGL), KView (KDE), Simple Viewer (поделка для личного использования, т.к. ничто иное меня не устроило - отсутствие GUI, все из командной строки, пачка форматов благодаря GFL SDK).

> Как минимум, feh не поддерживает анимированные GIF-ы, очень медленно работает, не умеет открывать файл через GUI, не умеет переопределять управляющие клавиши. Добавление новых форматов потребует правки imlib.


Угу, именно так.

> Если я не прав, пожалуйста, перечисли как в feh сделать всё, что перечислено в моём первом посте.


Ну сорцы открыты - так что все можно исправить на свой лад.

andreyu ★★★★★
()
Ответ на: комментарий от atrus

> > xnview
> Смотрел. Linux-версия была на Motiff, из-за чего смотрелась совершенно непотребно. Кроме того, в отличии от оффтопичной реализации она тормозила.


Давно уже есть версия на Qt.

andreyu ★★★★★
()
Ответ на: комментарий от gdv2

> Зато есть форк http://geeqie.sourceforge.net/ похоже пока живой.

Называется альфа-версией, ебилдов нигде нет. Спасибо, попробую...

question4 ★★★★★
() автор топика

меня, на пример, очень устраивает thunar + display (imagemagick). самое то: надёжно, функционально, просто, информацию о файле показывает, альфа канал поддерживает, svg показывает, картинки конвертирует, запускается быстро. это всё что мне от этого нужно

AGUtilities ★★★
()
Ответ на: комментарий от AGUtilities

> меня, на пример, очень устраивает thunar + display (imagemagick). самое то: надёжно, функционально, просто, информацию о файле показывает, альфа канал поддерживает, svg показывает, картинки конвертирует, запускается быстро. это всё что мне от этого нужно

Вы снова привязываетесь к определенному DE/WM. Человек же ищет DE/WM-независимое решение.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

> Вы снова привязываетесь к определенному DE/WM. Человек же ищет DE/WM-независимое решение.

display — независимое решение. Но очень некрасивое :) И к интерфейсу долго приспосабливаться.

question4 ★★★★★
() автор топика

Когда пытаются применить unix-way к чисто пользовательским GUI-программам, то всегда получается тормозное(1) неюзабельное(2) глючное(3) говно(4).

P.S. На правах ИМХО =)

> Предельно простой, чтоб багов было меньше. Пусть знает всего один формат: PNM. А всё остальное пускай декодирует утилитами типа входящих в netpbm и получает через stdin.


> Не знаю, как лучше с масштабированием. Можно осуществлять его внутри программы, средствами тулкита, найти соответствующую функцию в libnetpbm или каждый раз дёргать pamscale. Ещё варианты?


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

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

> С 2 мордами на Qt и GTK+ и возможностью лёгкой замены на другие тулкиты. Свести использование функций тулкита к минимуму. Пусть программа передаёт тулкиту:


Написание одинаковых "морд" на N разных графичестких тулкитах является идиотизмом при N>1.

> Так как понадобится много парсить stdin, имеет смысл прибегнуть к языку, хорошо умеющему обрабатывать тексты и регекспы. Перл?


Гонять большой объём данных через stdin/stdout это уже не нормально. А если переводить в текст - то опять же начинается идиотизм.

Deleted
()
Ответ на: комментарий от Deleted

Описанные мной проблемы исчезают, если все утилиты, из которых будет "собран" такой просмотрщик, разрабатывать в рамках единого проекта. И чётко специфицировать интерфейс взаимодействия между ними. Примерно как сделано с плагинами в GIMP'е или в шахматных программах. Но при этом придётся полностью отказаться от сторонних уже готовых утилит и писать всё самому.

Deleted
()
Ответ на: комментарий от question4

> > Вы снова привязываетесь к определенному DE/WM. Человек же ищет DE/WM-независимое решение.
> display — независимое решение. Но очень некрасивое :) И к интерфейсу долго приспосабливаться.


Про imagemagick я знаю, речь была о thunar. А display из imagemagick коряв и далеко не шустр. Уж лучше feh использовать, хотя последний мало форматов поддерживает.

andreyu ★★★★★
()
Ответ на: комментарий от question4

>Нет, эти программы созданы именно для того, чтобы ими пользовались роботы.

это неправильно, для роботов есть библиотеки, они куда быстрее, надёжнее и прямее.

>Чем он плох? Скорость будет низкой? Или что?

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

chicane
()
Ответ на: комментарий от Deleted

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

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

chicane
()
Ответ на: комментарий от Deleted

> Проблемы начнутся тогда, когда разработчик одной из таких сторонних утилит решит чуть-чуть поменять например опции командной строки.

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

> Или формат вывода сообщений.

Аналогично.

> Или прикрутит локализацию.

Запускать с LC_ALL=C.

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

Хорошая метафора :)

> Написание одинаковых "морд" на N разных графичестких тулкитах является идиотизмом при N>1.

Одинаковых внешне, или под одну задачу? С первым согласен, второе широко практикуется уже много лет :)

> Гонять большой объём данных через stdin/stdout это уже не нормально.

Альтернативы? Временный файл в shm-tmpfs?

> Описанные мной проблемы исчезают, если все утилиты, из которых будет "собран" такой просмотрщик, разрабатывать в рамках единого проекта.

Netpbm даст ~80 форматов. С остальными надо смотреть.

> И чётко специфицировать интерфейс взаимодействия между ними. ... Но при этом придётся полностью отказаться от сторонних уже готовых утилит и писать всё самому.

То есть изобрести ещё один велосипед. Или найти удобный из готовых.

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

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

Это утопия. Ты не сможешь адаптировать код/конфиг своего просмотрщика к новым опциям утилиты Васи Пупкина до того как Вася Пупкин выпустит новую версию своей программы с изменённым cli-интерфейсом. В результате пользователи, регулярно обновляющие свою систему, будут часто сталкиваться с несовместимостью твоего просмотрщика с утилитой Васи Пупкина. Решить эту проблему, не отказавшись от утилит Вась Пупкиных, не под силу даже айбиэмам с микрософтами.

> Альтернативы? Временный файл в shm-tmpfs?


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

> Netpbm даст ~80 форматов. С остальными надо смотреть.


Netpbm - это утилита от Васи Пупкина. Вася Пупкин решит переработать cli-интерфейс, выпустит новую версию, пользователи её скачают с остальным обновлением и... твоя программа перестаёт работать.

> То есть изобрести ещё один велосипед. Или найти удобный из готовых.


Если так сильно хочется именно юникс-вей с изолированными процессами, соединёнными при помощи пайпов - то да, изобретать велосипед. Готовых решений с чётко специфицированным интерфейсом нет.

Есть такая замечательная штука - IrfanView (только под виндоус, к сожалению). Ведь её автор (а он судя по всему один) как-то осилил сделать простой, быстрый и безглючный просмотрщик картинок. И без всяких труЪ-веев.

Deleted
()
Ответ на: комментарий от Deleted

> IrfanView (только под виндоус, к сожалению).

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

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


Где-то 85% объёма архивов составляют сторонние плагины. Основная программа поддерживает 10 распространённых форматов: gif, tiff, jpeg, png, lbm, pcx, psd, tga, pcd, семейство pbm считаю за 1 — и стандартные виндовые: wmf, emf, bmp, ico, icl, cur, ani (по-моему эти 17 тоже оформлены как плагины).

К такому количеству плагинов он шёл с середины 1990-х (самая старая версия, упомянутая на сайте — от 1 июня 1996 года).

Часть плагинов — платные, бесплатные их варианты показывают рекламу :)
Таковы, например, плагины SVG и DXF.

question4 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.