Comments 74
Сам JUCE достаточно легковесный, чуть более 28 Мб.
Это сарказм?
Зачем, если есть Qt? Только из-за размера?
Все-таки учтите что для работы Qt приложений необходимо наличие библиотек Qt на машине пользователя.
Плюс Qt дает нам нативный интерфейс системы, а JUCE строит интерфейс достаточно необычный и отличающийся от интерфейса нативных приложений.
Плюс Qt дает нам нативный интерфейс системы, а JUCE строит интерфейс достаточно необычный и отличающийся от интерфейса нативных приложений.
Плюс Qt дает нам античный интерфейс системы
Ох, на дворе всё-таки 2014 и имеется уже QtQuick 2 (даже 2.2, для уточнения) позволяющий строить интерфейсы любой красоты и любой сложности с помощью фреймворк-О-независимого декларативного языка разметки QML. Со сложнейшей логикой интерфейса, благодаря подпискам на события. Всё то довольно сложно выразить в синтаксисе C++, даже если бы в Juice были такие инструменты. Кстати, Juice умеет динамически менять свойства объектов при изменении других свойств, на которые «подписаны» первые?
для работы Qt приложений необходимо наличие библиотек Qt на машине пользователя.
Можно поставлять необходимые Qt-библиотеки вместе с бинарником, совершенно не обязательно устанавливать весь фреймворк.
Вообще, если вы всё равно публикуете исходный код (не платить же $1200), можно статически скомпилировать и на выходе получите ровно один бинарник, запускающийся без каких-либо предварительных подготовок на любой системе одного семейства (xp, 7, 8, 8.1). Вариантов ещё больше, на самом деле.
Плюс Qt дает нам нативный интерфейс системы, а JUCE строит интерфейс достаточно необычный и отличающийся от интерфейса нативных приложений.
Я бы не стал записывать это в плюс, если честно.
Так же интерфейс Qt можно создавать только в предназначенном для этого приложении, а здесь я могу писать интерфейс в той IDE которая мне больше нравится. Хотя может с Qt то же так можно, врать не буду.
Интерфейс QML пишется руками, как и html вёрстка. Используете любой удобный блокнот и всё. Просто в Qt Creator этот блокнот умеет автокомплит и автоформат, а ещё контекстную помощь.
Спасибо за напоминание, QML я не рассматривал, как то он мимо меня прошел.
Вообще думаю это дело вкуса на чем писать GUI, целью моего топика было просто показать альтернативу и познакомить с достаточно не плохим решением. Думаю что все зависит от того как пользоваться инструментом.
Вообще думаю это дело вкуса на чем писать GUI, целью моего топика было просто показать альтернативу и познакомить с достаточно не плохим решением. Думаю что все зависит от того как пользоваться инструментом.
Вообще, на чём писать GUI, ИМХО, не только дело вкуса, а и удобства. Пусть некоторые и ругают Qt за монструозность, но объективно — это один из лучших (в плане удобства) фреймворков на сегодняшний день.
Я бы сказал он один из лучших с точки зрения богатства готовых классов. С их реализацией не все так круто, как кажется на первых взгляд. В частности, слабо реализован QtSql, хлебнули в enterprise-проекте. И встроенный набор моделей данных для чего-то больше нескольких тысяч записей решительно не годится.
Там фильтры тоже боль если нужна возможность фильтровать по нескольким столбцам. Когда работал то пришлось их реализовывать на стороне данных до Qtшной модели. Да и сами модели были не очень хорошо документированы в случае если данные произвольно меняются или вообще выкидываются из модели. Впрочем в целом Qt оставил скорее хорошие впечатления
Да и помимо QML можно писать интерфейс руками (а что рисуется в дизайнере, сохраняется в .ui и в явном виде перегоняется утилитой uic в обычный компилируемый .cpp).
А как оно внутри работает? Как Xamarin или как Qt?
Не совсем понял вопрос…
Я так понимаю, вопрос был в том, что он эмулирует родные контролы ios и android (как Xamarin), или рисует свои (как Qt).
Xamarin, например, на Android гоняет виртуалку Mono.
На сколько я знаю родные, по сути для взаимодействия с целевой системой фреймворк использует нативное окружение целевой системы. По край ней мере на Mac OS X Cocoa IOKit WebKit и т.д.
Так как если бы я писал приложение непосредственно как Native. По мобильной разработке мало что могу рассказать, потому что сам ей не занимаюсь.
Так как если бы я писал приложение непосредственно как Native. По мобильной разработке мало что могу рассказать, потому что сам ей не занимаюсь.
Вопросы по теме:
- Через что рендерится интерфейс? Как при этом обстоят дела с переносимостью? Например, в Windows – DirectX, в x86 Linux — OpenGL, в ARM Linux – OpenGLES2.0 и EGL, и так далее;
- Можно ли составить комонент из набора других компонент? Насколько грамотно применяется инкапсуляция и нет ли подводных камней?
- Вопрос я уже писал выше, можно ли вместо callback-ада построить event-driven систему подписок?
- Рендеринг идет нативными средствами, в Linux это X11, в Mac OS X это Cocoa, в Windows это соответственно WinSDK (точнее сказать не могу, под окошками еще не смотрел подробно)
- Подводные камни думаю есть везде, вопрос о грамотности того или иного метода и подхода думаю немного субъективен а в остальном не думаю что могут быть какие то трудности.
- По этому вопросу затрудняюсь ответить.
Впринципе если кому то интересно, то пожалуй стоит рассмотреть некоторые моменты по подробнее и добавить дополнительную статью.
При работе с этим фреймворком на примере
Есть какие-то примеры более сложного приложения?
MainComponent::buttonClicked, если на форме есть 15 кнопок, этот метод превращается во многоэтажный if или switch? Или потребуется дополнительно воспользоваться дарами STL/boost для упрощения такой конструкции?Есть какие-то примеры более сложного приложения?
Возможно это решение которое вы искали
myButton->addButtonListener (ButtonListener*)
Описание слушателя для Button
По сути вам нужно просто передать указатель на нужный слушатель, а наделать их вы можете сколько угодно.
Нужно будет создать класс-компонент наследуемый от public ButtonListener, описать в нем соответствующую реакцию на событие и передать экземпляр это класса для регистрации в вашей кнопке.
void Button::addListener ( Listener * newListener )
По сути вам нужно просто передать указатель на нужный слушатель, а наделать их вы можете сколько угодно.
Нужно будет создать класс-компонент наследуемый от public ButtonListener, описать в нем соответствующую реакцию на событие и передать экземпляр это класса для регистрации в вашей кнопке.
И снова свой String… Мало им std::string, что-ли?
Тут уж кто на что горазд, мы все думаем что сможем сделать лучше и удобнее чем другие.
Чтобы потом пришлось самому корячиться писать всякие методы типа split() для связи с внутрифреймворковым классом регулярных выражений и таким же классом массива, например?
Это уже традиция во фреймворках…
Надо признать, что std::string довольно убог, когда дело до ходит до кодировок и всяческих манипуляций со строками, как с символами, а не набором байт.
Для этого есть
std::wstring. Неужели какой-то сишный фрейморк может предложить хорошую манипуляцию с символами, оставаясь в multi-byte кодировке?Если текст получаем из внешних источников, то это почти всегда UTF8. Это стандарт де-факто. (Правда иногда бывает с BOM. А иногда без него.) Никто не сохраняет исходники, текстовые, файлы, стевые ресурсы в UTF-16.
Но иногда кто-то все-таки сохраняет. И не только в 2х UTF-16, так еще и в национальных кодировках. А внутри, если дело касается работы с текстом, как с текстом, желательно все хранить в одном виде. Иначе ни о какой обработке не может быть и речи.
А еще с Юникодом бывают всякие прикольные фишечки, когда одна и та же строка может быть закодирована разной последовательностью байт. И UTF-16 тут не спасает. Нужно уметь строки нормализовывать, чтобы, например, сравнивать.
У Qt хорошая поддержка работы со строками. С std::(w)string даже сравнивать нечего.
Но иногда кто-то все-таки сохраняет. И не только в 2х UTF-16, так еще и в национальных кодировках. А внутри, если дело касается работы с текстом, как с текстом, желательно все хранить в одном виде. Иначе ни о какой обработке не может быть и речи.
А еще с Юникодом бывают всякие прикольные фишечки, когда одна и та же строка может быть закодирована разной последовательностью байт. И UTF-16 тут не спасает. Нужно уметь строки нормализовывать, чтобы, например, сравнивать.
У Qt хорошая поддержка работы со строками. С std::(w)string даже сравнивать нечего.
Для всего этого не нужен свой класс строки. Просто добавьте нужный функционал как глобальные функции, принимающие std::string/wstring (а еще лучше — basic_string). Вообще, пихание всей подряд функциональности непосредственно в класс, даже если ей не нужен доступ к private состоянию — это не C++ way.
Зато со всеми этими классами строк постоянно проблемы, когда нужно подружить два фреймворка. Понятно, что можно преобразовать типы, где надо. Но это 1) геморрой, и 2) дорогое и ненужное копирование данных.
Не пишите свой класс строки на C++. Пожалуйста.
Зато со всеми этими классами строк постоянно проблемы, когда нужно подружить два фреймворка. Понятно, что можно преобразовать типы, где надо. Но это 1) геморрой, и 2) дорогое и ненужное копирование данных.
Не пишите свой класс строки на C++. Пожалуйста.
Тем не менее, конструктор QString(const char*) конвертирует входную UTF-8 строку в цепочку 16-битных символов. Может, есть более «правильный» фреймворк?
Просто перекладываем грабли чуть подальше от дома.
Скажем: «Нет!» std::wstring. Он не затыкает дырки в абстракции символов, а делает только хуже, позволяя недальновидным личностям дальше воображать, что строки — это массивы символов. Даже UTF-32 — это потенциально многобайтовая кодировка (см. про комбинирующиеся модификаторы и нормализацию).
Если строку вообще надо разбивать на отдельные символы (я даже не могу вот так сразу назвать юз-кейс, где это необходимо), то мы знаем кодировку строки и имеем специальный набор функций лично для этой кодировки. А не обобщённый тип «строка».
Если строку вообще надо разбивать на отдельные символы (я даже не могу вот так сразу назвать юз-кейс, где это необходимо), то мы знаем кодировку строки и имеем специальный набор функций лично для этой кодировки. А не обобщённый тип «строка».
Увы, Qt не переплюнуть хотя бы из за размера сообщества и обилия хелпов. Когда то были подобные кросплатформенные wxWidgets — и тоже были задавлены Qt.
Какие у JUCE есть киллер-фитчи, выделяющие его среди других?
В массивном (хоть и хорошо спроектированном) приложении этот паттерн будет не слишком удобен. В этом плане в Qt сигналы хорошо вписались.
quitButton->addListener (this);
В массивном (хоть и хорошо спроектированном) приложении этот паттерн будет не слишком удобен. В этом плане в Qt сигналы хорошо вписались.
Спасибо, конечно за обзор (не сарказм), но зачем JUCE использовать вместо Qt действительно не понятно.
зачем JUCE использовать вместо Qt действительно не понятно
Некоторые любят самоистязания — это для них.
Например, далеко не всем нравится то, что QMake делает с кодом.
Простите за нескромный вопрос, а что QMake такого страшного может делать с кодом? Насколько мне известно, разработка на C++/Qt не привязана к какой-либо системе сборки: если чем-то не устраивает QMake — всегда есть альтернативы в виде CMake или новоиспеченного qbs.
UFO just landed and posted this here
Да, qRoC прав я про moc. Не то чтобы это было сильным недостатком Qt, но отсутствие moc для многих будет весомым плюсом ее конкурентов. Собственно, мне кажется, что программисты терпят moc только потому, что привыкли к неведомой фигне, генерящейся в обилии разными IDE.
Binary builder напомнил мне о временах моего раннего детства, когда я программировал на бейсике, а картинки перепечатывал из книги, вручную забивая data массив.
Думаю что тем кто только начинает осваивать кроссплатформенные GUI приложения на C++ будет интересно узнать об альтернативе таким монстрам как Qt или таким старичкам как GTK+
Qt на 3 года старше GTK+. Кто тут «старичок»?
Кроме того, хотелось бы попросить автора добавить немножко знаков препинания (в предложении выше можно добавить до 7 запятых и 1 точку).
еще есть к чему стремиться, однако
Эээ… это оно так на винде выглядит??
Т.е. оно даже и заголовки у окон само рисует вырвиглазным образом, вместо того, чтобы использовать нативный look & feel?
Т.е. оно даже и заголовки у окон само рисует вырвиглазным образом, вместо того, чтобы использовать нативный look & feel?
Наверное, это как-то настраивается, потому что заголовк у самого Introjucer обычный. Но по умолчанию — так.
Так скажем, это фишка Juce. Единый внешний вид вне зависимости от системы. Потому Juce и используют в основном музыкальные продукты, т.к. в них так принято, чтобы все контролы были свои, без привязки к системным. А весь остальной мир прикладного ПО смотрит с недоумением.
Использование title bar настраивается, какой именно использовать, так же настраивается отображение кнопок свернуть/развернуть/закрыть
Чего все так накинулись? Отличный проект, хотя бы потому что является альтернативой! Может кому-то «надоело» клепать GUI на Qt и тому подобных, хочется разнообразия(for fun)? :)
Как по мне, интересная вещица!
Как по мне, интересная вещица!
Насколько я знаю, основная фишка JUCE — это всевозможные audio / MIDI приблуды.
В частности, с JUCE очень круто делать аудио плагины (VST / audioUnit).
Там есть классы для простых синтезаторов, GUI для крутилок, фэйдеров и всего такого.
В частности, с JUCE очень круто делать аудио плагины (VST / audioUnit).
Там есть классы для простых синтезаторов, GUI для крутилок, фэйдеров и всего такого.
Мда, GUI дейсвтвительно ни на что не похож…
Попробую-ка я лучше на нём звук попрогать. Может хоть звук на что-то похож.
Попробую-ка я лучше на нём звук попрогать. Может хоть звук на что-то похож.
Ну альтернатив ещё достаточно:
EFL, Fox да тот же Guichan (очень просто и легко)…
Но как правило на десктопах столько нюансов… один словом только Qt более или менее всё разруливает. Для камерного применения подойдёт почти всё, что угодно, особенно если вам нудно GUI для VST плагина написать. Вон тот же ZynAddSubFX на FLTK вообще написан. ;)
EFL, Fox да тот же Guichan (очень просто и легко)…
Но как правило на десктопах столько нюансов… один словом только Qt более или менее всё разруливает. Для камерного применения подойдёт почти всё, что угодно, особенно если вам нудно GUI для VST плагина написать. Вон тот же ZynAddSubFX на FLTK вообще написан. ;)
Пока жив и развивается Qt он останется вне конкуренции. Все те возможности и стабильность, которую дает Qt нам сейчас, этот фреймворк (в таких же ± темпах) никогда не получит.
Sign up to leave a comment.
JUCE — Кроссплатформенный C++ фреймворк для разработки приложений с пользовательским интерфейсом