Здравствуйте. Вот уже несколько дней в моей голове вертятся мысли об идеальной библиотеке построения пользовательского интерфейса. Мысли такие меня посещают каждый раз, когда сталкиваясь перед выбором и не нахожу истинно правильного решения. В данном случае я встал перед выбором сабжа. Проведя маркетинговые изыскания я не нашёл ни одной идеальной библиотеки (это субъективное высказывание, относящееся только ко мне) при довольно неплохом выборе. Использовать несколько у меня не получается ввиду того, что это потребует больше времени на хотя бы изучение. А его у меня мало (Не подумайте ничего плохого, просто по жизни мне приходится очень многим заниматься и освоить всё времени действительно не хватает. Поэтому и приходится рывками бросаться то на одну тему, то на другую. Я за эти два года что сижу на форуме свой родной С++ не намного лучше стал знать). Но это всё не интересные сопли   Так вот, недостатки у всех библиотек разные - от привязки к определённой среде до кривости реализации и цене. Посему начала зарождаться (что в принципе логично) идея создавать потихоньку свой ГУЙ. Посему не нарушая правил (дин топик - один вопрос) спрашиваю - Какой должна быть почти идеальная библиотека?.

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

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

Проектирование с точки зрения платформонезависимости. Естественно хочется на любой платформе иметь в наличии одну и туже библиотеку. Тогда возникает вопрос как быть - иметь три разные версии одной и тойже библиотеки или одну универсальную? Ну например я программирую каждую версию отдельно, пытаясь сохранить одну структуру, каждую компилирую отдельно и на выходе имею три разных дистрибутива. Или же я могу делать единую версию где #ifdef'ами я буду выбирать что компилировать, а что нет в зависимости от платформы.

Проектирование с точки зрения удобства работы. В любом случае мне придётся писать обработчики событий (например события по нажатию на кнопку 1). Так вот как лучше рганизовать механизм вызова этого события? Через карту сообщений или как то иначе (ммм... сокеты, семафоры или что-то в этом роде)? Какова должна быть роль пользователя в этом? Ну в смысле он сам должен прописывать те события, какие хочет или же что бы все события воникали, а обрабатывались бы только те, обработчики событий который пользователь описал. И тут же - делать библиотеку как основной инструмент или как вспомогательный? Это значит например вот такое:

Вариант 1

Вариант 2


Проектирование с точки зрения внешнего вида. Соответсвенно хотелось бы сделать красвые контролы, отличающиеся от системных. Да и что бы поддержка скинов была заложена изначально. Самая разумная мысль, которая может мне сейчас прийти в голову - эот использование SVG-файлов. Т.е. на каждый контрол в приложении создавался бы файл с его графическим представлением. Тут уж внешний вид приложения по идее должен быть ограничен только дизайнерскими возможностями программиста. Ну и естественно включить поддержку по-умолчанию пары-трёх скинов. Разумен ли такой подход? И следующий вопрос - где должны быть эти файлы - встраиваться в сам экзешник или в отдельную dll, которую придётся постоянно таскать за приложением?

В общем вот так   

Это сообщение отредактировал(а) UniBomb - 12.11.2008, 19:25

такой как WPF  


а как-же

Я иногда бываю непоследовательным в своих мыслях))) Это значит остановить свой выбор на том, что выбрано и 


Добавлено через 7 минут и 9 секунд
А насчёт WPF - я не дотнетчик....  

Вот это мне сейчас кажется наиболее разумным, т.к. конечному пользователю будет легче понаделать своих контролов (скажем круглые кнопки, ромбовидные кнопки, кнопки повёрнутые на n градусов и т.д.)... 

WPF... Угу, сбоку кажется что оно даже ничего так, но только сбоку. Я сам по себе всю сознательную жизнь на плюсах пишу, но по ходу сложившихся обстоятельств сейчас веду проект на .NET/WPF.... Ну.. если бы GUI-библиотека на плюсах жрала бы столько ресурсов и имела бы столько глюков с ActiveX-компонентами, я бы уже давно перешел на что-то другое.
А так да, идея неплохая, много чего получается очень привлекательным, но с другой стороны многим приходится жертвовать. Думаю, каждому инструменту свое место.
А по поводу темы топика, не надо ничего придумывать, если каким-либо инструментом владеешь на достаточно высоком уровне, то спрыгивать или придумывать что-то новое особо не вижу смысла. Вон недоделанных библиотек сколько на сорсфорже, а ведь авторы могли взять какую-то уже развитую библиотеку готовую и дописать туда контриб какой-нибудь, который бы реализовывал то что хочется. А вместо этого получили кучу мертвых проектов..
ИМХО

ЗЫ: вобще споры на тему инструментов разработки дело неблагодарное...

так я и не затеваю спор))) Я просто хочу узнать признаки хорошей библиотеки))



ТОгда почему живут KDE и GNOME? Зачем нужны компиляторы от мелкомягкого, интела, борланда и гцц? Зачем нужны десятки дистрибутивов линукса? Да и вообще зачем нужны QT, VCL, MFC? Ведь есть же WxWidgets. Я это к тому, что кому то было интересно заниматься разроботкой того, чьего аналог уже есть. Плюс разработчик хотел внести что то своё. Вот и у меня примерно также...

кроме "почти идеальной" мне нечего сказать. Для начала определись с целями, они и будут, в свою очередь, определять преимущества и недостатки твоей библиотеки

и не очень увлекайся с наследованием, ибо "Favor 'object composition' over 'class inheritance'." (Gang of Four 1995:20)

ну а какие тут могут быть цели? Цель всего одна - строить ГУЙ...



а вот это я не понял   

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


Это цитата из книги "банды четырех" "Паттерны проектирования": предпочитайте композицию наследованию. Но если ты с паттернами не знаком, то начинать с этой книжки сложно
Мне по этому поводу понравилась "Шаблоны проектирования" Алан Шаллоуей, Джеймс Р. Тротт, хоть они и несколько фанатичная
в двух словах словах эта фраза обяъсняется так:
при наследовании ты связываешь все классы иерархии, потому что между ними меньше ограничения по доступу (protected), по сравнению с внешними классами. Отсюда сильная зацепленность (coupling): изменив один из классов ты рискуешь вносить изменения во все классы иерархии (в худшем случае). При композиции (когда поле класса является объектом другого класса) ты работаешь с ним через публичный интерейс - твои 2 класса меньше связаны
Наследование нужно, если ты будешь использовать полиморфизм (при этом базывай класс будет, скорее всего, пустой, т.е. только будет определять интерфейс) или, например, чтобы не писать одно и то же в куче классов (т.е. наследники будут делегировать выполнение некоторых действий базовому классу, в некоторых языках для этого наследование не нужно)

слов явно больше двух  

посмотри на библиотеку Shoes, она для руби и представляет из себя DSL(Domain Specific Language) для создания пользовательского интерфейса в декларативном стиле, да и автор - зачетный чел  

а, в этом смысле. Ну тогда да - цели избавится от недостатков предшествующих библиотек   



занятная штука, правда детально я её ещё не успел рассомотреть.



В общем, товарищи, тема временно принимает характер решённости, но вопросов меньше не стало. Просто по закону подлости - как появляется желание что-то сделать исчезает свободное время... Думаю через-полгода - год я эту тему снова подниму и мжет быть даже чем-нибудь похвастаюсь   

Ну как, не появились ли какие новые мысли по теме? Решился?)))

ReFLeXive, ну как сказать... Поигрался я немного с WinAPI, поколдовал чуть-чуть со свойствами формы. Дальше пока не продвинулся. Просто как то времени нет. Да и потом с тех пор QT стала бесплатной - посему смысла что-то глобальное делать уже нет. Всё равно QT переплюнуть несмогу. Но желание колдовать осталось и если что-нибудь и разразиться, то будет это скорее всего настолько эзотерическим, что практически нежизнеспособным    Онли фор фан, как говориться.

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

ReFLeXive, идеала вообще в принципе нет. Если я создам свою библиотеку, в которой я исправлю то, что мне непонравилось в других библиотеках, то где гарантия, что я своих кривостей непревнесу?