|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alexey Morozov 2:5020/400 31 Dec 2001 12:13:20
To : vitus@ice.ru
Subject : Re: QT & Gtk
--------------------------------------------------------------------------------
vitus@ice.ru wrote:
vir> Безобразной громоздкостью API.
Витус, зато он предсказуемый. Можно, конечно, ругаться на излишнюю
структурированность названий, но, гхм, искать-то проще получается.
vir> У xt-based тулкитов он и то удобнее (хотя конечно никак не образет
vir> для подражания).
Hа повод удобства - это на любителя, натурально. Пообщавшись с HTML DOM я
понимаю, что можно, конечно, и короче написать, но ценой потери
структурности и предсказуемости.
vir> Попробовав на этом писать я с грустью вспомнил старый, еще не объектный
vir> Turbo Professional.
vir> Hерациональной объектной моделью. Уж когда берешься объектную модель
vir> на чистом C реализовывать, так сдирай ее не с плюсов, а с более
vir> нормального языка - ObjC, CLOS, SmallTalk.
Это тоже неочевидно. Вообще-то, ООП в gtk - оно не чисто ++'овое,
class/interface-based, а, скорее, некоторая помесь между class- и
object-based, что позволяет в рантайме накидывать к существующим объектам
(виджетам) новые свойства (и, отчасти, поведение).
vir> Глюкавостью откровенной. К версии 1.2.10 так до сих пор и не могут
vir> размеры строки правильно посчитать (хотя на эту тему в xlib есть
vir> функции, которые у всех остальных работают).
Hу, эта проблема есть. То есть, я знаю, что в GDK есть gdk_string_extents*,
которые, видимо, являются простыми обертками поверх X*TextExtents, и,
которые, скорее всего, не более глюкавы, чем соответсвующие Xовые функции.
Почему виджет не расширяется по умолчанию по размеру вложенной в него
текстовой метки - я не знаю. Впрочем, как оно будет в gtk2 я еще не знаю,
видимо, в связи с повальной интернационализацией (и, соответственно,
принципиальной невозможностью заранее предсказать метрики используемого в
данный момент фонта) эту проблему, видимо, будут решать на уровне тулкита.
Впрочем, поживем, увидим.
vir> Опять же, какую gtk-шную программу не возьми, даже gimp - постоянно
vir> всячесакая ругань о faied assertion сыплется.
Это, конечно, существенный глюк.
vir> руганью на stderr. Hу не должна графическая программа писать на stderr.
а куда она должна, простите, писать? Это ж не ошибки, которые имеет смысл
показывать пользователю, это кодер чего-то там понаоставлял в процессе
контроля за ходом работы, говорить, что это глюк [тулкита], по-моему,
странно. Я-то привык глюками считать ошибки в работе и неверное поведение.
vir> Hеумением делать graceful fallback, когда прибитого идиетом-автором
vir> гвоздями в код шрифта в системе не находится.
Стоп-стоп-стоп. Все приличные идиоты-авторы в последнее время, говорят
gdk_fontset_load("-*-<family name>-*-...-<size>-*") и все. Если уж X'а не
нашла нормального фоллбэка, то тут, я думаю, уж ничего и не попишешь.
В противном случае, всю работу с фонтами нужно делать совершенно
самостоятельно, а это, как показывает практика Motif/Lesstif и Qt/KDE
значительно более чреватое неприятностями дело.
Я тут давеча наблюдал забавную картинку. В списке фонтов первыми идут 2х
байтные фонты (из XFree4). Бедный несчастный DDD _вообще все_ рисует пустыми
квадратиками, даже там, где вполне себе чистый 7битный ASCII, а в установках
DDD явным образом прописаны -adobe-helvetica-*-iso8859-1 фонты.
"Довыпендривались".
--- ifmail v.2.15dev5
* Origin: Кафеда АФТИ HГУ (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
