Здравствуйте, c-smile, Вы писали:

CS>(На самом деле по итогам разработки HTML based UI для Нортона (около 40 продуктов — скоро выходят)
CS> надо бы мне спеть отдельную песню)

Ты, эта... пой! Мы, ежели чего, то эта... нальем!

Здравствуйте, Денис Майдыковский, Вы писали:

ДМ>Простите за сумбурность изложения, но какие варианты решения можете предожить Вы?

Идеального решения нет: могу сказать как сделано в проудктах семейства Нортон сами знаете кого

(Они используют мой движок для всей новой линейки продуктов)

Они определили несколько наборов базовых images и вплотную
использует резиновость html и css.

Основная фенечка в CSS декларациях типа:

@media screen 
{
  background-image:url(img1.png);
  min-width: 124px;
}

@media screen-hires
{
  background-image:url(img1-hires.png);
  min-width: 248px;
}

application при загрузке UI устанавливает мне HTMLayoutSetMediaType
и система стилей подзватывает точ что нужно.
Код (логика) вообще ничего про это не знает само сабой.

Потребность в резиновости возникает во многих случаях например из недавних багов:
пользователь ставит у них extra large font в системе и фрагменты UI становятся недоступны
вообще. ( overflow:hidden is an evil )

На самом деле потребность в резиновости UI есть не только "украшательская" проблема.


(На самом деле по итогам разработки HTML based UI для Нортона (около 40 продуктов — скоро выходят)
надо бы мне спеть отдельную песню)

Здравствуйте, WinterMute, Вы писали:

ДМ>>Про ресайз битмапов мы уже думали, там более что есть аналогичный по возможностям ресайзер. В принципе, это один из вариантов, но лично мне он не очень нравится своей недерминированостью. Дизайнер увидит в продукте не совсем такую "кнопку", как нарисовал, могут возникнуть вопросы

WM>Для AGG есть небольшой модуль рисующий SVG. Что мешает хрнить "иконки" в SVG и рендерить их в нужный размер?

Иконки — это битмап (их так делает дизайнер). В какой формат битмап не засунь (SVG или BMP) — проблемы те же.

Если заказывать дизайнеру UI-графику в векторе, совместимом, например, с SVG, WMF, и при том требовать от дизайнера высококого качества в этом формате в нужном диапазоне размеров, то начнется падеж среди дизайнеров или их массовое бегство от такого заказчика. Я уж не говорю про маленькие битмапы от 32х32 — вниз. Они всегда дорисовываются попиксельно руками, даже если исходно сделаны в векторе. Не надо еще забывать, что растеризация у софта, на кот. лабает художник, и SVG-движка — разные. Битмап в данном случае тем и хорош, что он уже не требует растеризации и результат не зависит от движка.

---
2 Денис Майдыковский

На вашем скриншоте простые градиенты. Они вообще прекрасно масштабируются как хошь. Т.е. можно смело привязываться к тексту и легко масштабировать такую бэкграундную графику. Для монохромных градиентов достаточно иметь картинку 256х1 пикс. и тянуть ее в разные стороны, например, заливать в битмап для битблита без интерполяции цветов. Если не монохромный — интерполировать.

Для кнопок/иконок я бы посоветовал все то же — иметь 2-3 базовых размера картинок и использовать наиболее подходящий без масштабирования. В коде привязывать текстовые и графические элементы вручную (центрировать, выравнивать), танцуя от текста. В крайнем сл. масщтабировать картинки в сторону увеличения.

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

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

Еще советую глянуть. Если DPI очень высок, то возможно даже сильно масштабированная кнопка не будет смотреться замыленной. Найnи бы 15" ноутбук с 1920 на сколько-то пикселов.

Здравствуйте, Денис Майдыковский, Вы писали:

ДМ>Пока в качестве промежуточного варианта я думаю иметь несколько наборов картинок, для 72 дпи, 96 дпи. Но это решение не универсально. Windows позволяет установить призвольное разрешение экрана, не только "широкие/узкие" шрифты.

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

Если человек хочет, чтобы было хорошо видно — он выбирает большие картинки; чтобы было много места — выбирает мелкие.
По умолчанию можно делать автоматический выбор в зависимости от настроек системы — и оставить возможность ручного.

Ведь в чём тут фокус? У пользователя есть три рукоятки управления экраном:
— смена графического режима (и, тем самым, физического разрешения)
— смена программного разрешения (те самые 72/96/... dpi), не имеющая никакого отношения к физическому
— смена размера шрифтов и элементов окон в оформлении
Например, в вин98 были темы "для слабовидящих" — заточенные под 72 dpi, но с гигантскими шрифтами.
Мотивы варьирования программного разрешения разные: кто-то плохо видит, а кому-то хочется, чтобы линейки в ворде и фотошопе по ту и по сю стороны экрана совпадали.
Уж если на что ориентироваться — так это на пиксельный размер элементов оформления (GetSystemMetrics в ассортименте), а не на dpi.

В общем, я предлагаю сделать несколько скинов, но отказаться от расхожего подхода — выбора между "классика/попугайно/макинтошево" в угоду моде — в пользу практичного "компактно/средне/крупно" в угоду удобству.

... А именно графические элементы и текст.

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

Теперь серьёзно. Интерфейс моей программы основан на многочисленных графических элементах, по просту картинках. Вы наверняка много раз видели подобные, начиная от плееров и заканчивая OEM-приблудами к разным устройствам. Но помимо всяких красивых кнопок и текстур и обрамлений полей ввода программа содержит достаточное количество текстовых элементов, а пиксельный размер текста зависит от текущего DPI экрана (проще говоря "широких шрифтов").

Если жестко задавать размер шрифта всех текстовых элементов, привязывая его к размеру картинок, то на "широких шрифтах" этот текст будет слишком мелким, по сравнению с обычными диалогами, мени и т.д. Windows. В данной программе это недопустимо. Однако в противном случае при изменении DPI экрана текст будет вылезать за пределы графического обрамления или обрезаться.

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

Пока в качестве промежуточного варианта я думаю иметь несколько наборов картинок, для 72 дпи, 96 дпи. Но это решение не универсально. Windows позволяет установить призвольное разрешение экрана, не только "широкие/узкие" шрифты.

Простите за сумбурность изложения, но какие варианты решения можете предожить Вы?

Здравствуйте, Денис Майдыковский, Вы писали:

ДМ>Какие варианты решения можете предожить Вы?

А нельзя ли увидеть пару скриншотов? А то я впринципе понимаю о чём речь, но не совсем понятно что там с множеством картинок.

Здравствуйте, adontz, Вы писали:

A>А нельзя ли увидеть пару скриншотов? А то я впринципе понимаю о чём речь, но не совсем понятно что там с множеством картинок.

Ну например так: http://files.rsdn.ru/14533/Main%20Screen.jpg

На месте белого поля появятся многочисленные элементы управления содержащие текст, типа полей ввода, меток и т.д. Но в "психоделическом" оформлении, типа поля Search.

A>>А нельзя ли увидеть пару скриншотов? А то я впринципе понимаю о чём речь, но не совсем понятно что там с множеством картинок.

ДМ>Ну например так: http://files.rsdn.ru/14533/Main%20Screen.jpg

ДМ>На месте белого поля появятся многочисленные элементы управления содержащие текст, типа полей ввода, меток и т.д. Но в "психоделическом" оформлении, типа поля Search.


Я так думаю, можно попробовать приспособить к этому делу AGG? (как пример здесь и особенно здесь (двигать скроллбар справа и изменять его размеры)), но сколько времени займет его прикручивание к проекту — неизвестно

Здравствуйте, Mamut, Вы писали:

M>Я так думаю, можно попробовать приспособить к этому делу AGG?

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

Здравствуйте, Денис Майдыковский, Вы писали:

ДМ>Здравствуйте, Mamut, Вы писали:

M>>Я так думаю, можно попробовать приспособить к этому делу AGG?

ДМ>Про ресайз битмапов мы уже думали, там более что есть аналогичный по возможностям ресайзер. В принципе, это один из вариантов, но лично мне он не очень нравится своей недерминированостью. Дизайнер увидит в продукте не совсем такую "кнопку", как нарисовал, могут возникнуть вопросы

Для AGG есть небольшой модуль рисующий SVG. Что мешает хрнить "иконки" в SVG и рендерить их в нужный размер?

Здравствуйте, Денис Майдыковский, Вы писали:

ДМ>Здравствуйте, adontz, Вы писали:

A>>А нельзя ли увидеть пару скриншотов? А то я впринципе понимаю о чём речь, но не совсем понятно что там с множеством картинок.

ДМ>Ну например так: http://files.rsdn.ru/14533/Main%20Screen.jpg

ДМ>На месте белого поля появятся многочисленные элементы управления содержащие текст, типа полей ввода, меток и т.д. Но в "психоделическом" оформлении, типа поля Search.

Вполне удобно такое делается на Tcl/Tk
Там можно гибко указвать какие зазоры между графическими элементами "резиновые" и с каими весами.
Интерфейсную библиотеку Tk можно выдрать (это dll) и юзать отдельно...

Здравствуйте, Денис Майдыковский, Вы писали:

ДМ>... А именно графические элементы и текст.

Disclaimer: всё нижесказанное — моё (и не только) личное мнение и не претендует на истину в последней инстанции.

1. Если есть возможность — не выпендриваться со скинами и использовать стандартный пользователский интерфейс.
   
2. Если скин всё-таки есть, пользователь должен иметь возможность его менять. И не в пределах «синий/зелёный/серебристый» или «голубой/серебристый/чёрный», а неограниченно — покрасить всё в произвольные цвета и перерисовать всю графику.
   
3. “whenever a programmer thinks, "Hey, skins, what a cool idea", their computer's speakers should create some sort of cock-shaped soundwave and plunge it repeatedly through their skulls”. © makali здесь.

Здравствуйте, Centaur, Вы писали:

C>

1. Если есть возможность — не выпендриваться со скинами и использовать стандартный пользователский интерфейс.
   
   Увы, увы. Таково ТЗ.
   
   C>
2. Если скин всё-таки есть, пользователь должен иметь возможность его менять. И не в пределах «синий/зелёный/серебристый» или «голубой/серебристый/чёрный», а неограниченно — покрасить всё в произвольные цвета и перерисовать всю графику.
   
   Примемерно так и будет. Только скин будет задавать не пользователь, а распространитель.
   
   C>
3. “whenever a programmer thinks, "Hey, skins, what a cool idea", their computer's speakers should create some sort of cock-shaped soundwave and plunge it repeatedly through their skulls”. © makali здесь.

Здравствуйте, goto, Вы писали:

G>На вашем скриншоте простые градиенты. Они вообще прекрасно масштабируются как хошь. Т.е. можно смело привязываться к тексту и легко масштабировать такую бэкграундную графику. Для монохромных градиентов достаточно иметь картинку 256х1 пикс. и тянуть ее в разные стороны, например, заливать в битмап для битблита без интерполяции цветов. Если не монохромный — интерполировать.

Это был скриншот одной версии программы, другая выглядела например так: http://www.rsdn.ru/File/14533/image004.png
Что придёт в голову "чудо-десигнерам" на этот раз неизвестно.

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