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

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

Например, аналог 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. работает быстрее чем флекс.