Таури и линукс

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

Из плюсов - мало весит бинарник. Шустрое, мало жрет на старте (но примерно как и на раст). Работает в линуксе…

На этом плюсы заканчиваются. Уже сейчас один экземпляр у меня завис в памяти и разожрался до 240 метров. Я чисто случайно заметил. Сборка под винду походу закончится лютым провалом. Гитхаб собирет проект уже 46m 20s. Прости меня раст, за твои жалкие 8 минут сборки. Вот как поддерживать такой проект, если надо собирать под винду и линукс? Тут уж проще всетаки два разных держать - электрон под линукс и тот же таури под винду. Разве что разобраться, как собрать нормально.

Ну почему все через жопу везде? Или это просто мне опыта и знаний не хватает?

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

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

https://github.com/Vladgobelen/NSQCuC понаблюдаем уже завтра видимо этот фейл со сборкой. Интересно уже из спортивного интереса чего я там так накосячил в скрипте сборки и сколько оно протянет.

Уже сейчас один экземпляр у меня завис в памяти и разожрался до 240 метров. Я чисто случайно заметил.

Очень рекомендую освоить valgrind и/или clang-овские санитайзеры!!! Заодно и вопросы безопасности закроешь. Valgrind вообще убойная штука, я вообще, когда кто-то спрашивает, почему я не хочу кодить и отлаживаться под виндой, невинно хлопаю ресницами и прошу показать мне тамошний аналог valgrind, только не dr.Memory, это жалкое подобие. Он показывает утечки памяти, ну и если где-то нарушение работы с памятью, он спамит в консоль указание на это с точностью до функции. Если сочетать это с собственными

std::cerr << "Vasya was here; i=" << i << std::endl;

…то факап отлавливается с точностью до строки. Ещё есть статические анализаторы кода, которые не заменяют, но дополняют работу с валгриндом. И люди, которые всем этим умеют пользоваться, обычно не очень понимают, какую такую дополнительную супер-пупер безопасность им даёт раст (но тут можно поспорить, да).

Сборка под винду походу закончится лютым провалом. Гитхаб собирет проект уже 46m 20s. Прости меня раст, за твои жалкие 8 минут сборки.

А это всё потому, что модули. Они есть в расте и они были, на минуточку, в борландовском турбопаскале в 1989 (восемьдесят девятом, Карл!) году. В плюсах завезли только в C++20. Ты, скорее всего, пользуешься классическими плюсами с костылями на изоленте в виде #include и стражей компиляции. Кто жалуется на тупость нейросетей, тот никогда не задумывался, как в плюсах (и классической сишке, из которой они это и притащили) работает связка препроцессор-компилятор-линкер. Спойлер: чудовищно неэффективно она работает.

Есть такое, это недостаток плюсов, надеюсь, что всё же в ближайшие годы изживут. Плюс если твоя система сборки бэкендом вызывает GNU Make – она под виндой вообще работает более задумчиво, чем под линуксом (буквально в разы).

Рецепты: 1) если можно, под винду билдить всё же не гитхабом, а локально (если есть возможность найти локальную винду, пусть даже в виртуалке – я понимаю, что это не всегда возможно); 2) попробовать под виндой вместо make использовать ninja, она быстрее, и ЕМНИП, её можно подружить со cmake; 3) потихоньку посматривать в сторону C++20+ :)

Я никогда не считал плюсы идеальным языком. Но блин, это настолько универсальная, вездесущая и неприхотливая рабочая лошадка (в особо тяжёлых случаях позволяет до уровня традиционной сишки опускаться, а в противоположных случаях, когда надо поделить на части особо сложную гору кода – навертеть 5 слоёв абстракций), на которой можно написать ВСЁ, что недостатки и проблемы (решаемые) я ей прощаю :)

P.S. А раст интересная тема. Я хочу его погонять поплотнее. Но хорошим поводом для этого был бы принципиально новый хобби-проект, без груза совместимости, и желательно без GUI и работы с БД, пока такого не подворачивается :)

мало весит бинарник

Это пока не настанет необходимость qt определенной версии с собой таскать :) Электрон конечно не догонишь, но «мало» это тоже не назовешь.

failed 3 hours ago in 2h 41m 44s

Ладно. План не удался. Но было близко. Модули то модули, но не настолько же.

P.S. А раст интересная тема. Я хочу его погонять поплотнее. Но хорошим поводом для этого был бы принципиально новый хобби-проект, без груза совместимости, и желательно без GUI

С простым gui проблем нет уже на расте, тот же egui например и легковесен и просто осваивается.

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

https://github.com/Vladgobelen/NSQCuE/tree/main/global-mouse-hook

Вот пример проекта, но работает криво и линукс часть переписать надо. А виндовую доделать.

таури

Сколько его не пробовал, вечно какие-то траблы.

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

Приколов с прописанным «http_proxy» в debug, когда получаешь:

При получении URL http://localhost:1420/ произошла следующая ошибка

Соединение с ::1 не удалось

Система вернула: (111) Connection refused

от прокси.

Приколов с модальными окнами открытия фалов. И т.д. и т.п.

Мне его много тут рекомендовали на ЛОРе в разных темах, я и решил глянуть. Но пока побороть безопасность не смог. Его разрабы решили, что на линуксе использование таури небезопасно. Ну, точнее не они, а разрабы вебкитГтк.. Там вообще клиника.

Там вообще клиника.

Клиника походу со всем GUI. В Rust это ещё сильнее ощущается.

Мне нужны простые GUI, с набором, как мне казалось, простых требований.

• Иметь возможно для пользователя выделить и скопировать в буфер обмена выведенный текст (не только из поля ввода).
• Иметь возможность вставить текст из буфера обмена в поле ввода.
• Перейти с компонента на компонент клавишей tab.
• Нажать кнопку на форме кнопкой Enter.

Перебрал всё. И результат как раз описывается фразой «Там вообще клиника».

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

Надо попробовать Qt к нему подключить. Посмотрю варианты.

то кроме гтк ничего и нет, внезапно.

1. GTK4. Недоделанный. Который реально использовать, разве что в flatpack. И для написания для старых LTS дистрибутивов совсем не подходит.

2. GTK3 в rust два года как заморожен https://github.com/gtk-rs/gtk3-rs

3. В этом случае Qt под rust даже более приятен. https://kdab.github.io/cxx-qt/book/

GTK4. Недоделанный.

Если речь про сам тулкит, то не замечал такого.

для написания для старых LTS дистрибутивов совсем не подходит

Он лет 5 уже как везде есть. Понимаю, если на сервере что-то более старое стоит и работает, но там гуй не нужен, а на десктопе такое старьё зачем?

Qt

Если хорошо работает и удобно в использовании, то можно попробовать.

Я пока не сдался до конца. Я нашел согильдийца с виндой, нагуглил как работает павершелл и скинул ему скрипты и команды. Первая сборка длилась 3,5 часа, выжрала у него 70гб винта и вылетела….

-- Setting up python virtual environment...
-- Installing python packages: --no-index;C:/vcpkg/downloads/html5lib-1.1-py2.py3-none-any.whl;C:/vcpkg/downloads/six-1.17.0-py2.py3-none-any.whl;C:/vcpkg/downloads/webencodings-0.5.1-py2.py3-none-any.whl
-- Setting up python virtual environment... finished.
CMake Warning at buildtrees/versioning_/versions/qtwebengine/435c8f8e58ccaa2ffc6ff4e129effdaefbc00f30/portfile.cmake:186 (message):
  Buildtree path 'C:/vcpkg/buildtrees/qtwebengine' is too long.

  Consider passing --x-buildtrees-root=<shortpath> to vcpkg!

  Trying to use 'C:/vcpkg/buildtrees/qtwebengine/../tmp'
Call Stack (most recent call first):
  scripts/ports.cmake:206 (include)


CMake Error at buildtrees/versioning_/versions/qtwebengine/435c8f8e58ccaa2ffc6ff4e129effdaefbc00f30/portfile.cmake:191 (message):
  Buildtree path is too long.  Build will fail! Pass
  --x-buildtrees-root=<shortpath> to vcpkg!
Call Stack (most recent call first):
  scripts/ports.cmake:206 (include)
error: building qtwebengine:x64-windows failed with: BUILD_FAILED
See https://learn.microsoft.com/vcpkg/troubleshoot/build-failures?WT.mc_id=vcpkg_inproduct_cli for more information.
Elapsed time to handle qtwebengine:x64-windows: 1 min
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
  https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+qtwebengine
You can submit a new issue at:
  https://github.com/microsoft/vcpkg/issues/new?title=%5Bqtwebengine%5D%20build%20error%20on%20x64-windows&;body=Copy%20issue%20body%20from%20C%3A%2FUsers%2Fwhite%2FDownloads%2FNSQCuC-main%2Fvcpkg_installed%2Fvcpkg%2Fissue_body.md

Completed submission of gperf:x64-windows@3.3 to 1 binary cache(s) in 101 ms

Темные стороны плюсов меня вводят в задумчивое состояние. Я хз как выразить это словами.

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

Клиент на андроид занял полчаса написания кода. Сборка, если не считать 3 часов установки и изучения андроид студи и как она работает - там что то в секундах.

Электрон собирается что то о 1,5 до 8 минут в зависимости от среды и процессора. Таури собиратся от 3 до 8 минут. Да даже го примерно на уровне раста. Я проверял, пробовал, писал. Чуть чуть меньше удобств, но в целом - то же самое почти.

При этом полностью отсутствуют хоть какие то удобства и единство среды разработки на плюсах. Я видел, что майкрософн вон запилило что то более менее похожее на удобство, но это «удобство» описано вон выше в начале сообщения и работает каки все от майкрософт.

Это я так, для себя пытаюсь выразить свои мысли о языках и думаю о пути дальше. Плюсы сравниваю, минусы, особенности.

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

Но я что то не верю, что разрабы на винде и под винду так вот часами ждут сборки. Тут должны быть какие то хитрости, нюансы, как всегда. Вот например C:\vcpkg у него 61гб набралось. Плюс проект 8гб. Ну это же ненормально.

А в mingw собрать у себя из-под линукса не вариант?

Я много раз экспериментировал с этим. Кросс-дев ставил из оверлеев. Пока удачно не закончилось ни разу. Рабочий вариант самый простой - сборка на гитхабе. Но в случае с плюсами это вообще не вариант.

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

Очень давно не пользовался Qt под виндами, но раньше (>10 лет назад) было проще поставить готовые бинарные сборки.

А Qt заблокирован для нас с «той» стороны. Я подумал, что сборка проще, чем изучать нюансы обхода и объяснять потом юзеру…

Кросс-дев ставил из оверлеев

В контейнере с каким-нибудь дебианом попробуй, если с хостом что-то странное.

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

Или плюнуть и для винды держать таури, для линукса электрон. Сборки обоих одной командой. Просто ввел команду, забрал бинарник через пару минут. Все.

Из минусов - поддержка двух кодов на разных языках… Я пока сдаюсь. Остановлюсь на двух проектах, все.

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

Во всех проектах на раст у меня - приложение запустил, через неделю глянул, а оно жрет даже меньше, чем на запуске. Знаешь какой каеф наблюдать такое?

Если такой расклад пока устраивает, ладно.

У Go, к слову, самая беспроблемная кросс-компиляция под любую платформу. Хотя не знаю как оно, если подключать внешние зависимости по типу тех же webview.

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

А таури с cef не пробовал или там всё сложно?

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

Ещё можно потыкать flutter с cef плагином, но это если времени не жалко, конечно. А так, конечно проще на электроне уже остановиться.

До меня вдруг дошло, что я всю эту миграцию задумал из за одного юзера со слабым компом, у которого долго грузился клиент. Я опросил его - после долгой загрузки работает все идеально и быстро. По сути можно просто дальше пилить электрон и не страдать дурью…

Ну, бороться за каждого пользователя – тоже хорошо.

Сборка под винду походу закончится лютым провалом. Гитхаб собирет проект уже 46m 20s. Прости меня раст, за твои жалкие 8 минут сборки.

А это всё потому, что модули.

Нет, он просто при помощи vcpkg собирает все зависимости из исходников. Да-да, и Qt тоже.

А есть вариант для гитхаба без сборки? Установкой.

А Qt заблокирован для нас с «той» стороны.

Репа не заблокирована. Бинарные сборки – да.

Лично я для хобби-проектов собираю Qt статикой. Для Qt5 под виндой написал себе такую шпаргалку. То же, но под линуксом обсуждалось на ЛОРе (но да, надо бы тоже шпаргалкой оформить). До сборки Qt6 мои потные ручонки ещё не дотянулись, под винду было не нужно, под линукс пока устраивает сборка из репозитория.