|
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
Паршивенько, ничего не скажешь. Я во флексе не силён, думал может какой-нибудь трюк хитрый использовали, чтобы без обёрток и всё тип-топ... Надо подумать чтобы сделать это с минимальными затратами. Пока в голову приходит идея режимов - инвалидация по ENTER_FRAME, по прямой команде, принимать в дисплай лист только обёртки...
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Цитата:
а автоматический пересчет размеров нужен как раз на сложных, да и фреймворк ты задумываешь как универсальный. У нас в проекте (много диалоговых окон, списков, кнопок, и немного другого) копромис: - подавляющая часть функций расстановки(иногда лайаутов) запускается принудительно - после закидывание в контейнер компонентов - некоторые компоненты(их не много), любящие менять размер при изменении данных, посылают событие RESIZE и снаружи компонента, если перехватили это событие - девалидируем главный контейнер. Т.е. если элемент может сказать об изменении своего размера/положения - он говорит, если не может - считаем что он не менялся - и не надо ни каких оберток. Фишка в том, что много элементов которые не меняют размеры после добавления (статические текстовые поля, картинки) Если их оборачивать - только лишний код будет и постоянная путаница оберток и компонентов, ими оборачиваемых Последний раз редактировалось expl; 22.08.2010 в 13:06. |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Ага, склоняюсь примерно к такому же варианту. Хочешь - пускай Event.RESIZE бабблится, хочешь - не пускай.
А чем плох вариант с ENTER_FRAME по желанию? У меня скроллпейн будет дисплей обджект контейнером, т.е. его width будет показателем реальной ширины, например.
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Регистрация: Jun 2008
Сообщений: 204
|
Начинаете изобретать велосипед.... понятненько. А взять aswing или minimalcomps посмотреть и улучшить? не?
Насчет валидации, оберток и тд. Отложенная перерисовка после изменения каких-либо свойств виузального объекта, это наверное лучшее что можно вынести из фреймворков. Если у вас возникает путаница "между обертками" то это возникает или из-за неправильной архитектуры фреймворка, либо путанице в голове. |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
shaman4d, как Вы думаете, что быстрее: посмотреть aswing и понять, как оно работает или написать свой? Вы предпочтете тащить за собой 300кб никому не нужного фреймворка ради аналога SimpleButton`а?
И кстати, желание минимализировать число необходимых обёрток без потери функционала - это очень хорошо. Причем тут путаница - я совсем не понял.
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Регистрация: Jun 2008
Сообщений: 204
|
Цитата:
Цитата:
Ради SimpleButton я выдеру из асвинг и перепишу к примеру. Хотя кнопка наверное не очень удачный пример, потому как кнопка слишком проста, а вот набор окон, меню - ради этого 300кб не жалко, особенно когда ролики с ютуб уже весят намного больше и никто не кричит что об этом |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Ну я же вроде написал, что мне требуется только
Я просто прикинул что мне нужно то, от фреймворка: Цитата:
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Цитата:
но прикольно Цитата:
- Начинаем делать проект, ура! - Понимаем что нужны GUI-компоненты - Но нужны компоненты, которые можно быстро переточить в любом направлении - Выбор: 1. Брать и разбираться со swing, возможно сэкономив время на написание и лазить потом по нему в попытках написать/допилить кнопку или скролл-бар со специфичным скином, потом трястись - позволяет ли в принципе архитектура этого свинга того, что мы сейчас захотим? 2. Потратить больше времени, написать топорные компоненты, но зато в любой момент легко модифицируемые из-за их топорности Вот что выбрать? Топорные компоненты вроде уже делали, а со свингом можем огрести проблем на середине проекта. Вот и все. Если ты до этого изучил этот свинг и знаешь все его подводные камни - тогда конечно - выбор за вариантом 1. (Руки не доходят поковырять его поосновательнее) Ну а minimalcomps - там подсматривать даже нечего: - скины зашиты - шрифты тоже зашиты - систему валидации размеров? Да там ее практически нет - потому что лайаутов нема, оно и не надо. (а те что есть - HBox и VBox - это бесполезные "как-бы раскладки", выполняющее 1% обязанностей от флексовых HBox и VBox, других нет и в помине) - ну разве что посмотреть, что отрисовывать изменения лучше в следующем кадре, а не после срабатывания сеттера - но это основной принцип всех GUI-фреймворков, самая сложная часть - это всетки управление валидацией размеров - а её нет. Последний раз редактировалось expl; 22.08.2010 в 20:50. |
|
|||||
Et cetera
Регистрация: Sep 2002
Сообщений: 30,784
|
На это нет времени. К тому же, краткий курс для молодого бойца длится не более пары дней.
|
Часовой пояс GMT +4, время: 21:03. |
|
« Предыдущая тема | Следующая тема » |
|
|