Кроссплатформенная графика с использованием cairo

> gtk3 пока зовется иначе(и двояко :)

Qt 4?

Троли руляД!!!!!!

> и там и там пиксели бывают квадратные и прямоугольные.

Примеры современных мониторов с прямоугольным пикселем будут?

> > gtk3 пока зовется иначе(и двояко :)

> Qt 4?

Это gtk1.5

> Это gtk1.5

К сожалению (или наоборот) такой версии gtk не было. ;-)

Ба, да ты видать молод-зелен, раз 320х200 не помнишь ;)

Возможно. Мониторов с таким "родным" разрешением я точно не помню.

Хм, а ты не помнишь, что у ЭЛТ мониторов нет родного разрешения? Тогда ты ещё более молод, чем я осмелился предположить

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

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

А теперь будет в пол экрана?

/me ушёл за линейкой мерить скроллбар на своём десктопе.

> Мозг не резиновый и бесполезным знаниям в нем не место.

а полезные знания это какие ? ... где продают дешевое пиво ?

> Хм, а ты не помнишь, что у ЭЛТ мониторов нет родного разрешения? Тогда ты ещё более молод, чем я осмелился предположить

Применительно к ЭЛТ, "родное" разрешение - это разрешение, в котором квадраты квадратные, а круги круглые, как минимум. Потому что подразумевается, что монитор должен показывать правильные пропорции.

Специально для сильно медленных повторяю: если у тебя квадраты не квадратные, то это проблема не Cairo и не GTK, а монитора. Или, может, растровые изображения у вас тоже будет GTK3 выпрямлять?

> Применительно к ЭЛТ, "родное" разрешение - это разрешение, в котором квадраты квадратные, а круги круглые, как минимум.

Точнее сказать "родное" будет, когда res(x)/res(y)=width/height

> иначе тот же скролбар придётся с лупой искать

ну уж нет. Если на большом брате скроллбар 4 мм толщиной, то на КПК он мне нафиг не нужен такой толстый. И наоборот, если тема сделана под 200dpi, то на большом брате вся красота размажется по пикселям. И в конце концов, если я покупаю монитор с большим разрешением, то я собираюсь видеть на нем больше информации (и так шрифт выставлен такой, чтобы отличать запятую от точки), а не наоборот увеличивать шрифт.

Короче, кто без лупы жить не может, пусть для тех и выпускаются мониторы с крупными пикселями. А я и с 1600х1200 на 700ift себя отлично чувствовал.

Интересно мнение публики о уровне статей от IBM, которые публикуются тут переодически. Пошел по ссылке посмотреть, статья по кайро скорее обзорно-вводная, на учебник не претендует. Стал смотреть на другие документы - их там тьма. Больше 200. В заголовках заявлены весьма интересные темы, но вот уровень содержания? Прежде чем начинать вчитываться, может прокомментит кто-то.

А то вот такие перлы несколько удивляют:

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

Уровень серии "Для чайников" :)

> Допустим у меня два монитора с одинаковым разрешением но с разным размером, как можно написать интерфейс задавая размер в миллиметрах, чтобы программа не вылезла за рамки меньшего монитора, или не стала выглядеть слишком нерационально на большем?

В оффтопике этот вопрос уже сто лет как решён. Все диалоги рисуются не в пикселях и не в миллиметрах, а в своих виртуальных единицах. А дальше задача GDI перевести эти единицы в пиксели, чтобы диалоги не разъехались, и квадраты с кругами остались квадратными и круглыми.

> нет общепринятого сокращения для DPI.

тнд (точек на дюйм)?

>В оффтопике этот вопрос уже сто лет как решён.

4.2. собственно. Там ещё метрику правильно указать надо. А указывают обычно PIXEL_METRIC (или как-то так). Ну и разъезжающийся при изменении размеров шрифта гуй в венде - явление обычное. Ну ниасилили индусы layout, что поделать

> 4.2. собственно. Там ещё метрику правильно указать надо. А указывают обычно PIXEL_METRIC (или как-то так). Ну и разъезжающийся при изменении размеров шрифта гуй в венде - явление обычное. Ну ниасилили индусы layout, что поделать

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

> Можно ли её (или какую нибудь другую библиотеку) использовать для отрисовки большого числа (сотни тысяч) точек соединенных линиями? Стоит задача в написании подобия аудиоредактора

Поставьте Jokosher и не извращайтесь :)

>>> Не знаю, как там сейчас во всяких визуал-басиках это делается

Вот, неполенился, сделал скрин диалога одной комерческой программы написанной на .NET и запущенной в WinXP

http://smages.com/3a/a4/3aa47cbb7bb17b8312408829304db19f.png.htm

В GTK+ такое сделать очень сложно :)

>Там всё было в каких-то своих единицах как раз для того, чтобы при смене шрифта ничего не расползалось.

Да да да, в MSDN уклончиво написано что "Диалоговая единица" это 1/17 системного шрифта при том что системный шрифт имеет как раз в 17 пикселей в высоту.