tinytlf tlf
В отличие от идиотов в Adobe, автор tinytlf нормальный, в tinytlf нет никакого asdoc в классах реализации — только в интерфейсах.
Понятный и удобный API (если мне нужно установить только ширину, я explicitWidth = newW, а не setCompositionSize(newW, NaN)).
Минусы только по оформлению кода — явно видно, что автор пользуется блокнотом/Flash Builder, а не IntelliJ IDEA.
Черт возьми, впервые за 5 лет испытал удовольствие от работы со сторонней библиотекой на ActionScript (mate не в счет). По привычке порывался при использовании писать свое, но чудо — интерфейсы тут не только для галочки. И даже абстрактные классы можно использовать как базовые (с Flex SDK и TLF это невозможно — интерфейсы не используются, типы параметров/свойств конкретные, а в случае с tlf добавляется еще и tlf_internal). Да — если в неком коде используются пространства имен — разработчика кастрировать, а также всех сопричастных (в моей библиотеке Cocoa используется пространство имен ui для ui component skin parts, но это лишь от бедности — все время не найду написать compiler extension для ast генерации в compile time — то бишь в runtime этот namespace никак не является частью API/рабочего кода). Использование пространств имен это отличный индикатор убожества архитектуры. Потому что с ними все эти высокотеоретические выкладки об ООП смываются и размываются — это даже не прострелить себе ногу. И отсутствие поддержки пространств имен для интерфейсов это показатель, да.
Помимо пула для textLine (reuse на уровне плеера, добавление/удаление из пула на уровне as), также есть пул для textBlock (только на уровне as, при написании своей реализации ITextBlockFactory, нужно знать об этом пуле и использовать его) — вот этого в tlf нет.
Есть хитрый момент с инвалидацией. TextEngine принимает необязательный параметр stage. Stage ему нужен как раз для валидации — как во флексе, отрисовка происходит не на каждое изменение данных, а в определенный момент времени. И tinytlf вешается на ENTER_FRAME и RENDER (какой раньше придет — пришел — отписались от обоих и render). Если мы используем tinytlf во флекс-приложении, где уже есть свой LayoutManager, делающий ту же работу, то нужно ли нам передавать tinytlf stage? Если текст не интерактивный — можно всю валидацию осуществлять в host component — он на updateDisplayList вызывает у textEngine render и все (тема встраивания text engine во flex component lifecycle (типа measure) обширна и в этот топик не входит, могу лишь сказать, что тут tlf sucks, а tinytlf берет пирожок). А вот если интерактивный — то ничего работать не будет (то бишь никакой отрисовки в ответ на действия пользователя) — ведь он будет ждать, пока его отвалидируют. Интересно, что в реализации RichTextField данный момент никак не решен (тупо передается stage — то есть возможен сценарий гонки — когда оно отрисуется до updateDisplayList). Решается написанием своего (патч автору еще не отправил).
А gestures — это песня. Вам не нужен ParagraphSelectionBehavior? Ну так не мапьте его — оставьте только CharacterSelectionBehavior и WordSelectionBehavior. Впрочем — управление курсором вкупе со ссылками из разных блоков — получается порнография. Потому что стека курсора нет, получается гонка и как результат вы на второй ссылке получите auto вместо button/ibeam. Вряд ли автор tinytlf поправит это (невоспроизводимо на обычных текстах), пока что на это забил.
Нерваное выделение текста, как и должно быть в Mac OS X —
juick.com
Черт возьми, оно умеет отрисовывать подчеркивания не как путь всегда обкуренных сотрудников Adobe домой — то прилеплено к глифам, то нет, а нормально — всегда с отступом.
И, да, кайфую от того, что когда-то исправил компилятор таким образом, что вектор созданный в виде литерала, является фиксированным (
juick.com ).
