C++/Qt: пора валить?.

image


Если бы раньше я запускал новый долгоживущий проект, в котором основные функции связаны с большим объёмом вычислений при каком-то взаимодействии с пользователем через графический интерфейс, я бы не задумываясь использовал С++/Qt. Это позволяло использовать один фреймворк/язык везде, независимо от структуры проекта и его компонентов, без дополнительных сложностей с зоопарком технологий и зависимостей.

Сейчас, в свете присходящего с Qt, придётся менять подход...



Лирическое вступление


Сразу обращу внимание, что я пишу именно о С++/Qt и чем эту связку заменить, а не C++ как таковом. Да, язык стал, скажем так, «обширным». Но я никогда не понимал нытья про его сложность, костыли и тому подобное. Eсли соблюдать правило, что не надо фанатизма задачу надо решать самым простым из приемлемых способов, код на С++ не лучше и не хуже остальных, при этом язык и его экосистема – одни из самых универсальных. Меня стала смущать именно Qt в этой связке, что тянет за собой и пересмотр области применения С/C++.


А что там, собственно, происходит с Qt?..


Несмотря на то, что Qt – продукт с открытым исходным кодом, правами на него обладает Qt Group Plc. А когда чем-то рулит коммерческая организация, она, вполне естественно, старается извлекать из этого выгоду. И это нормально, пока соблюдается баланс между предлагаемыми преимуществами продукта и его стоимостью/ограничениями.

И вот тут-то и проявляются изменения последнего времени от эффективных менеджеров.


Как менялось лицензирование


Когда-то Qt распространялся на условиях двойной лицензии: «неограниченной» коммерческой и LGPL версии 2. LGPL 2, если упрощать, даёт право использовать Qt в проектах с закрытым исходным кодом, если используется связывание с Qt в её неизменённом виде. То есть можно просто прикладывать к своему приложению «официальную» Qt в виде динамических библиотек (или связывать статически, но предоставлять пользователям всё необходимое, чтобы они могли самостоятельно связать ваше приложение с другим вариантом Qt).


Потом появилась LGPL версии 3. Суть изменений по сравнению с LGPL 2 в том, что она обязывает поставщика приложения обеспечить пользователю возможность заменить вариант Qt, с которым связано приложение на другой, независимо от того, где работает такое приложение. То есть, если вы продаёте пользователю «коробку» (не важно, промышленный контроллер или сотовый телефон) в которой работает приложение, связанное с Qt, вы обязаны обеспечить пользователю возможность попасть внутрь такой коробки и поменять там библиотеки Qt. Что при этом происходит с обеспечением безопасности и т.п. – вопрос сложный. В общем, за пределами десктопов LGPL 3 – это большой геморрой очень неудобная лицензия, а про магазины приложений я даже и начинать не буду...


Компания-собственник, естественно, по просьбам трудящихся, под эгидой поддержки свободного программного обепечения, использовала появление LGPL 3 для наложения дополнительных ограничений на бесплатное распространение Qt.


Ну и вообще… Всё, что появляется новое в Qt за рамками коммерческой лицензии, появляется либо на жёстких (LGPL 3), либо полностью запрещающих (GPL) условиях для проектов с закрытым программным кодом.


При этом, мне кажется, что платная версия была бы в большем ходу, если бы коммерческая лицензия была бы более адекватной реалиям. Стоимость такой лицензии – $3950 (~300 тыс. руб) на один год на каждого разработчика. При этом, однажды затащив в проект использование коммерческой версии Qt, за эту лицензию придётся платить до конца жизни проекта, так как любые последующие доработки/исправления/поддержка должны осуществляться с использованием коммерческой лицензии. То есть стоимость лицензий Qt надо закладывать в стоимость поддержки конечного продукта. Кроме того, при использовании коммерческой лицензии Qt усложняется подключение временных внешних разработчиков или использование в небольших проектах.


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


И тут Qt Group Plc взяла и вообще вбросила бомбу, заявив, что последующие LTS-версии (стабильные версии с расширенным сроком поддержки) Qt будут выходить только с коммерческой лицензией.


image


Перспективы


И вот эти последние заявления вызвали очень резкую реакцию со стороны сообщества вокруг Qt. В списке рассылки KDE стали звучать предложения вплоть до форка Qt под эгидой «открытого правительства», поддержанные серьёзными организациями (представитель KDAB открытым текстом сказал, что если будет форк, они его поддержат).


То есть, на горизонте забрезжил вариант раскола сообщества разработчиков. И чем это всё закончится, как отразится на качестве, не уйдёт ли эта история в другую крайность, например использование форка только в полностью открытых проектах – не ясно.


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


Весь предыдущий текст я немного упростил, так как всё несколько запутаннее. Например, над Qt Group Plc висит ограничение, позволяющее при определённых обстоятельствах, сделать форк Qt под очень свободной лицензией BSD, но при этом она имеет полное право на задержку выпуска некоммерческих версий на 12 месяцев.


Но суть происходящего именно такая – владелец прав на Qt движется семимильными шагами к максимальному ограничению использования некоммерческой версии Qt и имеет на это право, а остальные негодуют, но возможность форка, последствия фрагментации разработчиков и их влияние на состояние/распространение Qt пока не ясны. А оно нам такое надо? Что вызывает сомнения относительно его применения в новых проектах.


Что вместо?


За что многие любят связку С++ и Qt? За то, что она позволяет решать практически любые задачи без смены контекста. Язык, на котором можно писать быстрые программы, простая, единообразная и хорошо документированная структура, кроссплатформенность, и за всем этим – огромное сообщество.


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


Давайте структурно декомпозируем разделим на части тот тип проектов, о которых эта заметка (напомню: какие-то вычисления с каким-то взаимодействием с пользователем). Я не про модель-вид-контроллер и прочее, а про накладываемые требования. Получим два основных компонента: 1) клей из соплей и палок структурная логика, хранение данных и взаимодействие с пользователем, 2) там, где думать надо, и быстро обработка данных.


Первый компонент (общая логика и взаимодействие с пользователем) не накладывает особых требований к производительности (разница в три раза для пользователя не настолько важна, если это 10 против 30 миллисекунд), но должен позволять как можно более простую разработку/доработку/расширение функционала силами рабов на галерах.


Второй компонент (обработка данных) должен быть как можно «ближе к железу», безболезненно масштабироваться горизонтально (на множество ядер, серверов и т.д.) и, разумеется, должен иметь возможность использовать десятилетиями накопленные/оптимизированные библиотеки для предметной области приложения.


Обработка данных


Ну, тут вообще всё просто. Так как С/С++ со своими задачами по обработке данных вполне себе справляется и всем указанным требованиям удовлетворяет, шило на мыло менять смысла нет. Единственное, что тут дополнительно может возникать, так это небольшая обёртка вокруг алгоритмической части на чистом C для внешнего интерфейса, если планируется прямой вызов функций извне, а внутри используется C++. Ну или, как пример, такая же обёртка в виде интерфейса на сокетах. (Только никому не рассказывайте, а то смеяться будут: можно вообще просто запускать процессы и общаться через стандартные потоки, и затраты на это в лунуксах, относительно основной логики, почти никакие).


Общая логика и взаимодействие с пользователем


Да и тут всё более-менее очевидно… Что общедоступно, работает везде, для чего напридумано всё, что только можно, и что никуда не денется в обозримой перспективе, как и наш, прости-господи, любимый, C/C++? Что распространяется даже туда, куда оно «не пришей кобыле хвост» где раньше оно было неприменимо? Что позволит нам без дополнительных телодвижений выносить «тяжёлую» обработку от клиента на внешние мощные серверы?


Web-технологии, естественно. Под web-технологиями я понимаю связку из HTML, CSS и JS, плюс всё, что это генерирует/доставляет/выводит.


Со средствами доставки/вывода со стороны пользователя понятно – это либо браузер, либо какой-нибудь WebView. Ну да, кроссплатформенность, ага...


C HTML/CSS/JS мы ничего поделать не можем, оно уже тут и никуда не денется, значит выбора нет, а раз выбора нет – не надо задумываться, а когда задумываться не надо – голова не заболит.


Остаётся выбрать, что будет выдавать HTML/CSS/JS со стороны приложения.
Опять смотрим на требования (чтобы было просто и могло всё) и перебираем варианты. И тут опять просто.


image


Выбор небогат – это PHP. Да, я сказал PHP. И мне не стыдно.


Ещё раз напомню, о каком типе приложений идёт речь: о тех, где сложная логика, требующая вычислительной производительности, реализована на C/C++, а к ним в пару нам нужен как можно более простой открытый язык/экосистема для общения с внешним миром и связи компонентов между собой. А если будет C-подобный синтаксис – вообще хорошо. И тут мы ставим галочки напротив каждого пункта наших требований.


  • Главное – PHP прост. При том круге задач, которые он (и экосистема) может решать — он божественно прост. И дело не только в когнитивной нагрузке при кодинге и переключении контекста. Простота ещё и в развёртывании, администрировании и минимальном количестве вариантов, которыми можно решить одну задачу.
  • PHP медленно, без резких движений, ползёт в правильную сторону, от увеличения производительности в 3 раза, до строгой типизации, решая задачи простым способом. И обрастая по пути крутыми штуками типа Swoole.
  • PHP реализовал офигенский FFI (foreign function interface) к C. Офигенский в том контексте, о котором идёт речь — сочетании простоты и возможностей. Вы только наберите в гугле «PHP: Basic FFI usage».
  • В PHP кругом $, а кто по нынешнему курсу их не любит...
  • PHP быстрый. Да. Могу по слогам: бы-стрый. Для своей простоты и задач он божественно быстрый.

Тут многие могут начать холивар, если не начали после слов про простоту вспомнить про Node.js и Python, меряться запросами в секунду на голом «Hello, world!» (даже без рендеринга шаблонов, конечно, иначе ж не так понтово выигрышно будет выглядеть). На что я в очередной раз напомню, что в нашем случае, где значительное время уходит на обработку данных на C/C++, все остальные затраты не имеют решающего значения.


Пипкомер


Прошу пардона, не удержался, ибо холивар — дело святое. Поэтому для накидывания субстанции на вентилятор давайте сравним «в лоб» сферических коней в вакууме на PHP и C++/Qt.


Коней для замеров расположим в самом простом одноядерном вакууме с 1 Гб ОЗУ за $5 в месяц, а замерять их будем из другого такого же в том же дата-центре. Перед приложениями – nginx.


Первый конь – скрипт на PHP, выводящий шаблон страницы, на которой показывается значение из базы данных на основе параметра, переданного в запросе. Тормоза – для трусов Для простоты, ошибки не обрабатываем, и вообще не паримся. Но чтобы ещё хоть что-то происходило, для параметра из запроса ещё хэш sha256 посчитаем.


Второй конь – то же самое, но выводится с использованием QtWebApp.


Вот такая пара, потому что эта заметка о замене Qt. Если кому-то хочется вспомнить что-то типа node.js, тогда вспоминайте в паре с чем-то типа Swoole, и в отдельной статье, пожалуйста, потому что здесь не про асинхронщину, а про простоту, к тому же Swoole порвёт ваш node.js как Тузик грелку это будет оффтопиком.


Фрагмент на PHP
<?php

$horse_name = htmlspecialchars($_GET['horse_name'], ENT_QUOTES, 'UTF-8');
$horse_hash = hash('sha256', $horse_name);

$database = new PDO("mysql:dbname=vacuum;host=127.0.0.1", 'user', 'password');
$database->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$query = "SELECT `horse_color` FROM `horses` WHERE `horse_hash`=:horse_hash";
$statement = $database->prepare($query);
$statement->bindParam('horse_hash', $horse_hash);
$statement->execute();
$result = $statement->fetch(PDO::FETCH_ASSOC);

if ($result)
  $horse_color = $result['horse_color'];
else
  $horse_color = 'unknown';

?>
<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="utf-8">
  <title>Horse Color</title>
</head>

<body>
  <p><?= $horse_name ?> color is <?= $horse_color ?>.</p>
</body>

</html>


Фрагмент с QtWebApp
void HorseHandler::service(HttpRequest& request, HttpResponse& response)
{
    QSqlDatabase database = QSqlDatabase::addDatabase(
        "QMYSQL", QString::number(
                      reinterpret_cast<uint64_t>(QThread::currentThreadId())));

    database.setHostName("127.0.0.1");
    database.setPort(3306);
    database.setDatabaseName("vacuum");
    database.setUserName("user");
    database.setPassword("password");
    database.open();

    QString horseName =
        QString(request.getParameter("horse_name")).toHtmlEscaped();
    QByteArray horseHash =
        QCryptographicHash::hash(horseName.toUtf8(), QCryptographicHash::Sha256)
            .toHex();

    QString queryString(
        "SELECT `horse_color` FROM `horses` WHERE `horse_hash`=:horse_hash");
    QSqlQuery query(database);
    query.prepare(queryString);
    query.bindValue(":horse_hash", horseHash);
    query.exec();

    QString horseColor;
    if (query.next())
        horseColor = query.value("horse_color").toString();
    else
        horseColor = "unknown";

    QString templateString(R"RAW(<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="utf-8">
  <title>Horse Color</title>
</head>

<body>
  <p>{horse_name} color is {horse_color}.</p>
</body>

</html>)RAW");

    Template horseColorTemplate(templateString, "horseColor");
    horseColorTemplate.setVariable("horse_name", horseName);
    horseColorTemplate.setVariable("horse_color", horseColor);

    response.setHeader("Content-Type", "text/html; charset=UTF-8");
    response.write(horseColorTemplate.toUtf8(), true);
}


В итоге получили, что PHP выдаёт абстрактную фигню страницу даже в полтора раза быстрее.


ab -c 1 для PHP
root@horsesab:~# ab -n 1000 -c 1 http://x.x.x.x:8080/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking x.x.x.x (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx/1.17.10
Server Hostname:        x.x.x.x
Server Port:            8080

Document Path:          /
Document Length:        155 bytes

Concurrency Level:      1
Time taken for tests:   1.125 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      302000 bytes
HTML transferred:       155000 bytes
Requests per second:    888.77 [#/sec] (mean)
Time per request:       1.125 [ms] (mean)
Time per request:       1.125 [ms] (mean, across all concurrent requests)
Transfer rate:          262.12 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     1    1   0.2      1       6
Waiting:        1    1   0.2      1       6
Total:          1    1   0.2      1       6

Percentage of the requests served within a certain time (ms)
  50%      1
  66%      1
  75%      1
  80%      1
  90%      1
  95%      1
  98%      2
  99%      2
 100%      6 (longest request)
root@horsesab:~#


ab -c 1 для QtWebApp
root@horsesab:~# ab -n 1000 -c 1 http://x.x.x.x:8081/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking x.x.x.x (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx/1.17.10
Server Hostname:        x.x.x.x
Server Port:            8081

Document Path:          /
Document Length:        155 bytes

Concurrency Level:      1
Time taken for tests:   1.848 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      323000 bytes
HTML transferred:       155000 bytes
Requests per second:    541.26 [#/sec] (mean)
Time per request:       1.848 [ms] (mean)
Time per request:       1.848 [ms] (mean, across all concurrent requests)
Transfer rate:          170.73 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       4
Processing:     1    2   0.3      2       7
Waiting:        1    2   0.3      1       7
Total:          1    2   0.4      2       7
ERROR: The median and mean for the waiting time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      2
  95%      2
  98%      2
  99%      2
 100%      7 (longest request)
root@horsesab:~#


ab -c 20 для PHP
root@horsesab:~# ab -n 1000 -c 20 http://x.x.x.x:8080/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking x.x.x.x (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx/1.17.10
Server Hostname:        x.x.x.x
Server Port:            8080

Document Path:          /
Document Length:        155 bytes

Concurrency Level:      20
Time taken for tests:   0.664 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      302000 bytes
HTML transferred:       155000 bytes
Requests per second:    1505.59 [#/sec] (mean)
Time per request:       13.284 [ms] (mean)
Time per request:       0.664 [ms] (mean, across all concurrent requests)
Transfer rate:          444.03 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       6
Processing:     2   13   1.2     13      18
Waiting:        1   13   1.3     13      18
Total:          3   13   1.2     13      18

Percentage of the requests served within a certain time (ms)
  50%     13
  66%     13
  75%     14
  80%     14
  90%     14
  95%     15
  98%     15
  99%     16
 100%     18 (longest request)
root@horsesab:~#


ab -c 20 для QtWebApp
root@horsesab:~# ab -n 1000 -c 20 http://x.x.x.x:8081/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking x.x.x.x (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx/1.17.10
Server Hostname:        x.x.x.x
Server Port:            8081

Document Path:          /
Document Length:        155 bytes

Concurrency Level:      20
Time taken for tests:   1.716 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      323000 bytes
HTML transferred:       155000 bytes
Requests per second:    582.77 [#/sec] (mean)
Time per request:       34.319 [ms] (mean)
Time per request:       1.716 [ms] (mean, across all concurrent requests)
Transfer rate:          183.82 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       2
Processing:     4   34  13.3     34     188
Waiting:        2   34  13.3     34     188
Total:          4   34  13.3     34     188

Percentage of the requests served within a certain time (ms)
  50%     34
  66%     39
  75%     41
  80%     44
  90%     49
  95%     54
  98%     60
  99%     69
 100%    188 (longest request)
root@horsesab:~#


А отсюда избитая банальная истина мораль — вычислительные расходы на обвязку («инфраструктуру») приложения не сильно зависят от того, с помощью чего она реализуется. Отдельные компоненты, на которые и ложится основная нагрузка, от базы данных до внутренней реализации функций PHP, всё равно написаны на относительно низкоуровневых языках и достаточно оптимизированы. И могут быть даже быстрее криво написанных менее отточенных компонентов на номинально более быстрых языках. И где кто в какой ситуации будет быстрее — никто заранее не знает, так как все эти тупые бенчмарки ничего не скажут о той конкретной архитектуре, которая будет у вас в проекте.


Так что можем использовать для «обвязки» и интерфейса то, что проще, более открыто и распространённее, и не переживать. И «PHP плюс веб-фронтенд» для этого — оптимальный выбор.


Но в «тяжёлой» логике это, конечно, не так, поэтому никуда мы от второй части (С/С++) не денемся. И будем, как и раньше, писать её рабоче-крестьянским простым человеческим «Си с классами», регулярно почитывая на Хабре развлекательное нытьё про «задротский С++». Ну а когда встанет вопрос о прям вот оптимизации-оптимизации, то, как и раньше, наденем перчатки и опустим руки в субстанцию использем SIMD-интринзики на несколько строчек «горячего» кода, в каждой строчке прокомментируем что она делает, и ускорим код раз в несколько. А про геморрой красивое метапрограммирование со 100500 уровнями абстракций ради экономии нескольких процентов скорости будем с увлечением читать на «Хабре».


Вместо заключения


Я умышленно избегал технических деталей, чтобы не породить бессмыссленных дебатов о способах реализации конкретных решений. Для связки фронтенда/PHP/C++ cуществует огромное количество возможных комбинаций функций отдельных компонентов и их взаимного размещения, способов хранения информации и обмена сигналами/сообщениями, возможностей разработчиков в конкретном коллективе и т.д. Но однозначно можно говорить, что для всего этого уже всё придумано, на stackoverflow уже всё есть беспокоиться нечего.



Основной посыл такой – в огромном пласте приложений нет особых причин продолжать использовать Qt, а где-то теперь есть и противопоказания. И многое, что надо для замены, и в значительно большем количестве, уже есть в web-технологиях, от компоновки интерфейса до вывода графиков и трёхмерных моделей.
И технологии эти теперь имеют человеческое лицо со всех сторон: для владельца бизнеса, для пользователя, для программиста, и при общении с быстрым нативным кодом. Будем с ними дружить. А вот будем ли скучать по Qt — не знаю...

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 301

    +31

    Основная проблема всего написанного в том, что это лишь один кейс использования Qt. Я уже тыщу лет на нём не пишу (с версии 5.4), но в те времена когда я свои мелкие поделия нан ём делал, мне в нём нравилось:


    1) Event-based потокобезопасная и быстрая модель взаимодействия почти всего во фреймворке. Самое главное то, что её было ОЧЕНЬ легко использовать и почти не надо было думать. Всё взлетало само, много ума не надо.


    2) Богатый набор всего на свете. Тогда Qt воспринимался как boost с человеческим лицом, т.е. вещь в которой можно накопать всё что угодно и это будет работать хорошо и быстро.


    3) QML очень удобная вещь.


    4) Документация. Долгое время я думал, что на MSDN хорошая документация, но потом я встретил документацию Qt. Ничего более прекрасного я не видел никогда и нигде (в мире С++, в других экосистемах всякое есть).


    5) НОРМАЛЬНЫЙ кроссплатформенный (Mac/Win/Lin на то время) GUI фреймворк. Где всё работало блин. А если не работало, требовались прямо вот совсем минимальные подпрыгивания. Шрифты не уезжают, поддержка нативных контролов есть, ничего не тормозит "на глаз".


    6) На тот момент единственная бесплатная вменяемая кроссплатформенная C++ IDE


    7) qmake (вроде уже похоронили)


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


    И вряд ли кто-то вот так в один момент откажется от Qt по щелчку пальцев. По сути, Qt стал популярен и приобрел статус хорошего надежного решения и сейчас делает шаг в сторону использования только большими компаниями, ибо на них можно срубить больше бабла. Если он сможет закрепиться в этой позиции, то еще долго будет жить. Большим компаниям будут нужны программисты на Qt, так что программисты будут его учить, т.к. он перспективный и т.д. и т.п.


    А не сможет — ну, откатит лицензионную модель обратно.

      +4
      qmake не похоронили, я задавал вопрос в комментариях к статье на blog.qt.io про переход Qt6 на cmake (там как-то не совсем понятно это было сформулировано), меня заверили, что речь идет исключительно о переходе на cmake сборки самого Qt, а qmake для сторонних проектов в Qt6 никуда не денется. Ну а в целом да, статья несколько алармистская, я считаю. Даже если сделают форк, не факт, что это будет так уж плохо. Сейчас у Qt развитие идет главным образом в сторону embedded, automotive и так далее, в общем, в коммерческом направлении, все остальные направления идут как бы по остаточному принципу (пример — формат AAB появился еще в 2018 году, а поддержку его в Qt добавили только в 5.14, который вышел в декабре 2019). Может быть, если его таки форкнут, новые фичи будут бодрее реализовываться и в областях, касающихся, скажем так, более широкого круга разработчиков. Ну а HTML/CSS в браузере по сравнению с QML — это ИМХО такое… Как ниже правильно написали — Электрон с PHP на борту.
        +2
        Богатый набор всего на свете. Тогда Qt воспринимался как boost с человеческим лицом, т.е. вещь в которой можно накопать всё что угодно и это будет работать хорошо и быстро.

        Пересечение с бустом там так себе. Как в Qt называется аналог boost.graph или fusion?

          +2
          Да конечно — выбираем самые нестандартные части boost и ищем это в Qt.
          Все таки надо смотреть базовые части. Там пересечений довольно много. Например сериализация, работа с файлами и т.п.
            +1

            Кому нестандартные, а кто их использует весьма регулярно.

              +1
              Я скорее про то что Boost by design сборник разных библиотек не связанных друг с другом. А Qt таки фреймворк где взаимосвязанность сильно больше.
        +24

        Оу… Electron с PHP на борту?
        Завораживает.

          +14
          И тут фраза «секс, наркотики и рок'н'ролл» меняется на «наркотики, наркотики, наркотики»…
          +2
          К сожалению, Qt всё дальше отстает от апстрима С++. На дворе 2к20й а людям всё ещё надо доказывать что smart-pointer'ы это хорошо и правильно (и нет, в Qt6 их не будет, будем как в 90х делать parent-child на raw-поинтерах).
          Всякие std::optional/std::variant завезут только в 6ке и тоже непонятно когда и куда (у TQtC явно не хватает рук да и те разбегаются).
            +17
            К сожалению, Qt всё дальше отстает от апстрима С++.

            Ну как раз апстрим взял то, что в Qt было очень давно: variant, future, thread, smart-pointers и многое другое.


            На дворе 2к20й а людям всё ещё надо доказывать что smart-pointer'ы это хорошо и правильно (и нет, в Qt6 их не будет, будем как в 90х делать parent-child на raw-поинтерах).

            QPointer, QAtomicPointer, QSharedPointer and QWeakPointer — не то?! См. вики: https://wiki.qt.io/Smart_Pointers. Появились гораздо раньше, чем аналоги в C++!

              +3
              Они то там есть, только весь фреймворк пронизан передачей и работой с обычными указателями. Ещё и этот parent-child… Если используется как библиотека для каких-то отдельных плюшек, то ещё не заметно. Но вот когда в качестве GUI фреймворка, то все время глаз дергается, что есть простой указатель, за которым кто-то приберет (или не приберет?)
                0
                Я както задумался, и пришел к выводу, что нету другого простого способа управлять ресурсами в Qt модели не через parent-child. Ну например, хотите вы сделать обертку над тредом, что-нить типа такого
                class ThreadWrapper {
                    virtual void run() = 0; // Этот метод будет запущен в потоке
                    void start() { // Запуск потока }
                    ~ThreadWrapper() {
                           // Остановка потока
                     }
                }
                


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

                Как эту проблему решить не через parent-child?
                  +4
                  Перестать делать классы-потоки, тем более которые участвуют в иерархии?) Воркер-пулы на всё, а где все таки нужен класс-поток (уж явно единичные случаи) и можно без наследования обойтись.
                  Решается через некий ThreadManager, который сам позовет виртуальный метод stop у всех потоков. Менеджер можно даже синглтоном сделать, в котором каждый ThreadWrapper регистрируется при создании. Если других задач менеджеру не давать, то вполне рабочий вариант. Но и руками не забывать перед удалением stop говорить (собсна тот же std::thread развалится, если позвать деструктор, когда тред ещё работает, здесь даже попроще выйдет интерфейс, ну или совсем если мудрить, то в пользование отдавать всем простейший враппер над вашим тредвраппером, который в деструкторе будет звать у тред стоп и его деструктор)
                    +2
                    Тогда QObject и signal-slot перестанут уметь в многопоточность
                    И притом совершенно непонятно ради чего будет эта потеря
                      0
                      В принципе, через ThreadManager можно и QObject-ы с signal-slot-ами работать. Как-то задумывался над этим, но не пробовал реализовать
                  +1

                  Qt 5 вышел в 2012 году, когда этих всех плюшек ещё не было, а начали его делать ещё раньше. По ходу дела так серьёзно менять API они не могли. В 6-ке уже можно будет: https://habr.com/ru/post/501798/?reply_to=21613662#comment_21613378

                    0
                    Я понимаю, что это всё старое наследие… будем ждать в общем. Qt штука хорошая, местами есть нюансы, но это везде так. Лучше многих и часто лучше велосипедов. Да и я бы не сказал, что текущая ситуация с указателями прям сильно всё портит.
                    0
                    Система parent-child используется во многих UI (я даже не припомню таких, которые её не используют). Она логически напрашивается. Есть в окне панелька, в которой лежат кнопочки. Логично выходит, что панелька дочерняя к окну, а кнопки дочерние к панельки. Бывает, что на этой системе и отрисовку в рендере строят: рисуют от родителя к детям (как в Qt — не знаю). Причём она гарантирует, что кнопочка не отрисуется под панелькой, на которой лежит, а также что не придётся иметь геморрой с Z-порядком (по крайней мере в рамках родителей и детей). Убийство от родителя к детям тоже считаю полезной особенностью: при уничтожении окна не требуется обхода всех детей. Кроме того, QPointer всегда позволит знать, кто убит, а кто нет (если требуется).
                    +6
                    Ну как раз апстрим взял то, что в Qt было очень давно: variant, future, thread, smart-pointers и многое другое.


                    std::variant имеет очень отдаленное отношение к QVariant (и вообще, QVariant это скорее std::any). И пришел он в стандарт из буста а не из Qt.
                    Аналогично, thread — тоже из буста.
                    Насчет указателей не уверен, но они появились задолго до стандарта в tr1 и скорее всего пришли в Qt оттуда (просто комитет тогда был слоупоком и не принимал их).

                    QPointer, QAtomicPointer, QSharedPointer and QWeakPointer — не то?!

                    Они там ест но даже новый код пишется без их использования, например, QThread::create который возвращает голый указатель на созданный тред. Каждый раз когда я использую этот метод, я его заворачиваю в unique_ptr.
                    Или например тредпул который берет раннаблы с булкой «надо ли удалять раннабл» (autoDelete), что приводит к рейсу, который описан в документации (кек). А всего-то надо передавать шаред_птр на раннабл — и булка не нужна и рейс уходит.
                    Из всех smart pointer в самой Qt активно используется только QPointer. Что мешает пойти дальше и начать использовать остальные указатели — яхз.
                      0
                      Или например тредпул который берет раннаблы с булкой «надо ли удалять раннабл» (autoDelete), что приводит к рейсу, который описан в документации (кек). А всего-то надо передавать шаред_птр на раннабл — и булка не нужна и рейс уходит.

                      А можно по-русски пожалуйста и с примером в целях повышения образованности? :)

                        +2
                        Я не очень умею выражать свои мысли, поэтому давайте пример=)
                        setAutoDelete(false) нужен для того, чтобы переиспользовать раннаблы несколько раз. Например, мы хотим запускать раннабл дважды:
                        auto tp = QThreadPool::globalInstance();
                        auto run = new Runnable(); // класс наследует QRunnable и что-то исполняет
                        run->setAutoDelete(false); // хотим переиспользовать
                        tp->start(run); // запустили первый раз
                        tp->start(run); // запустили второй раз
                        run->setAutoDelete(true);
                        /* а вот так^ делать нельзя, потому что пул мог уже 
                        обработать раннаблы и не успеть прочитать булку. Это поведение
                        описано в документации, "пожалуйста, не стреляйте себе в ногу"*/
                        
                        


                        Теперь тот же юзкейз на shared_ptr:
                        
                        auto tp = QThreadPool::globalInstance();
                        auto run = std::make_shared<Runnable>();
                        tp->start(run); // запустили первый раз
                        tp->start(run); // запустили второй раз
                        

                        Фишка в том, что мы получили тот же юзкейз и нам эта булка вообще не нужна, нам нужен атомарный счетчик ссылок на раннабл. Если в пуле лежит 2 раннаблы, объект будет жив пока не исполнится последняя. Если мы держим ссылку вне пула, то тоже всё хорошо — пул ничего не удалит, а просто выкинет свои копии указателя.
                        Кода меньше, код безопаснее, нет corner-case'ов которые надо описывать в документации. Одни плюсы.
                          0

                          булка — это что в данном случае?

                            +2
                            boolean, bool, вот эта сама bool autoDelete()
                              +2
                              Спасибо за загрязнение персонального словаря новым приставучим термином 8)
                                0

                                Давайте только писать bool'ка или B00Lка, чтобы показать свой пацанский характер ))))

                                  +5
                                  Не за что, держите еще один — батарея (QByteArray)
                      +7
                      и нет, в Qt6 их не будет
                      в смысле?
                      Всякие QScopedArrayPointer и QSharedPointer — есть уже чёрти сколько лет.
                      Да, иерархия QObject использует сырые указатели — но там дерево объектов само отслеживает время их жизни, т.е. по сути является smart pointer'ом; добавлять туда ещё — это во многом бесполезное дублирование функциональности.
                        +15

                        Обычно авторам таких высказываний неважно — как только обнаружен код без smart pointer'ов, делается вывод про качество всей библиотеки. И не интересует ни её объем, ни исторический (и надо сказать прекрасно себя показавший) подход к разработке — когда используется гарантированно поддерживаемый всеми компиляторами минимальный остов языка, ни устоявшиеся API с сырыми указателями… Надо smart и все тут, даже если это последий пункт в очереди болящих вещей.

                          –1
                          Я так стараюсь придерживаться разумного минимума. На данный момент считая таковым C++11. Например, у Убунты LTS срок жизни пять лет, 16.04 C++17 по штату не положен. Недавно пришлось обновлять вполне рабочую систему на Debian из-за старой версии CMake. Но это сборка, а вот в готовом продукте необходимости обновиться или ставить левые зависимости заказчик может не понять (как и C++98). Я так понимаю, что скоро у нас будет три версии Qt — 4, 5 и 6. Впрочем, ЕМНИП, и третья довольно долго жила бок о бок с четвёртой.
                            +4
                            Автор такого высказывания активно принимал участие в обсуждении перепиливания parent-child на умные указатели. И аргументов типа «сломается много кода» там нет, аргументы там были «да посмотрите вон на модуль ХХХ (вроде что-то с Xml) он написан на смартпоинтерах и там такооой говнокод». Изменение почти неломающие (кроме ряда случаев), старый код продолжает работать и копилироваться, но мы не будем его внедрять просто потому что мы в 2к20м не уверены что смарт поинтеры это хорошо. Это дословно аргументация противников, можете почитать development mail list.
                              0
                              А все же — какую проблему планировали решить данным proposal'ом?
                              И аргументов типа «сломается много кода» там нет
                              До этого даже не дошло мб?
                                +3
                                А все же — какую проблему планировали решить данным proposal'ом?

                                Абсолютно неочевидная передача владение в куче случаев. QMainWindow::setCentralWidget репарентит виджет. QAbstractItemModel::setModel не репарентит модель несмотря на абсолютно аналогичное название.
                                QLayout::addWidget репарентит виджет.
                                QMenu::addAction не репарентит экшн.
                                Глядя на сигнатуру\вызов метода невозможно понять, передается владение или нет, что ведет к постоянным багам (не все смотрят в документацию каждый раз).
                                Хорошо если метод называется takeItem, можно угадать что он отдает овнершип юзеру… Но если юзер не догададется, получим утечку.

                                До этого даже не дошло мб?

                                Почитайте рассылку, там реально аргументы уровня студента (причем не от самих кутешников, а от каких-то рандомов)
                                  0
                                  QMenu::addAction не репарентит экшн.
                                  И это правильно — один и тот же QAction может легко быть использован во множестве мест, в том числе и для ShortCut'ов, работающих везде в программе.
                                  QAbstractItemModel::setModel
                                  Нет такой.
                                  Если вы про QAbstractItemView::setModel, то там тоже прямо сказано — одна модель may be shared between several views.
                                  Глядя на сигнатуру\вызов метода невозможно понять, передается владение или нет
                                  Вот это стоит исправить — сделать разные языковые конструкции для случаев когда владение забирается и когда просто даётся для использования.
                                    +2
                                    Да, конечно же я имел ввиду вью, спасибо=)

                                    Никто не говорит что это неправильно — это неочевидно при чтении кода. Код должен быть самодокументируемым и читающего не надо заставлять лезть в документацию, чтобы ответить на вопрос «нет ли тут утечки».
                                    Примеры с addAction тривиальны, но есть места где приходится реально углубляться в чтение.
                                    На самом деле, QLayout::addWidget гораздо лучше смотреть как пример. Я вот написал что он виджет репарентит, а на самом деле, он репарентит его не всегда, а только если лайаут чему-то назначен. Если у вас есть лайаут, ни к чему (ещё) не привязанный, вы сделали layout->addWidget(new Widget) и внезапно решили выйти из функциии (ну, например, настройки не считались)… Упс, утечка.
                                    Да, это сомнительный corner-case, но его можно было бы избежать, использовав умные указатели.
                                    +2
                                    не все смотрят в документацию каждый раз
                                    В этом и проблема. В документации Qt всегда прописано, что владеет объектом.
                                    Мне понравилось, как написал 0xd34df00d в своей статье — в C++ постоянно нужно вдумчиво писать код, на каждой строчке предвидеть возможные последствия и UB. Ну починят «проблему» сырых указателей в Qt (с которой живет сам фреймворк и тонны софта на нем), так ведь все равно C++ предоставит кучу способов сделать рокет-джамп выстрелить себе в ногу.
                                  +1
                                  И аргументов типа «сломается много кода» там нет, аргументы там были «да посмотрите вон на модуль ХХХ (вроде что-то с Xml) он написан на смартпоинтерах и там такооой говнокод».
                                  Если вы про вот это обсуждение — то там как раз всё в аргументах именно про «сломаются типичные паттерны использования» и «нам надо запилить свои смарт поинтеры для этого».
                              +3
                              Куда остает?
                              У Qt6 в планах C++17, минимальный поддерживаемый компилятор на винде MSVC 2019 (не уверен какой конкретно версии).
                              Внутри уже давно на стандартные смартпоинтеры переписывают.
                              Строки по умолчанию хотят utf-8 сделать и прочее, прочее
                                0
                                Parent-child и есть те же smart pointers, просто несколько другие.
                                И они никуда не денутся, потому что на них завязана многопоточка причем на мой взгляд достаточно изящно.
                                  +1
                                  Многопоточка никак не завязана на parent-child, вся иерархия «в треде» должна иметь нулевой parent (нельзя переместить в тред только часть иерархии, вы получите ворнинг).
                                  Потом, никто не предлагает убирать иерархию, предлагают реализовать ее через unique/shared_ptr (и там уже есть счетчик слабых ссылок (а точнее вся дата QShared/QWeakPointer) в QObject для QPointer'а, например)
                                    +2
                                    Смотрите: в Qt есть типовой use-case: если удаляем родителя, то должны умереть его дети. Это вполне логичное требование: если умерло окно приложения, то должны умереть и населяющие его компоненты. И кьют гарантирует что Вы сможете корректно это сделать даже в многопоточном приложении (путем наложения серьезных ограничений на эту многопоточность, но тем не менее). Как Вы собираетесь это реализовывать через unique/shared_ptr? Вообще какую пользу даст эта замена?
                                      0
                                      Как Вы собираетесь это реализовывать через unique/shared_ptr

                                      Легко и изящно, parent-child отлично реализуется на unique_ptr (и можно даже сделать так что старый код будет работать).
                                      0. QObject
                                      1. TreemodelItem
                                      2. Нода дерева

                                      Вообще какую пользу даст эта замена?

                                      Эта замена даст ту пользу что будет сложнее выстрелить себе в ногу (а сейчас сделать это ооочень легко) и передача владения будет явно выражена в коде:

                                      window->setCentralWigdet(std::make_unique<QWidget>());

                                        –2
                                        Да, с передачей владения через unique_ptr полностью согласен, это косяк Qt что до сих пор не реализовали
                                +7
                                Надеялся, что Вы предложите вариант не Qt WebView и HTML/JS с аналогом таких элементов Qt, как мой любимый QTreeView и QGraphicsScene, а Вы PHP…
                                Кстати, LGPL в Qt появилась не сразу — сначала там была только GPL.
                                  +3
                                  да. и все очень обрадовались, когда в 4.5.0 завезли LGPL.
                                    0
                                    Я так сразу рванул делать на ней закрытое приложение по работе, поэтому сей факт хорошо помню, правда, уже не помню точно, когда это было, помню только, что давно.)
                                    Во всём, как всегда, виноват Microsoft. Не сожри он Нокию, таких проблем бы не было.
                                  +5
                                  Они вернули адекватную лицензию для небольших компаний.
                                    0
                                    Это для pet projects и больше замануха, вдруг выстрелит и опа — вы платите по $4K за лицензию: Qt for Small Business is restricted to companies with an annual revenue + funding of max $250 000.
                                      +2
                                      Некисло так: $3950.00 в год. А потом ещё каждый год продлевать, пока программу распространяешь(или продаёшь).
                                      Есть такая программка Yarxi. Разработчик её на Delphi написал. Собрал на краудфандинге 1500 евро на Delphi 10 Seattle. Его убеждали на Qt перескочить. Он устоял. Иначе бы вляпался в кабалу и пришлось бы словарик продавать по цене 2х Windows 10 major edition.
                                      Не всё так адекватно для небольших компаний. Qt — это махровая коммерция для гигантов типа VAG и маленьким компаниям там делать нечего.
                                        +4
                                        Иначе бы вляпался в кабалу и пришлось бы словарик продавать по цене 2х Windows 10 major edition.
                                        Чем вам не нравится бесплатная LGPL лицензия?
                                          0
                                          Исходники закрыты — это коммерческий продукт.
                                            +3
                                            LGPL это позволяет. Поэтому все с радостью встретили выход Qt 4.5 -где была добавлена эта лицензия
                                              –1
                                              Что то Вы не договариваете, либо сами не разобрались с лицензиями.
                                              Василий Иванович, что такое нюанс?
                                              Видишь ли Петька:

                                              Иначе зачем тогда работают менеджеры и юристы в Qt Company?
                                                +4
                                                Текст лицензии LGPL доступен. почитайте, там всё написано
                                      +26

                                      Веб? Интерпретатор вместо нативной программы? Нет, пожалуйста, не надо, прошу! Нет!

                                        0
                                        Ну когда они сменили Qt WebKit на Qt WebEngine в 5.7, сломав отличную разметку в Assistant и вывод на печать через QPrintPreviewDialog из QWebView (многие делали отчёты на html), это очень не понравилось многим разработчикам.
                                        вот пример сломанной разметки
                                          0

                                          Есть annulen, который пилит вебкит дальше. В линуксодистрах, по крайней мере, пакеты есть.

                                          +9

                                          А какие вообще есть альтернативы QT, чтобы и интерфейс было относительно просто реализовать (приличный редактор форм, вполне вменяемая реализация взаимодействия между элементами интерфейса и остальным кодом), и реализации всякого полезного были (работа со списками, деревьями, потоками и т.п.), и чтобы все было единообразно, логично, вменяемо и кроссплатформенно?


                                          Я пока что-то ничего не нашел. Разве что Delphi/C++ Builder, но оно уже давно тоже куда-то не туда смотрит, да и с поддержкой разных платформ как-то не очень по сравнению с QT.

                                            +4
                                            Нет. Поэтому QtC такое и вытворяет.
                                            • UFO just landed and posted this here
                                                +6
                                                Ну почему, в некотором смысле аналоги есть. Те же GTK или wxWidgets. Но полноценного конкурента для Qt во всех его нишах (cross-platform desktop, embedded, mobile), думаю, нет. В его развитие очень сильно и долго вкладывались, и сделали реально мощную вещь, с которой непросто конкурировать. Поэтому и лицензирование такое — могут себе позволить, так сказать.
                                                  +5
                                                  Qt — это не UI.
                                                  Qt — это огромный фреймфорв и UI в нём — это лишь одна из областей для которых он пригоден.
                                                    0
                                                    Widgets, QML и сопутствующее им половину всех dll и занимают.
                                                    А всему остальному замену найти как раз несложно.
                                                    • UFO just landed and posted this here
                                                      0
                                                      Вроде бы Word не использует mfc и другие библиотеки, которые microsoft даёт сторонним разработчикам, при этом он есть и под mac — то есть относительно кроссплатформенен, не все компании открывают свои наработки, а делают их только для себя, чтобы иметь конкурентные преимущества
                                                        0

                                                        ну, макофис может быть легко собран из другой кодовый базы (по крайней мере — UI). Можете провести анализ, какие компоненты они используют сами ?

                                                        • UFO just landed and posted this here
                                                      +2
                                                      Java?
                                                        +3
                                                        Господа минусующие, вы знак вопроса видите? Это вопрос был, а не утверждение. Если Джава не соответствует вопросу:
                                                        А какие вообще есть альтернативы QT, чтобы и интерфейс было относительно просто реализовать (приличный редактор форм, вполне вменяемая реализация взаимодействия между элементами интерфейса и остальным кодом), и реализации всякого полезного были (работа со списками, деревьями, потоками и т.п.), и чтобы все было единообразно, логично, вменяемо и кроссплатформенно?

                                                        Может объясните — почему, если уж настолько не согласны, что ставите минус?
                                                          0
                                                          Вроде OpenJFX живет, так что да
                                                            +3
                                                            Мы тут для embedded-проекта сравнивали Qt и JFX,… если кратко, это только на бумаге они конкуренты. Qt заводится с полпинка, среда ставится элементарно, документация нормальная, на арме не тормозит, поддержку аппаратного ускорения отрисовки имеет… Ничего из этого нет в jFX. В дополнение к этому, экосистема и комьюнити вокруг jfx практически нулевая, по сранению с Qt, а уж в области embedded тем более.
                                                              0
                                                              Embedded в условии не было. Было бы глупо ожидать производительности нативного c++ фреймворка от виртуальной машины Джавы. Они конкуренты разве-что на десктопе.
                                                          +2

                                                          wxWidgets.

                                                            +2
                                                            по сравнению с Кьюти это просто боль и страдание. Зато контролы нативные, но больше плюсов нет, все остальное минусы.
                                                              0
                                                              Я тоже так всегда думал, пока не увидел вот это видео, оказалось там не всё так плохо.
                                                              www.youtube.com/watch?v=FOIbK4bJKS8
                                                              www.youtube.com/watch?v=FwUGeV2fnfM

                                                              Хотя я всё равно буду использовать Qt, мне она кажется логичнее и удобнее.
                                                              По сравнению с Qt — у других библиотек плохо с документацией.
                                                              Qt этим берёт, не просто перечисление методов, а примеры правильного использования!
                                                              Но её делал Жасмин Бланше и Саммерфилд, которые уже давно ушли, и как мне показалось в QML документация уже не такая качественная.

                                                                +2
                                                                Там не всё так плохо для задачи «сделать, чтобы была кнопка и она работала». А вот задачу сделать красивую программу, со всякими там стилями, темами и анимациями wxWidgets тупо не тянет. Функционально оно не уступит Qt, но вот визуально — очень.
                                                            +1
                                                            JavaFX прекрасно работает на декстопе, и можно делать сильно навороченные вещи. Но не сильно быстрые (((
                                                              0
                                                              Разве что GTK
                                                                0
                                                                Я пока что-то ничего не нашел. Разве что Delphi/C++ Builder, но оно уже давно тоже куда-то не туда смотрит, да и с поддержкой разных платформ как-то не очень по сравнению с QT.
                                                                1. Он как раз таки смотрит куда нужно в последние наверно лет 7+ :)
                                                                2. Каких платформ не хватает?
                                                                3. Существует полностью бесплатный FPC/Lazarus, который работает как говорят, хоть на утюгах :)
                                                                  0
                                                                  Скорость так себе, хуже шарпа.
                                                                    0
                                                                    1. Скорость на Делфе примерно 10% ниже плюсов на Windows, тут спорить не буду. Опять же есть Билдер, который шустрее.
                                                                    2. За счет нативного кода ниже шарпа скорость не может быть никак.
                                                                    3. На мобильных платформах и Линуксе/OSX сборка в Delphi и Билдере идет с помощью LLVM, поэтому скорость сопоставима с другими срадами собирающими бинари LLVM'ом
                                                                      +2
                                                                      Ой ли. Вот тут можно взять исходники и проверить. FPC там почти вдвое медленнее С (с шарпом у автора какие то нелады в системе — лучше сверять у себя).

                                                                      Шарп уже умеет компилиться в нейтив, кстати.
                                                                        0
                                                                        Встроенный Делфи копмпилятор всё таки пошустрее FPC. Но тут есть нюанс: FPC умеет собирать бинари с помощью LLVM тоже на некоторых платформах и вот можно было бы попробовать разные варианты. В FPC пошли дальше Делфи — в качестве бэка сборки можно юзать и свой компилятор и LLVM и JVM и сборку в JS (вот как раз пишут). Думаю, что и на другие платформы будет LLVM бэк дописан, FPC очень активно развивается в последнее время.
                                                                        wiki.freepascal.org/LLVM
                                                                    +1
                                                                    Раз в пару лет пробую поставить Lazarus, собрать проект по умолчанию (с одним пустым окном) и всегда компиляция падает на каких-то странных ошибках(
                                                                      0

                                                                      Странно… А можно подробнее?

                                                                        0
                                                                        Что пишет то хоть? :) У нас вот проекты под миллион строк работают без каких-то особенностей и на винде и на линухе.
                                                                          0
                                                                          Хех, сейчас поставил на чистую убутнту 18.04, и… все работает, ура! Кажется, раньше я пробовал это всё на винде, хотя не помню, несколько лет уже не проверял.
                                                                            +1
                                                                            Удобно если что ставить этим тулом:
                                                                            github.com/LongDirtyAnimAlf/fpcupdeluxe/releases
                                                                            И на винде и на линуксах и на остальных платформах.
                                                                              0
                                                                              На винде наверное удобнее, но в убунте все-таки apt install lazarus удобнее
                                                                                0
                                                                                Зависит от того, какая версия в репе лежит. Мы ставили Лазарь уже на примерно семи разных сбороках Линухов, fpcupdeluxe удобнее.
                                                                        +1
                                                                        1. Проблем несколько.
                                                                          Во-первых, глючные до безобразия IDE после версии 5.5.
                                                                          Во-вторых, перенос проектов на новую версию IDE может превращаться в серьезную проблему в случае использования сторонних визуальных компонентов. А порой и без использования оных можно получить проблем в полной мере (один переход на Unicode чего стоил, долгожданный, но, как именно его сделали...).
                                                                        2. Во-первых, среда разработки только под Windows. Для меня это уже серьезный минус.
                                                                          Во-вторых разработка под некоторые платформы не просматривается, в то время как Qt там основной вариант (тот же Sailfish).
                                                                        3. Lazarus, конечно, вещь интересная, даже пользую его иногда, но это совсем не Delphi. Это даже до версии 5.5 по удобству не дотягивает. Особенно "радует" необходимость пересборки всей IDE при добавлении визуальных компонент.
                                                                          0
                                                                          1) Юникод уже более десяти лет назад был, все компоненты перенесены и очень давно. Я сам три проекта примерно около млн строк перенес на уникод полностью за примерно неделю вместе с компонентами, вот примерно в 2010м году, да. По стабильности — сижу на XE6, работает неделями без единого сбоя. Да, проблемные версии были, они известны. Не обязательно их использовать.
                                                                          2) Если не нравится Delphi которая действительно только под Win, то Лазарус в помощь, он работает 'по месту', сам постоянно в Линуксе на нем сижу.
                                                                          3) Пересборка идет довольно шустро, примерно 15 секунд вся среда с компонентам пересобирается и их можно ставить 'пачкой', особых сложностей это не доставляет
                                                                            0
                                                                            К слову — пилят подобие bpl в Лазаре. Так что текущее состояние не на всегда. Смогут копмоненты устанавливаться точно так же как в Delphi.
                                                                              0

                                                                              1) Тем не менее в целом с обратной совместимостью проблемы были чаще, чем в Qt. Да и сторонних визуальных компонент, для которых не появлялись обновления под новые версии Delphi, очень много встречалось.


                                                                              Еще вспомнился один занятный баг, который хорошо попил крови. При попытке сборке одного проекта под более новыми версиями Delphi, чем исходная 2005, на которой проект разрабатывался, постоянно получали странную ошибку. Что-то вроде "Internal error" с каким-то кодом. Причем никаких объяснений именно по данному типу ошибки нигде не было, по месту возникновения ошибки ничего понять не получалось.
                                                                              Уже спустя несколько лет попыток таки собрать проект под новыми версиями Delphi случайно где-то в сети обнаружили упоминание, что в этом случае надо просто везде заменить object на class в объявлении классов. Что интересно, хватило изменения только в том модуле, при компиляции которого выдавалась ошибка.
                                                                              3) У меня в 15 секунд не укладывается. обычно несколько минут. Впрочем, это не сильно меняет ситуацию. Пока по всем параметрам, определяющим удобство использования, до Qt ему далеко.
                                                                              Хотя для "домашнего" пользования уже вполне годится.

                                                                                0
                                                                                Вы как-то все в прошлом застряли :) 5.5, 2005, уже как-то 15-20 лет прошло… Указанные проблемы уже настолько давно остались в прошлом — несовместимости какие-то, что их уже все забыли. Все более-менее заметные компоненты, которые стоит себе в проект вообще добавлять уже очень давно переработаны под новые среды.
                                                                                  0
                                                                                  Вы как-то все в прошлом застряли

                                                                                  Это просто самые яркие впечатления.
                                                                                  Впрочем, последние версии (после XE5) я действительно не пробовал, как-то совсем разочаровался к этому моменту. Может быть и зря, конечно.
                                                                                  Впрочем, желание попробовать последнюю версию производитель сам тут же убил в зародыше. Требовать телефон (без его указания просто не пустило дальше) за скачивание Community Edition — это как-то слишком.
                                                                                  А Qt пока за бесплатную версию не требует никаких персональных данных.

                                                                                  0

                                                                                  Кстати о lazarus, Qt для fpc оказывается есть. Интересное кино. Надо посмотреть-попробовать.

                                                                                    0
                                                                                    Всё так, Лазарь работает через несколько виджетов:
                                                                                    wiki.freepascal.org/Widgetset
                                                                                      0
                                                                                      Когда-то Борланд делал Kylix. Там был набор виджетов от qt (через него работали компоненты — CLX назывался набор), но он был очень скромен по сравнению с delphi.
                                                                                      В какой-то версии ядра (уже не помню точно)- немного сменили формат elf файлов и kylix перестал работать, а его приложения требовали патча.
                                                                                        0
                                                                                        Всё так. Говорят что Майкрософт сильно вмешалась, после чего Kylix свернули, так бы мы уже очень давно имели нормальную кросс-платформенность. К сожалению Майкрософт всегда Делфе очень сильно гадил. В последнее время наконец они опомнились )
                                                                                          0
                                                                                          Врядли, качество куликса было неок, и самое главное что линуха на десктопе в пределах погрешности — бабок от продажи 0.
                                                                            +3
                                                                            .Net с Eto.Forms или Avalonia.
                                                                            +5

                                                                            А что насчет ну к примеру связки flutter + rust? Вроде как те же яйца, но на более новых технологиях.

                                                                              +2
                                                                              Кто б сомневался, что и тут будут Rust рекомендовать :) Вроде как автора вполне себе С++ устраивает. Но это безусловно намного лучше, чем выбор PHP :)
                                                                                +1

                                                                                Нет, автора устраивает С с классами, он про это явно пишет.

                                                                                0
                                                                                Флаттер ни под десктоп, ни под веб пока ещё не очень то юзабелен. Даже начальных релизов ещё не было, мастер только тащить. Только под Мак альфа вышла, насколько помню.
                                                                                Последний раз, когда пробовал его, даже примеры из SDK были поломаны и не собирались. Так что, до Кьюта ему ещё долго ползти.
                                                                                +1

                                                                                Хм, ну запилят очередной Qt на php (или чем то другом), кончится все тем же — как только начнется массовое использование придут эффективные менеджеры и опять начнут требовать деньгу.

                                                                                  0

                                                                                  единственное, что спасет — полностью открытый проект ?

                                                                                    0

                                                                                    Как очередной виток.

                                                                                      0
                                                                                      А кто его разрабатывать то будет?
                                                                                    +21
                                                                                    Прочитать столько интригующего текста, что бы напороться на PHP…
                                                                                      +3

                                                                                      Вляпаться в))

                                                                                      0

                                                                                      Забыл добавить, юзать ab для бенчмарков это моветон, он часто бывает сам тормознее тестируемого кода.

                                                                                        +2

                                                                                        Немного слов в защиту. Хотелось обратить Ваше внимание, что все государственные структуры в настоящее время переводятся на AstraLinux, где это связка c++/qt доступна прямо из коробки. Это факт как раз может послужить к увеличению количества разработчиков именно на этой связке. Если я не ошибаюсь то разработка ПО для госструктур должна выполнялся на сертифицированных средствах.

                                                                                          +20
                                                                                          Вы уж извините, но в госструктуру я пойду в последнюю очередь=) Я лучше выучу rust или go (да даже php вспомню!) чем буду писать на уютной кутешечке на государство=)
                                                                                            +6

                                                                                            А что, давно загран получали? Я подглядел в софт, в котором заполняли данные и фотографировали — Qt под KDE , если мои эльфийские глаза не окутаны каким-то волшебством. Вопрос работы в госорганизации холиварный, но код на Qt кое-где точно есть, и это в целом хорошая новость как по мне!

                                                                                          +1
                                                                                          Судя по заказам на Upwork, большинство проектов десктопных приложений заказчики ожидают видеть на C#, WinForms. Qt очень редко нужен под Windows, чуть чаще под Mac и практически никогда под Linux.
                                                                                          Кроссплатформенность Qt конечно отличная штука, но далеко не всегда она нужна.
                                                                                          Вот и получается, что если начнут закручивать гайки в Qt, можно перебраться на C#.
                                                                                            +13
                                                                                            Qt очень редко нужен под Windows, чуть чаще под Mac и практически никогда под Linux.

                                                                                            Очень спорное утверждение: как раз чаще всего на Линуксе — это и IoT, и embedded (что чаще всего) и Qt Automotive. Про Андроид вообще молчу: количество сильно растёт. Все проекты, на которых я работал на Qt (медицина, инжернерно-технические, управление временем и т.п.) были кросс-платформенные. Вообще отказ от Qt был бы катастрофой и замена его на Web или C# в большинстве проектов просто нереальна!!! Вот например в таких: https://github.com/mavlink/qgroundcontrol/ Это бред!

                                                                                              +1
                                                                                              Именно WinForms? Не WPF разве (если речь о новом проекте, не легаси)?
                                                                                                –6
                                                                                                Вот и получается, что если начнут закручивать гайки в Qt, можно перебраться на C#.

                                                                                                Как человек который пробовал и то и другое, поверьте: с C# будет так плохо что лучше уж web-интерфейс. По производительности C# не тянет, при скрещивании C++ с C# возникает жирный промежуточный слой CLI, плюс логика реализации C# приложений радикально отличается от логики Qt приложений что в завязке на ситуацию когда вызовы могут ходить туда-сюда порождает совершенно нечитаемую логику приложения в целом (если в C++ есть какая-то логика а не набор отдельных вызываемых для скорости алгоритмов). Ну и WPF после QML — это очень больно и грустно.
                                                                                                +2
                                                                                                Пока читал, — ждал появления простого и элегантного кода биндинга php в C++. Типа либа обёртка которая может «фсё искаропки», включая многопоточность и прозрачный обмен данными между потоками C++ и PHP, ч-з очереди.
                                                                                                  –4

                                                                                                  А еще есть JavaFX, кросс-платформенно, удобно и не php.

                                                                                                    –1

                                                                                                    Который жутко тормозит в сравнении с C++/Qt/QML.


                                                                                                    Qt vs. JavaFX: https://www.youtube.com/watch?v=Kh6K-yEp_JY


                                                                                                    HTML5 vs Qt: https://www.youtube.com/watch?v=Z4CwVN9RRbE


                                                                                                    Посему для большинства приложений, где используется Qt, где нужна скорость или есть тяжёлые вычисления и нужна высокая скорость передачи данных ни Web ни Java ни вариант. Хотя Java много лучше будет конечно.

                                                                                                      +5
                                                                                                      Не надо такие видео в адекватных сообществах показывать. Вы хотя бы на дизлайки в видео посмотрите и комментарии прочитайте. Не говоря уже о том, что сравнивать производительность без кода это как верить в статиистику без источников данных.
                                                                                                        –3

                                                                                                        Что ты называешь "адеватным" сообществом? Ты хочешь сказать, что Java будет быстрее C++?! Даже комментаторы там признают, что C++ производительнее. Подтверждаю на собственном опыте: когда-то хотел сделать программу на Java но UI и расчёт ИНС тормозил на ней жутко — в 2-3 раза (хотя может надо было наплевать с прицелом на будущие перспективы и уровень зп ;) ) — сделал на C++/Qt.


                                                                                                        С видео о HTML5 в комментариях и лайках вообще ни у кого вопросов не возникло. Чтобы спорить здесь надо быть полным неадекватом.

                                                                                                        +3
                                                                                                        1. Мы всё еще о UI или вы из тех, кто вычисления в одном потоке с интерфейсом делает?
                                                                                                        2. Цифры относительно «тяжелых» вычислений и «высокой» скорости, конечно де у вас под рукой?
                                                                                                        3. Про большинство приложений тоже интересно увидеть цифры
                                                                                                        4. Про видосы, как уже сказали ниже — без кода — это мусор.
                                                                                                          –3
                                                                                                          1. UI, вычисления у нас конечно в отдельном потоке.
                                                                                                          2. Конечно: см. пост выше: Java была в 2-3 медленее на моих задачах
                                                                                                          3. Большинство приложений, где используется Qt: https://en.wikipedia.org/wiki/Qt_(software)
                                                                                                          4. Статья выше — это мусор или ты хочешь сказать, что JVM или HTML5 будут работать быстрее нативного кода C++/Qt? О чём здесь речь вообще?! Какие тебе цифры надо?
                                                                                                            0

                                                                                                            Ну кстати в теории же html + js по такой же схеме работают как и qml + js. И там и там язык разметки плюс клей из js.
                                                                                                            Просто qml намного лучше задизайнен. А вот javafx увы, не сможет тягаться никогда, у нее сам рендер тоже на джаве, он никогда не будет столь же быстр как нативный.

                                                                                                              0
                                                                                                              Ну кстати в теории же html + js по такой же схеме работают как и qml + js. И там и там язык разметки плюс клей из js.

                                                                                                              "В теории", а на практике, когда скорости JS начинает не хватать — переносишь логику в C++ и всё начинает летать на порядок быстрее — проверял. Ну и "разметка" в QML — это нативные C++ объекты QML Items с аппаратным ускорением, так что они тоже сильно быстрее HTML.

                                                                                                                0

                                                                                                                Я думаю htmlные теги тоже в итоге мапятся на нативные обьекты, да и логику же тоже можно писать в плюсах и прокидывать в вебню. По крайней мере, так точно можно было в QtWebKit делать

                                                                                                                  0

                                                                                                                  В QML можно реализовать любой новый элемент на плюсах, унаследовав его от QQuicklItem, если он визуальный, или просто от QObject, если нет, и легко и просто интегрировать его в остальной QML код. А вот как реализовать подобным образом кастомный html тег — я что-то сходу даже и не знаю.

                                                                                                                    0
                                                                                                                    Я как-то задумывался над реализацией UI на WebKit. Кастомный html тег не нужен. Идея была в следующем:
                                                                                                                    На html+css+js делаем типичный веб UI (не исключено и использование популярных в js фреймворков). Далее делаем интерфейс C++ -> js. В QtWebKit это выглядело как C++ класс на одной стороне и аналогичный js объект на другой. Ну так вот, через этот интерфейс все данные и таскаем.
                                                                                                                      +1

                                                                                                                      "Кастомный html тег не нужен" напоминает мне анекдот про "потребности в колбасе на сегодня нет". А если мне нужен именно визуальный компонент? Что мне толку с этого js объекта, если я не могу его отобразить? Мне придётся корячиться и пытаться лепить что-то на js стороне из DOM объектов. А с QML я на C++ стороне его нарисую именно так, как мне надо, хоть через scenegraph, хоть через QPainter, да и все. Быстро, просто, экономично в плане ресурсов.

                                                                                                                        0
                                                                                                                        А, вы в плане вставки кастомных компонентов. Это да. Сам сейчас копаю сей вопрос. Теоретически можно (всякие Flash в своё время так и встраивались со стороны браузера), но явно не просто
                                                                                                                    0
                                                                                                                    можно было

                                                                                                                    Но ведь не сделано, правда? :) Или вы предлагаете аналог Qt с нуля написать?! :)

                                                                                                                      0

                                                                                                                      По хорошему, сейчас можно смотреть в сторону WASI, wgpu и всего такого. Все вместе это смогло бы вырасти в куда более универсальное и прикольное решение.
                                                                                                                      Можно языки разметки типа qml напрямую в wasm транслировать, а с хоста прокидывать нужные методы.

                                                                                                                        0

                                                                                                                        Ну дык Qt туда и смотрит: https://doc.qt.io/qt-5/wasm.html

                                                                                                                          0

                                                                                                                          Блин, самой либе уже 30 лет, это вот прямо говоря, очень много, очень очень. То, что они запускаются внутри wasm это круто, но они при этом тащат огромный техдолг вовнутрь.

                                                                                                                            0
                                                                                                                            Ну и что, что либе 30 лет? Все эти 30 лет она развивалась. Если вы сейчас начнете что-то новое велосипедить, то паритета по фичам достигнете еще условно через 30 лет, и то если Qt все это время будет стоять на месте. Это не говоря уж о том, что веб — это всего лишь одно направление для Qt из многих, потому что веб подходит не всегда и не всем.
                                                                                                                    0
                                                                                                                    касательно
                                                                                                                    когда скорости JS начинает не хватать — переносишь логику в C++

                                                                                                                    Есть надежда что WebAssembly позволит точно так же, но в html
                                                                                                                      0

                                                                                                                      Ну у WASM-а скорость уже будет сравнима с Java или C#, до C++ всё равно будет недотягивать.

                                                                                                                        0
                                                                                                                        Уже это немало, особенно если разовьют идею.
                                                                                                                    +2
                                                                                                                    И для некоторых вроде меня явная нелюбовь разработчиков Qt к QВиджетам вызывает неприятные ощущения под спинным мозгом.
                                                                                                                      –1
                                                                                                                      Может дело в прямоте рук? Вон intellij idea на swing работает шустро, а это более старая технология.
                                                                                                                        0
                                                                                                                        совсем не шустро, а в виртуалке так даже напряжно
                                                                                                                          0

                                                                                                                          Это называется шустро? Плохое время отклика в среднем и фризы в рандомные моменты, причем в случае рендера чего-нибудь типа markdown вообще слайдшоу, будто бы запускаешь код на калькуляторе.

                                                                                                                            +1

                                                                                                                            Если сравнивать с KDevelop, то IntelliJ — тот ещё тормоз.

                                                                                                                              +1

                                                                                                                              Согласен, что IntelliJ тормоз. Кстати, борландовские гуевые среды просто реактивными кажутся по истечению стольких лет...

                                                                                                                                +1

                                                                                                                                С другой стороны с kdevelop сравнивать сложно, потому что на моём плюсовом проекте он падает при индексации, а clion — не падает.

                                                                                                                        0
                                                                                                                        Там им в комментах написали, что даже для rpi3 интерфейс сильно тормозит.
                                                                                                                          –1
                                                                                                                          Немного не профессионально. Мало того, что там видео заминусили, так вы сюда тащите этот шлак как аргумент.
                                                                                                                          Вы бы еще видео Антона Полухина здесь запостили.
                                                                                                                          Давайте с примерами, того, что можно запустить у себя на машине. Я начну.

                                                                                                                          Вот, скачайте(не надо выбирать онлайн) и кликните самый большой датасет. Поиграйтесь, посмотрите на зумы и прочие фишечки.
                                                                                                                          А потом вернитесь и покажите мне такой аналог на плюсах, но чтобы не тормозил.

                                                                                                                          dlsc.com/products/flexganttfx
                                                                                                                            0
                                                                                                                            Вообще странно. Люди, которые пишут на плюсах должны быть максимально объективны.
                                                                                                                            Ведь это те самые локомотивы, что двигают прогресс.
                                                                                                                            Они как никто другой сталкиваются с проблемами, которые скрыты от какого-нибудь среднего разработчика.
                                                                                                                            И они как никто другой, должны понимать, на сколько сложно объективно измерять перформанс.

                                                                                                                            Но смотришь на комменты и некоторых индивидов и диву даешься.

                                                                                                                            Ведь сам javafx писан на плюсах, как и JVM. И те плюсовики, которые пишут JVM, от них редко услышишь подобного рода заявления. Ну то есть люди, которые создают продукты, которые реально двигают миллиардные бизнесы по миру.
                                                                                                                            А тут приходит «Вася из Ульяново» и рассказывает, как же джава тормозит, аж скулы сводит.
                                                                                                                            Без аргументов, без цифр, без примеров, без замеров. Человеческий фактор.
                                                                                                                              0
                                                                                                                              А тут приходит «Вася из Ульяново» и рассказывает, как же джава тормозит, аж скулы сводит.

                                                                                                                              Можно вопрос из зала? Вот смотрите. Есть чудесный проект Кассандра. Как известно, он на Джаве. Но его зачем-то переписывают на C++ — ScyllaDB. Если джава прекрасно, то зачем так делают? Все-таки, значит, есть проблемы в джаве и с перформансом, и с выделением памяти. И ребятки решили бороться с этим самым радикальным методом. Нет? Это не означает, что "джава тормозит". Это реально миф из бородатых времен. Но возможно, что есть типы задач, которые лучше делать тут, а другие типы задач — там.

                                                                                                                                +1
                                                                                                                                Не, проблемы конечно есть. Вы платите железом за условную абстракцию, за скорость разработки, за надежность и прочее.
                                                                                                                                Поэтому такие продукты появляются на джаве. Это быстрее и дешевле.
                                                                                                                                Когда нужен топ, то нужны или плюсы или раст и тогда переписывают.
                                                                                                                                Конечно, грамотная реализация на плюсах будет быстрее.

                                                                                                                                С такими очевидными вещами никто и не спорит. Вот питон реально медленный, тут мало что попишешь, но даже у него огромная ниша. Особенно в связке со всякими плюсовыми либами.
                                                                                                                                  +1
                                                                                                                                  У переписывания, может быть 1000 непонятных причин. Java с 1.6 прекрасно работает с нативной памятью и имеет достаточно нормальную интеграцию с С++.

                                                                                                                                  Сложно представить, что проблемы с performance, которые возможно затрагивают 1-5% кода, нельзя оформить доп. нативной библиотекой. А какой-нибудь менеджмент вообще не про performance.

                                                                                                                                  Я подозреваю, основная причина все-таки embedded и AOT, который Java никак не расдуплится сделать с другими фишками типа Canadian Cross.
                                                                                                                                    0
                                                                                                                                    Сложно представить, что проблемы с performance, которые возможно затрагивают 1-5% кода, нельзя оформить доп. нативной библиотекой

                                                                                                                                    Во многих приложениях это UI — 1-5% кода, а 95% делом занимается а не формочками :). И если на плюсах начинает жить логика (а это очень часто так для подобных приложений) то всё, хана, интерфейс быстро разрастается и становится непонятным, так что оказывается в разы проще UI на плюсах сделать. И в случае с Qt это вдобавок получается очень удобно, просто в разы удобнее того же C#. По части удобства какой-нибудь мелкой разработки где язык работает клеем между С++ библиотеками, на мой взгляд рулит Python. Там хорошо прототипы пишутся по принципу «все медленное пихаем в плюсовую библиотеку, всю логику оставляем в Python, для UI прикручиваем PyQt». С Java правда не работал (если не считать написания небольшого плагина для ImageJ) но по отзывам слышал (да и мне самому так показалось) что он плюс-минус на C# похож.
                                                                                                                                      0
                                                                                                                                      Тут вроде про DB разговор, там UI вообще нет, но тонны код по оптимизации, парсингу и т.п., а ядро базы данных где нагрузка 99%, в БД-проектах где-то 10% максимум.
                                                                                                                                      Про «типичный» проект говорить нельзя, но, конечно, же UI -кода в 10 раз больше, чем backend.
                                                                                                                                      –1

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

                                                                                                                                        –1

                                                                                                                                        У джавы больой throughput но малый latency. Я так понимаю это фундаментальный момент всех гц. Плюс джит на эмбеддед так себе надо полагать

                                                                                                                                          0
                                                                                                                                          У Java максимальный throughput при заданном железе, но если надо гарантировать 95% заданной скорости, например 10 мс на http response, то это не работает.
                                                                                                                                          Потому что, 1) JIT — который пока раскочегарится и соберет статистику 2) GC — может выпадать в ненужные моменты.
                                                                                                                                          По сути если мерить кол-во http response в 1 минуту на заданное железе, то throughput будет одинаковый или лучше. А вот хвост 5-15% самых медленных запросов, будет гораздо хуже.
                                                                                                                                  0
                                                                                                                                  в видео демки запущены на дохлых планшетиках. что вполне соответствует панелькам в промышленности или автомобильных
                                                                                                                              0
                                                                                                                              В целом flutter очень близок к qml, и гугл обещает выкатить связку flutter + dart под desktop, может и отожмет какую то часть рынка у Qt.
                                                                                                                                0
                                                                                                                                Проблема в том, что Qt можно легко интегрировать с другими библиотеками на C++, а у флаттера будут проблемы.
                                                                                                                                  0
                                                                                                                                  это да, в целом у fluttera проблемы что пока что всего очень мало, но конкуренция это всегда хорошо. Я рад за это
                                                                                                                                  +1
                                                                                                                                  В целом flutter очень близок к qml
                                                                                                                                  Идеологически может и да, а по синтаксису сильно хуже :/
                                                                                                                                    0
                                                                                                                                    Тут согласен, но вроде там тоже были подвижки
                                                                                                                                  +3
                                                                                                                                    +3
                                                                                                                                    Что еще ждать от Qt?! Они уже пару десятилетий не могут пофиксить корректную работу путей в windows, содержащих нелатинские символы.
                                                                                                                                      +3

                                                                                                                                      Поэтому по моему лучше форк (тем более, если KDAB готов вписаться), чем полных отказ от Qt и переход на Web, что есть полнейший бред для многих задач!

                                                                                                                                        0

                                                                                                                                        Как может форк решить лицензионную проблему с мобильными приложениями, про которую писал автор поста?


                                                                                                                                        Кстати говоря, а каким пунктом LGPL создана такая проблема?

                                                                                                                                      0
                                                                                                                                      не встретил проблем, да там обрабатывать надо иначе, но это точно не критикал
                                                                                                                                      +1

                                                                                                                                      Недавно встал выбор библиотеки для проекта, который должен быть «кросс». Выбор был между Qt, Java и «чем угодно ещё». Java не очень люблю (субъективно, хотя на 13 уже можно существовать), к тому же нужно было в любом случае писать код на плюсах для критичной к быстродействию части, а JNI — боль, так что его отбросил почти сразу. В Qt сомневался, поскольку не очень хорошо отзывались мои сотрудники о нём. В итоге погуглил, и понял, что у меня есть минимум ещё 2 варианта — SDL и wxWidgets. Присмотрелся ко второму (соблазнило использование нативных системных компонентов), и понял, что это «оно». С системой layout разобрался достаточно быстро, с быстродействием проблем нет — ибо native. С лицензированием глубоко не вкуривал, но вроде тоже всё спокойно.

                                                                                                                                        +3
                                                                                                                                        У wxWidgets вроде все совсем плохо с мобильными платформами.
                                                                                                                                          0
                                                                                                                                          Зачем нужен JNI, когда есть JNA
                                                                                                                                            0

                                                                                                                                            Ещё одну библиотеку тащить...

                                                                                                                                            +1
                                                                                                                                            Пытался написать на wxWidgets десктоп приложение лет десять назад. Количество плохо документированных функций, непонятных багов ( когда нужно делать именно так а не иначе чтоб работа ) просто поражаеет. Не знаю улучшились ли они за эти годы, но тогда это был плохой выбор.
                                                                                                                                              0

                                                                                                                                              Не знаю, может, мы с разработчиками «нашли друг друга», но в документацию пришлось вкуривать всего пару раз, на неочевидных названиях контролов и на тонкостях работы с OpenGL (адепты Вулкана — молчать, сам о нём знаю, но для первого прототипа юзал что умею). Остальное кодил на интуиции, и оно работает как задумано.

                                                                                                                                            +4

                                                                                                                                            О, автор, прямо на больную мозоль!
                                                                                                                                            Я недавно сам озадачился этим вопросом и решил перейти на что-то близкое, желательно, что-то на C++. Хотел начать для себя разрабатывать большое приложение на Qt, хотя многое в Qt не нравилось — монструозность, проникновение не только в GUI, но и в логику, отставание от стандарта. Изменения в политике Qt стали последней каплей. Основное требование к новому фреймворку стала открытость, ± нативность на Linux и простота разработки.


                                                                                                                                            Путём исключения дошёл до GTK+ (gtkmm). На нём Gnome написан, если кто не знает. Так вот, язык может и хороший, но инструментальная обвязка — тихий ужас. Я попытался запустить проект Hello World по умолчанию из их среды разработки Builder IDE — не получилось с трех раз!!! Попытался запустить Glade (инструмент разработки UI для GTK+) — Glade упал. Добавить к этому почти полное отсутствие поддержки Android. В общем, отказался я от него.


                                                                                                                                            Решение пришло неожиданно. Обнаружил для себя GUI-фреймворк Kivy для python. Простейшую программку для него я набросал за время компиляции hello world для gtk. И я влюбился в kivy. Это реально простой GUI-фреймворк, построенный на sdl2. У него есть собственный простой язык разметки интерфейса (аналог qml) — kv (сравните с многословным xml-based у GTK+).


                                                                                                                                            Пусть kivy, возможно, не подходит для production, пусть у него есть некоторые нелогичности в поведении, но мне он настолько понравился своей простотой и наличием неплохой документации, что я первый раз в своей жизни сделал донат и очень этим гордился. Уже месяц как пишу на киви, вижу кучу странных решений, но всё ещё очень им доволен.


                                                                                                                                            Кстати, на хабре недавно вышла статья по библиотеке для kivy, адаптирующей внешний вид к android — kivymd.

                                                                                                                                              +5

                                                                                                                                              Насчёт отставания от стандарта — да, Qt не на bleeding edge развития C++, но подвижки идут. Например, тот же новый (относительно, ему уже несколько лет) синтаксис сигналов-слотов на указателях на функции, или отказ от собственных алгоритмов в пользу STL. Опять же, чтобы понять путь библиотеки, нужно "обуть ее обувь" — фреймворк появился в годы черти какой поддержки стандартов, единственным выходом было использование минимального и гарантированно подерживаемого подмножества языка. С тех пор все изменения в пользу новых стандартов предпринимаются с учётом всех поддерживаемых платформ!
                                                                                                                                              Насчёт проникновения не только в GUI, но и логику, как Вы говорите — все же Qt это фреймворк, он и не позиционируется как библиотека, поэтому все логично. Т.е. предлагается некий скелет, некий подход к организации приложения, следуя которому можно реализовать что-то удобно и комфортно. Если идти против его идеологии, боль неизбежна.

                                                                                                                                                0

                                                                                                                                                Я бы и продолжал пользоваться Qt для своих pet-проектов (я даже 2D-игру на нём начал делать), технические ограничения — не основная причина перехода. Хотя тут тоже такое. Пытался я сделать кнопку-иконку или кнопку с иконкой и текстом — не нашёл такого механизма из коробки, хотя это частый use-case. Но это так, не важное.


                                                                                                                                                Что важно — это политика Qt в отношении сообщества. Захотят закрыть фреймворк — закроют, они продемонстрировали, что мысли в ту сторону у них уже имеются. А ведь другой представитель KDЕ сказал, что вряд ли они потянут форк Qt. И никто не потянет Qt — там слишком много экспертизы нужно, чтобы поддерживать и qml, и widgets, и moc, и кросс-платформенность, и qt core (QList, QString, ...).


                                                                                                                                                А взять тот же kivy. Ну скажет автор, что закрывает код kivy. Так тут только одно русскоязычное сообщество сможет поддержать продукт — это же обертки на cython вокруг SDL + простой транслятор для kv. Совсем не rocket science. Поэтому для себя я замену нашёл. Я понимаю, что Qt гораздо больше, чем просто GUI, но я, к примеру, хочу свои pet-проекты программировать ради удовольствия, не беспокоясь, что завтра фреймфорк закроется.


                                                                                                                                                P.S. Кстати, у kivy еще и довольно активное community, которое помогает. (это в тему про удовольствие)

                                                                                                                                                  +1
                                                                                                                                                  Захотят закрыть фреймворк — закроют
                                                                                                                                                  Полностью — не могут. У них контракт с KDE, по которому они обязаны открывать код не позднее чем через год после его появления под коммерческой лицензией.
                                                                                                                                                    +6
                                                                                                                                                    Если вы не смогли на qml сделать кнопку с текстом, то вы как то плохо в нем разобрались, уже 4 года пишу gui на qml и не было еще графического элемента который невозможно было создать, просто и легко. Так что QML прекрасен
                                                                                                                                                      0

                                                                                                                                                      Ну, во-первых, да, qml хорош. А не могли бы вы здесь продемонстрировать код на qml для кнопки с текстом и иконкой?

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

                                                                                                                                                        Button {
                                                                                                                                                            Row {
                                                                                                                                                                Image {}
                                                                                                                                                                Text {}
                                                                                                                                                            }
                                                                                                                                                        }


                                                                                                                                                          0
                                                                                                                                                          Зачем Button? или это ваш кастомный?
                                                                                                                                                            0
                                                                                                                                                            Да, это я зря, у Button'a и так все есть :) Не проснулся!
                                                                                                                                                          +2
                                                                                                                                                          способов там тыща, в зависимости какую действительно кнопку вы хотите. Есть стандартаная кнопка из QtQuick.Controls
                                                                                                                                                                          Button {
                                                                                                                                                                              text: "example"
                                                                                                                                                                              icon.source: "qrc:/source.png"
                                                                                                                                                                              onClicked: {}
                                                                                                                                                                          }
                                                                                                                                                          

                                                                                                                                                          если хочется совсем свое, то можно как в конструкторе все построить через Item как базу
                                                                                                                                                                      Item {
                                                                                                                                                                          implicitHeight: childrenRect.height
                                                                                                                                                                          implicitWidth: childrenRect.width
                                                                                                                                                                          Row {
                                                                                                                                                                              Image{}
                                                                                                                                                                              Text{}
                                                                                                                                                                          }
                                                                                                                                                                      }
                                                                                                                                                          
                                                                                                                                                            –1

                                                                                                                                                            Те, кто говорят про icon.source (kanutah) не забывайте, что возможность эту добавили только 2 или 3 года назад, до этого никаких icon.source в стандартной поставке не было. А когда Qt 5 вышел? в 2013 году? И всё это время чего-то не хватало — то иконки не встроишь без костылей, то layouts ещё толком не завезли. Примерно об этом ниже и говорит Harrix. Сейчас, кстати, Qt5 более-менее юзабелен. Но на горизонте уже маячит Qt6 и возможное закрытие релизов на 12 месяцев.
                                                                                                                                                            Кстати, у меня этот ваш первый способ когда-то так и не получилось завести нормально. Вот я прямо сейчас его попробовал — на простом изображении он работает, а на иконке с высоким разрешением — просто не отображает её, отображает черный квадрат. Из моего опыта — метод есть, метод работает, но часто работает он не так, как от него ожидаешь. При сборке в тот же андроид, куча настроек слетают, иконки иногда даже простые не отображаются. Но это только мой опыт, а я не самый лучший программист.
                                                                                                                                                            Про использование Row. Вот мне приходилось примерно так и выкручиваться, чтобы заработало. Только ведь если вы используете Item, то вам надо и обертку писать, чтобы имитировать поведение кнопки.
                                                                                                                                                            Но вообще, как я говорил, техническая часть не является проблемой. Я и игру на Qt для себя писал, с картинками и анимациями там работал — проблем особых не возникло. Основная проблема — политика Qt Project. QtRoS пишет, что я недооцениваю сообщество, видимо полагая, что KDAB и сообщество сможет поддерживать форк. Поддерживать — сможет, а развивать? У них приоритетный проект — KDE, разработчиков на зарплате даже для KDE не особо-то много. А уж вытянуть команду, которая будет развивать целый фреймворк с двумя языками программирования (C++, QML), у них и подавно не получится.
                                                                                                                                                            В общем, для своих пет-проектов я выбор сделал. Мне лишний стресс не нужен, поэтому я отказался от Qt, несмотря на то, что Qt более продвинут, чем киви в любом из аспектов.

                                                                                                                                                              +2
                                                                                                                                                              обертка для того чтобы сделать из Item кнопку это строчек 15-20 и потом юзаете на весь проект. А ваши проблемы выглядят как просто отрицание, если что мы вас не заставляем сидеть на qml, но и гнать на него надо
                                                                                                                                                                +2
                                                                                                                                                                Те, кто говорят про icon.source (kanutah) не забывайте, что возможность эту добавили только 2 или 3 года назад, до этого никаких icon.source в стандартной поставке не было.

                                                                                                                                                                Ну сначала в Qt5 были Quick Controls 1, потом вышли Quick Controls 2. Идет постепенное развитие. Но QML тем и хорош, что у него очень мощные примитивы. По сути любую кнопку можно сделать, скомбинировав rectangle, image/text и mousearea. Ограничения практически отсутствуют.

                                                                                                                                                                Вот я прямо сейчас его попробовал — на простом изображении он работает, а на иконке с высоким разрешением — просто не отображает её, отображает черный квадрат.

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

                                                                                                                                                                Button {
                                                                                                                                                                    icon.source: "path/to/icon.png"
                                                                                                                                                                    icon.color: "transparent"
                                                                                                                                                                }
                                                                                                                                                                

                                                                                                                                                                Я сейчас попробовал засунуть в кнопку изображение 4096x4096 (это же достаточно высокое разрешение?) — отобразилось нормально, по крайней мере на десктопе.

                                                                                                                                                                При сборке в тот же андроид, куча настроек слетают, иконки иногда даже простые не отображаются.

                                                                                                                                                                Ну, это странно. У меня есть несколько pet-проектов на Qt для iOS и Android, не сталкивался с чем-то таким. Ну точнее такое может быть наверное, если вы как-то хардкодите пути к картинкам вместо использования ресурсов, а картинки кладутся куда-то не туда, куда вы ожидаете, но в целом у меня как-то таких проблем не было, честно говоря.

                                                                                                                                                                Основная проблема — политика Qt Project

                                                                                                                                                                У Qt Company уже давно такая политика. Они постоянно балансируют между стремлением заработать денег и стремлением не потерять сообщество. И будут этим заниматься дальше. Такова их тяжелая доля. Устраивать по этому поводу истерики я бы не стал.
                                                                                                                                                                  0
                                                                                                                                                                  У Qt Company уже давно такая политика. Они постоянно балансируют между стремлением заработать денег и стремлением не потерять сообщество.

                                                                                                                                                                  Вот поэтому я и решил сменить фреймворк. Пусть они себе балансируют, а мне нервы дороже. Я сменил фреймворк и очень этому рад. Киви в десятки раз хуже, чем Qt, но мне его функциональности хватает. Для меня главное — душевное спокойствие, которого с балансирующим Qt мне не получить.

                                                                                                                                                              +2
                                                                                                                                                              Стандартная кнопка из Quick Controls 2 с иконкой и текстом под ней будет выглядеть примерно так:

                                                                                                                                                              Button {
                                                                                                                                                                  icon.source: "path/to/icon.png"
                                                                                                                                                                  text: "Button"
                                                                                                                                                                  display: Button.TextUnderIcon
                                                                                                                                                              }
                                                                                                                                                              


                                                                                                                                                              Искаропки, естественно. Плюс ее можно дополнительно стилизовать. Ну а так да, способов просто миллион.
                                                                                                                                                            0
                                                                                                                                                            Закрытие фреймворка в эти дни эквивалентно форку, поэтому этот сценарий хоть и является неприятным, но не пугает.
                                                                                                                                                            там слишком много экспертизы нужно, чтобы поддерживать и qml, и widgets, и moc, и кросс-платформенность, и qt core
                                                                                                                                                            Мне кажется Вы недооцениваете сообщество. Люди коммитят в .NET Core, в Go, в VS Code, в K8S — там тоже многослойно.
                                                                                                                                                          0
                                                                                                                                                          Спасибо за наводку, но я тоже в своё время его пробовал, тоже понравилось. Пока не применил на Андроиде. Не знаю как сейчас, но тогда интерфейс прям вот очень заметно тормозил. Не то что медленно, а именно тормозил. Но я даже не про скорость, а про то, что такие вещи намекают на «зрелость» продукта. А так да — Kivy приятная штука.
                                                                                                                                                            0
                                                                                                                                                            В kivy всё прекрасно, но их сайт не открывается (спасибо РКН). И когда надо распространить результаты своего творчества, вы будите виселиться (виселица находится в конце деревни).
                                                                                                                                                            +2
                                                                                                                                                            Попробуйте wt — веб-фреймворк на С++
                                                                                                                                                              0
                                                                                                                                                              Статья кстати однобокая и алармистская полностью, про то что LTS платные он сказал, но ведь это не означает что Qt платный стал, просто все будут сидеть на одной dev ветке. Так что рано еще лить слезы по Qt
                                                                                                                                                                +7

                                                                                                                                                                Простите за дурацкий вопрос, но я хотел бы уточнить: вы недовольны тем, что владельцы Qt старательно уменьшают количество вариантов бесплатного использования Qt в закрытых коммерческих разработках и при этом держат слишком высокие цены на коммерческую версию Qt. Правильно я вас понял?

                                                                                                                                                                  0
                                                                                                                                                                  Они в том числе перекрывают возможность создания проектов по MIT лицензии, если программист будет использовать какие-то GPL библиотеки от Qt. А как видно, Qt всё больше своих библиотек распространяет по GPL лицензии в бесплатной версии. При LGPL такая возможность была.
                                                                                                                                                                    +2

                                                                                                                                                                    Это понятно, но это не ответ на мой вопрос.


                                                                                                                                                                    PS. Qt под LGPL так же появилась не сразу, минимум лет 10 до этого Qt вообще была доступна только под двумя лицензиями: коммерческой и GPL.

                                                                                                                                                                      0
                                                                                                                                                                      Ну, лично я тогда относился к ней с осторожностью, потому что использовать по работе один фреймворк, а для себя — другой неудобно.
                                                                                                                                                                    0
                                                                                                                                                                    Вопрос не дурацкий. Нет, не только этим. Меня волнуют последствия и как это скажется на продукте. Если сейчас годами баги висят, то что там при политических пертурбациях дальше может получиться…
                                                                                                                                                                      +1
                                                                                                                                                                      Если сейчас годами баги висят, то что там при политических пертурбациях дальше может получиться…

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


                                                                                                                                                                      Но, раз они висят годами, то можно предположить следующее: те, кто используют Qt забесплатно, мало отдают взамен. А тех денег, которые владельцы Qt собирают с покупателей коммерческих решений, недостаточно для увеличения штата разработчиков.


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


                                                                                                                                                                      PS. Сам я придерживаюсь точки зрения, что цена на коммерческую лицензию высоковата (раньше она была пониже). Но саму Qt следовало бы распространять всего под двумя лицензиями: GPL и коммерческой. По крайней мере в ситуации, пока Qt Group вынуждена сама зарабатывать на разработке Qt и не имеет богатого донора (как это было после покупки TrollTech фирмой Nokia).