Идеальный мини-фреймворк
 

Сколько пишу код, всё больше понимаю, что его очень приятно писать, когда у тебя есть что-то маленькое, но очень полезное.

Например, аналог SimpleButton, только более прокачанный. Как здорово, когда достаточно создать кнопку, назначить ему upState и overState, потом надпись одной строчкой - Button#setText("Hello!"), а она сразу же отцентрируется. А по надобности - отключить кнопку одной строчкой, а она станет серой, что сразу видно - неактивная.

Короче, меня что-то в лирику потянуло. У меня есть запрос, такой как юзер-гуи-фреймворк, причем очень лёгкий, мелкий, легкодопиливаемый, шустрый... короче, не флекс :)

Требования к нему:
Все компоненты должны быть легко скинируемы, причем, хочется что то вроде SkinManager, где есть дефолтный скин для каждого компонента - чаще всего в любом приложении 95% всех кнопок отличаются только надписями на них - который легко можно поменять в рантайме (без крайностей, конечно, вроде изменения всех кнопок с дефолтным скином при его смене), ну и другие скины, если надо. Причём каждый компонент может иметь "свои" шкуры, о которых SkinManager может и не знать (например, 40 кнопок вещей в инвентаре, зачем нагружать SkinManager 40 лишними шкурами?).
Нужна ерунда вроде Alert`а, блокирующего интерактивность, всякие массовые загрузчики и визуализаторы к ним, которые можно засунуть в Alert и смотреть как тикают проценты от загрузки того, что мы хотим.
Всё это дело должно работать красиво, я имею ввиду всякие инвалидаторы и прочие свистелки.

Короче, запросы у меня высокие. Кто нибудь знает, что нибудь близкое к тому, что я хочу? Если да - поделитесь, буду крайне рад. Хочу ещё чтобы всё было централизованно, поэтому меня не устроят разные единичные классы, которые работают сами-по-себе.

Сам я не нашел ничего подобного и видимо, придется это дело писать самому, почему у меня возникают вопросы, как бы это делали Вы.
Как бы это сделал я:
YourClass extends UIComponent extends Sprite, где UIComponent - это мой класс.
Думаю сделать в нём методы, которые будут во всех компонентах, такие как enable, disable, etc.
В конструкторе будет вызов SkinManager`а, с просьбой "приготовся к работе", если он ещё не был.
В каждом из компонентов в конструкторе должен будет передаваться интерфейс ISkinnable, который будет который будет скинировать, выдавать его будет SkinManager. Если было передано null - используется дефолтный скин. Если он не был назначен - SkinManager обращается к экземпляру класса, который требует шкуру и просит дать ему эту шкуру. Это ради того, чтобы при добавлении нового компонента не нужно было менять SkinManager, а просто сделать метод getDefaultSkin().

Как то так я это дело вижу, но нутро мне подсказывает, что где то здесь есть кривость.
Например, меня смущает ISkinnable, потому что в нём придется реализовать массив ДисплейОбджектов, а что где используется придётся смотреть по комментариям - не айс. Я не знаю, насколько это плохая идея, вытворять SkinManager.register(skin:Skin) - где Skin это экземпляр класса. Других вариантов, кроме как правкой кодом при измене чего либо для универсальности не вижу, может быть не правильный подход.

В общем, уже итак много букв написано, интересно ваше мнение.

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

В 99% скины НЕ надо менять в рантайме
Чем делать отдельно классы скинов раз в 10 гибче и проще
Сделать компонент, который легко поменять при наследовании и который содержит достаточно методов для скинования, наример upBitmapData, downBitmapData и т.д.
Т.к. при компонентах сложнее кнопки в 50% после получения дизайна от художников этих полей НЕ хватает для правильного позиционирования частей компонента внутри него - делаем наследника и там позиционируем

Как это легко скиновать без скинов каждый раз при создании кнопки?
Очень просто!
Делаем статичную фабрику, называем ComponentFactory
и лепим ей поля:
Потребовалась кнопка "скина" Simple - вызываем getSimpleButton("button") - PROFIT!

А настраиваем параметры для конкретного вида внутри этих методов.
Не хватает настроек для воплощения задумки дизайнера? - Создаем новый класс с интерфейсом ICommonButton - наследуем от чего хотим
И меняем единственный метод - getSimpleButton(text:String).
(а со скинами пришлось бы "растачивать" систему скинования, добавляя новый функционал)

P.S. Имхо если создавать отдельные классы скинов - никогда в них не заложишься функционалом настолько, чтобы покрыть всю творческую мощь дизайнера :)

У товарища bit-101.com (или какого-то другого, тоже умного) был какой-то симпл гуи или мини гуи...

Еще ВКонтакте гуи :-)

Еще у Яху был.

И вообще-то надо побаиваться таких фреймворков, они в ряде случаев напротив, будут связывать руки.

А вообще лучше не усложнять и использовать Флекс. Это крайне разумно, я считаю.

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

А вот тулзы делать НЕ на флексе - это маразм, в нем с гуи запарок нет, лайауты, опять же, нормальные (хоть и не без глюков, но они мало проявляются)

Годятся только для лепки слайдеров при отдельных экспериментах с настройками эффектов, ну может в дебажной панели можно испольозовать,
потому как скинование - нулевое, набор очень скудный, ее пытаются дополнять компонентами, но не теми, которые нужны (зачем, например, может понадобиться индикатор в виде горящей лампочки или вольметра?)

Вроде бы самое необходимое есть - но АПИ-тихий ужас, и скинование, опять же, нулевое.

Может я тебя не так понял (можно на ты?), но я как раз и имел ввиду что если в SkinManager`е поменяю скин с идом 1 на другой, то плевать на то, как себя поведут компоненты с этим скином, т.е. заниматься миссионерством и доведения до крайних идиалов я не хочу) Но вообще, если исходить из того, что ты процитировал я имел ввиду что в рантайме поменять надпись на кнопке с "открыть" на "закрыть" =)

По поводу фабрики - не хочу, потому что это подразумевает конечное число скинов для чего либо. Мощи дизайнера в моём варианте мне нравятся больше: не каждый день обычная кнопка с 3 стетйтами превращается в молюска, поэтому я думаю с моим подходом тут удачней: просто наследуюсь от компонента кнопки и переправляю функционал создания дизайна... Вообще думаю при правильной организации переправка функционала конструирования визуальной части это наиболее низкоуровневое, а значит и наиболее удачное из "нестандартного" скинирования. В 95% мне должно хватить стандартного функционала, в остальных 5 я готов полностью или частично переправлять конструкцию. Но за идею спасибо, подумаю, как обыграть.

MrPoma, как уже сказал expl скинирование везде нулевое. Мне как раз важно, чтобы за минимальное число действий я получал максимальный эффект в минимализме - что-то революционное я напишу с нуля под конкретный случай, речь скорее идёт о базовых наборах джентельмена которые меня уже конкретно достало переписывать/использовать старые наработки, которые приходится костылировать по нужде...

У меня есть такой) только пока закрытый. Но он очень узко заточенный под определённый проект. Есть - кнопки, кнопки с иконками, кнопки с лэйблом, кнопки с лэйблом и иконками, разные формы ( с титулом, без и.т.п.), чекеры, радиобаттоны и ещё чутть-чуть. скины описываваются в xml (не css) - поддерживается 9-scale, tiling.
Стиль всего гуи задаётся 1 этой xml и часто 1-единственной битмапой где склеены все эти шкурки.
Был соблазн делать что-то вроде mxml и css для варавниваний/позиций итп, но потом понял, что легче писать as-код конкретного компонента чем городить непонятно на каком языке без автокомплитов и валидации.
Используется для гуи в игре - тормозов от флэш особых нет, но и всяких вспыхиваний, уходов альфу итп свистелок/перделок тоже.
Мувиков и спрайтов почти нет - одна сплошная битмапа, которая отдаётся директиксу)

Хочешь - называй на ты.

Ну это само собой - надо поднатужиться и встроить текстовое поле в кнопку, ну и предусмотреть установку формата текста и других параметров (например, наложения фильтра на текст) для каждого состояния (нажата, отжата и т.д.)

Ничего НЕ мешает сделать ее НЕ статической:
Можно прямо в кнопке слепить метод clone() и создавать кнопки с "эталонных".
Можно совсем жестко - скиновать через наследование - Делаем наследника кнопки, который задает нужные параметры и имеет более простые настройки при этом.
Это не чтобы переубедить, просто к сведению - самому ни разу не потребовалось,
т.к. сообщить какой-то особый скин часто нужно меню или еще какому повторно используемому компоненту, ничего не знающему о СтатичнойФабрике кнопок, а в него и так обычно передается класс рендерера с этой кнопкой, который все знает о СтатичнойФабрике кнопок.

Трабл в том, что придется делать еще и класс скина, поддерживающего этот "расширенный" дизайн, или я чего-то не понял?

http://www.minimalcomps.com/
http://flashcamo.flashartofwar.com/

Не понимаю - чем флекс так не нравится? Spark компоненты скинируются на ура. Баги? Ну с кнопками, чекбоксами, свистелками надо постараться эти баги найти...

я начал использовать www.aswing.org Пока что мне всё в нём нравится. SkinManager там присутствует.
Правда он не совсем мини и не совсем компактный. И напильником его надо.
Из плюсов.
1. Есть gui builder.
2. работает быстрее чем флекс.

2Котяра: в директ х? У тебя не флешевый фреймворк?

2Волгоградец: когда пишешь проект на чистом AS3 для какой нибудь игрушки и нужно добавить кнопку - тащить весь тяжеленный фреймворк для неё мягко говоря нелогично.

2shaman4d, не понравились =( Флэш камо вообще RTE шмалял как конфетки.

2expl, мысль уловил, я хотел сделать примерно так же, только с большим числом наворотов) Спасибо.

Nemo_c: да, интересно. Напрягает только что скинирование у него чисто по "цветам" - цвета задаются в коде, а не картинками битмапы.

фрэймворк флэшовый - на выходе swf получаем. Только выводим его через f-in-box подобную тулзу. Это для 3D игры используется( на скринах - гуй флэшовый). И ещё для одной неанонсированной.

У кнопки есть такая штука как иконка для каждого состояния своя. Делаешь её размером с кнопку. И допиливаешь класс кнопки таким образом что бы надпись позиционировалась в независимости от положения и размера иконки внутри кнопки.

Хотя, если нужно именно централизованное скинирование. То лучше конечно написать отдельный класс для такой кнопки, по всем правилам и логики фреймворка

Говорю же напильником надо дорабатывать. Но по мне лучше допилить этот фреймворк. Чем свой с нуля создавать.

Я просто прикинул что мне нужно то, от фреймворка:
1) Централизированное скинирование
2) Компонент: кнопка
3) Компонент: слайдер
4) Компонент: скроллпейн
5) Компонент: Алерт с блокировкой интерактивности

Всего-то, и ради этого тащить что-то серьезное вроде AsWing... Надо думать.

Тяжеленный фрэймворк? 1 Мб. Сделать через RSL - тогда swf возьмет файлы из кэша компьютера, если их нет - то скачает с сайта adobe. Но наверняка у любителей flash игр все нужные файлы лежат в этом самом кэше.

за то время, которое висит эта тема, успел бы написать свой (;

Меньше суток она висит)

Да и делом я занимаюсь в это время, у меня есть и другая работа. Да и болею я, мне лежать нужно )

aswing лучшая из существующих альтернатива флекс-фреймворку

у вас уже все есть, присядте и приведите все в порядок, что бы вы сами понимали как оно работать должно.

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

как-то маловато:
-а попапы и управление окнами
- прогрессы, ожидания
-richText - тоже нужен, чтоб и inline картинки выводил в тексте
-диалоги в приложениях нужны?, нужны, значит непростой алерт
....
....

вообщем чуть, почуть, вот и flexframework написали ))

2murz - я о том же.. да, например в моём фв всё задаётся из единого класса - шаг влево, шаг вправо, прыжок вверх -расстрел, но на то он и "ограничительная рамка работ" - ГОСТ, только и всего.

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

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

И да, для меня Алерт это сообщение, сообщение с кнопками да нет, любой дисплей обджект.. короче, для меня это многое)

А мы таки сгородили mxml/css. Жаль, правда, что оно умрет скоро.

если не секрет - почему?

Потому что в TZ не осталось тех, кто его знает вдоль и поперек.

Вот и я о том же. Выгода от написания внешних нагромождений резко падает с исчезновением инициаторов этих нагромождений)

фуф, я пишу нечто похожее в свободное время и начал было беспокоиться ))

а документацию написать... не?

А я вот кстати думаю, как написать скроллпейн.
В идеале я так думаю в него можно делать addChild, задав высоту и ширину самого скроллпейна, остальное он сделает сам.
Только вот при движении детей ширина и высота "контента" может меняться... Не вешать же на ENTER_FRAME проверку. Какие есть идеи?)

А при изменении ширины контента может понадобиться перерасположить детей :)

Перегружать set x и set y и вызывать внутри них что-то типа:
а в контейнере вызывать тяжолую функцию validate(), только если его девалидировали перед отрисовкой следующего кадра единожды
И можно еще вызывать при спрашивании размеров, если эта функция размеры контейнера пересчитывает(не дожидаясь начала перерисовки кадра):
Можно событиями - но дороже по ресурсам.
И ломать голову как сделать циклы валидации - инвалидации, чтобы оно не зациклилось
Подсматривать как это сделано - во флекс и aswing - я сам до конца не вкурил.

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

Да это ежу понятно.
Только если что-то большое требует скролла (ну, такие дела) - переределывать им всем геттеры-сеттеры на x, y не вариант.
x, y, scaleX, scaleY, graphics, width, height... Многовато будет. Причем для каждого объекта. А SimpleButton финальный, к тому же.

И перегрузка подразумевает изменение сигнатуры. Правильнее сказать "переопределение".

Ну дык, во флексе тоже на изменение положения/размеров НЕ флексового компонента контейнер реагировать не будет.

Если компонент о своем изменении не раскажет - кто же раскажет?
Только его обертка, если ее сделать. Ее можно и поверх объекта с финальным классом натянуть,
Про удобство такого подхода все понятно (и если сама кнопка вдруг вздумает изменить положение без внешнего присвоения x - ничего обертка не сможет сделать), но, тем не менее, можно сделать при необходимости.


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

Тут проблема больше не в x и y, а высоте и ширине - они чаще меняются - т.е. изменилась высота текстового поля - родитель должен отреагировать.

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

Надо подумать чтобы сделать это с минимальными затратами. Пока в голову приходит идея режимов - инвалидация по 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-фреймворков, самая сложная часть - это всетки управление валидацией размеров - а её нет.

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