Ты имеешь ввиду сделать композицию?
Паршивенько, ничего не скажешь. Я во флексе не силён, думал может какой-нибудь трюк хитрый использовали, чтобы без обёрток и всё тип-топ...

Надо подумать чтобы сделать это с минимальными затратами. Пока в голову приходит идея режимов - инвалидация по ENTER_FRAME, по прямой команде, принимать в дисплай лист только обёртки...

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

У нас в проекте (много диалоговых окон, списков, кнопок, и немного другого) копромис:
- подавляющая часть функций расстановки(иногда лайаутов) запускается принудительно - после закидывание в контейнер компонентов
- некоторые компоненты(их не много), любящие менять размер при изменении данных, посылают событие RESIZE и снаружи компонента, если перехватили это событие - девалидируем главный контейнер.
Т.е. если элемент может сказать об изменении своего размера/положения - он говорит, если не может - считаем что он не менялся - и не надо ни каких оберток.

Фишка в том, что много элементов которые не меняют размеры после добавления (статические текстовые поля, картинки)
Если их оборачивать - только лишний код будет и постоянная путаница оберток и компонентов, ими оборачиваемых

Ага, склоняюсь примерно к такому же варианту. Хочешь - пускай Event.RESIZE бабблится, хочешь - не пускай.

А чем плох вариант с ENTER_FRAME по желанию?
У меня скроллпейн будет дисплей обджект контейнером, т.е. его width будет показателем реальной ширины, например.

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

shaman4d, как Вы думаете, что быстрее: посмотреть aswing и понять, как оно работает или написать свой? Вы предпочтете тащить за собой 300кб никому не нужного фреймворка ради аналога SimpleButton`а?

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

Про путаницу цитата выше.

Ради SimpleButton я выдеру из асвинг и перепишу к примеру. Хотя кнопка наверное не очень удачный пример, потому как кнопка слишком проста, а вот набор окон, меню - ради этого 300кб не жалко, особенно когда ролики с ютуб уже весят намного больше и никто не кричит что об этом :)

Ну я же вроде написал, что мне требуется только
Я просто прикинул что мне нужно то, от фреймворка:
и ничего больше.

Хех, в этом что-то есть, оно и легкие ентерфреймы гонять не камильфо,
но прикольно :)


Как оно обычно происходит:
- Начинаем делать проект, ура!
- Понимаем что нужны GUI-компоненты
- Но нужны компоненты, которые можно быстро переточить в любом направлении
- Выбор:
1. Брать и разбираться со swing, возможно сэкономив время на написание и лазить потом по нему в попытках написать/допилить
кнопку или скролл-бар со специфичным скином,
потом трястись - позволяет ли в принципе архитектура этого свинга того, что мы сейчас захотим?
2. Потратить больше времени, написать топорные компоненты, но зато в любой момент легко модифицируемые из-за их топорности
Вот что выбрать?
Топорные компоненты вроде уже делали, а со свингом можем огрести проблем на середине проекта.
Вот и все.

Если ты до этого изучил этот свинг и знаешь все его подводные камни - тогда конечно - выбор за вариантом 1.
(Руки не доходят поковырять его поосновательнее)

Ну а minimalcomps - там подсматривать даже нечего:
- скины зашиты
- шрифты тоже зашиты
- систему валидации размеров? Да там ее практически нет - потому что лайаутов нема, оно и не надо.
(а те что есть - HBox и VBox - это бесполезные "как-бы раскладки", выполняющее 1% обязанностей от флексовых HBox и VBox, других нет и в помине)
- ну разве что посмотреть, что отрисовывать изменения лучше в следующем кадре, а не после срабатывания сеттера - но это основной принцип всех GUI-фреймворков, самая сложная часть - это всетки управление валидацией размеров - а её нет.

На это нет времени. К тому же, краткий курс для молодого бойца длится не более пары дней.