LXDE переносят на Qt, планируется совместимость с Wayland

я пробовал на gtkmm (это С++ биндинг к gtk+) и qt.

В qt мешать с STL плохо получается. долго и громко метерился.

gtkmm полностью совместима с STL и можно не задумываясь использовать нужные контейнеры и алгоритмы.

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

У тебя что-то с руками. Qt отлично совместима с stl и модули можно делать тулкитонезависимыми.

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

А если ещё немного уменьшить связность логики и интерфейса, то и с Qt без проблем можно делать тулкитонезависимую логику. Во всяком случае skype без проблем использует Qt только в линуксовой версии, а QtCreator без проблем работает с libclang и это никак не задевает libclang.

У тебя что-то с руками. Qt отлично совместима с stl и модули можно делать тулкитонезависимыми.

Просто он видимо пишет в стиле

// Интерфейс логического модуля
std::vector<std::string> list_something(bool verbose);

// UI
tableView->setContent(list_something(false));

Разумеется, при такой сильной связанности логики и интерфейса с Qt будет неудобно.

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

Он скорее всего имел ввиду не то, что QVector вполне себе можно использовать с std::for_each и другими алгоритмами через итераторы, а то, что напрямую нельзя использовать std::string, std::vector и прочтие std::list - только через адаптеры типа QString::fromStdString() или QVector::toStdVector(), что требует дополнительных ресурсов на копирование.

Но это так, предположение. libastral не последней версии.

напрямую нельзя использовать std::string, std::vector и прочтие std::list - только через адаптеры типа QString::fromStdString() или QVector::toStdVector(), что требует дополнительных ресурсов на копирование.

Копирование кучи разных списков — это и есть чрезмерная связанность логики и интерфейса. В таких случаях можно уже всё писать на Qt без STL.

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

А если ещё немного уменьшить связность логики и интерфейса, то и с Qt без проблем можно делать тулкитонезависимую логику.

да со всем можно. вопрос в объёме дополнительного кода на прослойку.

В таких случаях можно уже всё писать на Qt без STL.

как-то не хочеться много кода переписывать.

нельзя использовать std::string (в glibmm Glib::ustring намного лучше совместим с std::string ).

что-то не видно интервальных конструкторов у QVector и т.д.

что-то не видно интервальных конструкторов у QVector и т.д.

Что-то, простите?

да со всем можно. вопрос в объёме дополнительного кода на прослойку.

У нормальных людей эта «прослойка» называется API и не создавать её считается плохим тоном. Разумеется, у индивидуальных разработчиков и слабых команд разработчиков на этот счёт другое мнение: они думают, будто смешивать логику и интерфейс до полной неотделимости — это круто. В результате в их коде годами не исправляются очевидные баги и годами проводятся попытки интегрировать стороннюю библиотеку заместо своего прибитого намертво велосипеда.

В qt мешать с STL плохо получается.

Неосилятор

нельзя использовать std::string (в glibmm Glib::ustring намного лучше совместим с std::string ).

Открой для себя QByteArray

Что-то, простите?

Он имеет в виду конструктор, принимающий два итератора

что-то не видно интервальных конструкторов у QVector

точно, столкнулся пару раз. было обидно.

Что-то, простите?

конструктор вида: std::vector(iterator begin, iterator end), есть у всех контейнеров в STL, у контейнеров Qt нет. Пережить можно, но, как выше писал, было пару раз обидно.