LINUX.ORG.RU

U++ Framework 2020.1

 , , ,


2

3

В мае этого года (точная дата не сообщается) вышла новая, 2020.1, версия U++ Framework (Он же Ultimate++ Framework). U++ — кроссплатформенный фреймворк для создания GUI приложений.

Нововведения в текущей версии:

  • Linux бэкенд по умолчанию теперь использует gtk3 вместо gtk2.
  • «look&feel» в Linux and MacOS переработан и лучше поддерживает тёмные темы.
  • У ConditionVariable и Semaphore появились варианты метода Wait с параметром timeout.
  • Добавлена функция IsDoubleWidth для определения глифов UNICODE двойной ширины.
  • U++ теперь использует директории ~/.config and ~/.cache для хранения разного.
  • Добавлена функция GaussianBlur.
  • Модернизирован внешний вид виджетов в дизайнере слоёв.
  • Поддержка нескольких мониторов в MacOS и другие исправления.
  • В дизайнер добавлено несколько часто используемых виджетов, таких как ColorPusher, TreeCtrl, ColumnList.
  • Нативный диалог выбора файлов, FileSelector, переименован в FileSelNative и добавлен в MacOS (в дополнение к Win32 и gtk3).
  • Рефракторинг GLCtrl в OpenGL/X11.
  • Добавлена функция GetSVGPathBoundingBox.
  • PGSQL теперь может экранировать ? через ?? или использовать метод NoQuestionParams в целях избежания использования ? как символа подстановки параметров.

>>> Подробности

★★★★★

Проверено: alpha ()

классический вопрос - и чем лучше, допустим, того же wxwidgets. Если правильно понял - идеология одинакова(единый api для разных операционок)

Atlant ★★★★★ ()
Ответ на: комментарий от anonymous

на qml всё в две строчи пишется и выглядит нормально

Нормально это как? Полагаю под этим вы понимаете «СМАРИ КАКИЕ У МЕНЯ КРАСИВЫЕ И НЕОБЫЧНЫЕ ВИДЖЕТЫ», а не натив?

Im_not_a_robot ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Какая ОС реализует свою БД?

Я к тому, что не дело GUI-фреймворков заниматься ещё и базой (и всем тем барахлом, что даёт Qt, например, типе сети, мультимедии и т.п.). Потому что в итоге код выглядит не как апликация для операционки, а как апликация для фреймворка, а всё что бывает за пределами фреймворка, отбрасывается, как несуществующее впринципе.

Фреймворк же превращается в набор NIH-костылей.

AngryElf ★★★★★ ()
Ответ на: комментарий от anonymous

Конечно, лучше уродливые и банальные (как любой натив)

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

skiminok1986 ★★★★★ ()
Ответ на: комментарий от AngryElf

Qt всё же не gui-фреймворк по сути Да и исторически сложилось, что в stl нихрена нет, до сих пор (упомянутые тут нетворк и мультимедиа в частности) Многие вещи в кьюте были задолго до появления в stl (первыми на ум приходят смарт поинтеры) QString так вообще вне конкуренции и сейчас. Аналоги в stl менее функциональны.

anonymous ()
Ответ на: комментарий от anonymous

Большинство дефолта в большинстве дистрах смотрится в высшей степени убого( Есть исключения конечно, но меньше, чем хотелось бы

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

skiminok1986 ★★★★★ ()
Ответ на: комментарий от AngryElf

Всё так. Что ещё хуже, когда очередной фреймворк неизбежно ложится в могилу, вместе с ним автоматически захоранивается весь софт на нём, поскольку без фреймворка он самостоятельного смысла не имеет. Единичные исключения разве что только для проектов с особо интимными отношениями с их фреймворком, типа Gtk+Gnome или Qt+KDE.

d_a ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

d_a ★★★★★ ()
Ответ на: комментарий от AngryElf

не дело GUI-фреймворков заниматься ещё и базой (и всем тем барахлом, что даёт Qt, например, типе сети, мультимедии и т.п.)

+1,000,000!

Плюс, если ГУЙня хочет быть действительно широко используемой, ещё с самого начала проектирования надо думать о байндингах к другим языкам. Т.е. вся эта местечковая, наколенная ООПшка идёт лесом.

matumba ★★★★★ ()
Ответ на: комментарий от cetjs2

поддержка D есть?

Я б по этому вопросу вообще не парился. Сам Ди настолько прекрасен и мощен, что любой «байндинг» из него к ГУЯм будет выглядеть дверным глазком в Нарнию.

Надо взять и отбросив все предрассудки, написать на Ди одноплатформенный ГУЙ, используя все мощные концепции языка. ТОГДА эта библиотека будет гармонично вписываться в приложения, которые потом напишут. И конечно же, будет куда более развиваемой, чем если бы Ди-разработчик ковырялся бы в Сипиписных шаблонах и закорючках ситаксиса.

matumba ★★★★★ ()
Ответ на: комментарий от next_time

Некоторая разница в подходах, на вкус и цвет. Вот пример

Это не «пример различий», а тупо шмот кода на обеих библиотеках. Мне он ни о чём не говорит, а разбираться в этой простыне тем более нет желания. Если разрабы хотят показать «чем лучше», надо взять отдельный кусок кода и показать: вот на Qt это так, а мы делаем так. И плюсы-минусы обоих подходов.
Сегодня слишкм много пишется дилетантской тошнотины (зато С++!), которую следовало бы закопать ещё до появления.

Если ты выходишь в мир с очередным «убийцей Культей/Гытыкыков», ты должен быть готов внятно, с первых же страниц документации, объяснить свои концепции и чем ты «заборешь» другие либы.

matumba ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Так и запишем, @RazrFalcon анскильная лалка которая гордится этим. И никогда в своей жизни не видел ни одного MVVM приложения или MVU.

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

В моё время люди стыдились быть тупыми…

fsb4000 ★★★ ()
Ответ на: комментарий от anonymous

Qt всё же не gui-фреймворк по сути Да и исторически сложилось, что в stl нихрена нет, до сих пор (упомянутые тут нетворк и мультимедиа в частности) Многие вещи в кьюте были задолго до появления в stl (первыми на ум приходят смарт поинтеры) QString так вообще вне конкуренции и сейчас. Аналоги в stl менее функциональны.

Некоторые вещи, например потоки, в Qt не очень хорошо сделаны (можно было лучше), но вы правы Qt безнадежно обогнал stl.

Skullnet ★★★ ()
Последнее исправление: Skullnet (всего исправлений: 1)
Ответ на: комментарий от matumba

Сегодня слишкм много пишется дилетантской тошнотины (зато С++!), которую следовало бы закопать ещё до появления.

Да, например Д. Хотя он уже давно сдох на помойке, откуда никогда не вылезал, и где был дохлым и обосанным рождён.

minihic112 ()
Ответ на: комментарий от Skullnet

Некоторые вещи, например потоки, в Qt не очень хорошо сделаны (можно было лучше), но вы правы Qt безнадежно обогнал stl.

Сообщаю новость - qt - это си с классами дерьмо. Когда-то давно в С++ произошло разделение. Пту осталось с си с классами, а люди ушли вместе с С++.

Дак вот, stl не имеет никакого отношения к си с классами, к пту, к qt и прочей подобной херне.

Осознайте уже это и перестаньте нести херню.

minihic112 ()
Ответ на: комментарий от minihic112

Т.е. stl не пытается быть какой-то библиотекой для си с классами, которой является qtcore. Ей насрать на ваши потребности, на ваши птушные чаяния. Она развивается так, как нужно C++.

minihic112 ()
Ответ на: комментарий от AngryElf

В Qt некоторые подобные потуги были вынужденной мерой. С развитием плюсов уже и новый стиль сигнал-слотов ввели и, по тихоньку, от своих алгоритмов отказываются. Что будет дальше - время покажет.

hatred ()

Как копавшийся в кишках U++, скажу свой опыт. Дисклеймер: копался давно, может что-то и поменялось.

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

Плюсы:

  • нативный С++. Все фичи (ресурсы, гуй, схема БД) реализуются кодогенератором, препроцессором и компилятором. moc, сасат!
  • когда освоишься, довольно быстро и приятно пишется гуй
  • IDE всё-в-одном, её достаточно
  • много нужного под рукой - байндинги к БД, экспорт в PDF
  • небольшой размер для такой функциональности
  • пермиссивная лицензия
  • мейнтейнеры реагируют на пулл-реквесты

Минусы:

  • куча своих велосипедов. Они едут, но с ними нужно осваиваться
  • (туда же) аналог RTF с «птичьим» синтаксисом. Жуть.
  • (туда же) свой скриптовый движок, легко интегрирующийся с типами фреймворка. Тормознутый и со странностями
  • (туда же) система сборки. Сама по себе вполне неплохая. В давние времена пытались вычленить её в отдельную консольную тулзу, но не срослось. Без костылей собирается только из своего гуя.
  • монолит. Забудьте про общий .so с фреймворком. Если на выходе один бинарник - хорошо, если плагины - костыли
  • прыжки в сторону многопоточного гуя. Как по мне, это нах не нужно - хочешь фоновый воркер - пусть делает свою работу и не лезет в окна
  • постоянно тикающий таймер. А кто спать будет?

пока всё, что вспомнил

anonymous ()
Ответ на: комментарий от minihic112

Лучше Си с классами пока никто ничего не придумал для байндинга к другим языкам, выноса в .so, и стабильности ABI. Оффтоповый COM в этом до сих пор вне конкуренции.

anonymous ()
Ответ на: комментарий от minihic112

Хотя он уже давно сдох на помойке, откуда никогда не вылезал, и где был дохлым и обосанным рождён.

Так вот в чем причина твоей неадекватности! Прямо оговорочка по Фреду - тебя нашли на помойке дохлым и обоссаным. И теперь ты хочешь доказать всем что ты не лох. Пока у тебя получилось доказать что ты клоун только. Кстати, клоун, где твой блог на С++?

anonymous ()