Разработка программы с графическим интерфейсом (советы)

На жабе пиши, ну. Жабу, конечно, поставить всем придётся, зато мультиплатформа и без мужеложства

моно мертв

Тем не менее, в репозиториях пока присутствует.

Юное хамло, вас учили как надо писать незнакомому человеку? Дискутировать я с вами не буду. Из форума ухожу. Бесполезная болтовня.

прочую хрень…«спецы» на смех подымут…Ответа на форуме мне никто не дал

Юное хамло

Из форума ухожу

Скатертью дорога, можете даже писать мне письма. Меня зовут Себастьян Перрейра, торговец черным деревом.

Лорчую этого оратора. Только я использую pyQT.

здравствуйте, это перепись фекалий мамонта отсталых технологий?

21 век на дворе, алё
flutter идет на смену крестьянской лошадке!

пункты 1,2,3,4 искаропки
пункт 5 хоть идея, хоть андроид-студия, хоть вскод туалет, душ, маленькая кухня, микроволновка, wi-fi, телевизор, тихо, зелено, окна во двор, hot reload (если вы понимаете о чем я) и прочие батарейки в комплекте!

Этож просто библиотека компонентов. Она в зависимости от платформы превращается в веб-компоненты либо в xml-дрисню (а та еще во что-то) на ведре…

удивительный ты человек

счастья тебе и здоровья

Опять эти сектанты флаттера… У нас на работе есть один такой. Скучно

• Java + java-fx. Язык в меру сложный, работать будет везде (ну кроме андроида разве что). Собирать гуй удобно в javafx-scenebuilder.
• Go + fyne.io, там хотя бы удобная компиляция. Сам go легко и быстро учится.
• Dart + flutter — рабочая классика для кроссплатформы. Удобно, быстро, но sdk жрёт адски много ОЗУ, так что на слабой машине становится трудно.

Всё, на этом нормальные (удобные) варианты закончились.

Просто для справки напишу:

Питон, кстати, тоже компилится: kivy и beeware транслируют его в кресты, а потом пакуют в бинарник. Но нужно понимать, что такая магия не надёжна, плохо контролируема и имеет свойство ломаться в неожиданных местах.

Qt / wxWidgets/ tk / etc — это всё танцы на граблях и жопная боль, когда нужна кроссплатформа.

А ещё есть react native, но это особый вид мазохизма.

Раз писал на lua, посмотри в сторону defold и godot — это игровые движки, но там есть приличный ui. Сеть, всякое там io — тоже есть. Нативные зависимости с сексом, но можно прикрутить. Вариант хоть и экзотический, но тоже кроссплатформенный и быстрый по скорости разработки.

Qt / wxWidgets/ tk / etc — это всё, что я не осилил.

Исправил для тебя.

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

Можно в сторону вектора Умова подумать, Н.А.

Задолго до А. Эйнштейна обсуждал в своих работах[6] формулу E=kmc^2, выведенную ранее Генрихом Шраммом[7], которая, по его предположению, связывала плотность массы и энергии гипотетического светоносного эфира. Впоследствии эта зависимость была строго выведена, без какого-либо коэффициента k и для всех видов материи, Эйнштейном в специальной теории относительности (СТО). Одним из первых русских учёных оценил значение СТО.

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

 Умов Н. А. Теория простых сред и её приложение к выводу основных законов электростатических и электродинамических взаимодействий. — Одесса, т. 9, 1873.
 Умов Н. А. Теория взаимодействий на расстояниях конечных и её приложение к выводу электростатических и электродинамических законов (недоступная ссылка). — М.: Имп. Моск. Ун-т, 1873. — 44 с.
Umov N. A. Ein Theorem über die Wechselwirkung in Endlichen Entfernungen. (Теорема относительно взаимодействий на расстояниях конечных). Zeitschrift für Mathematik und Physik. Bd. 19, 1874, H. 2. § 12.
Умов Н. А. Уравнения движения энергии в телах (недоступная ссылка). — Одесса: Типогр. Ульриха и Шульце, 1874. — 56 с.
Умов Н. А. Вопросы познания в области физических наук (недоступная ссылка). Речь произнесена в общем собрании 9 съезда русских естествоиспытателей и врачей 4-го января 1894 г. — М.: 1984.

Уравнения движения энергии в телах (Умов)

Оглавление
I. Общее выражение закона сохранения энергии в элементе объёма среды
§ 1. Определения и задача исследования.
§ 2. Уравнение сохранения энергии в элементе тела. 
§ 3. Связь законов движения энергии с законами частичных движений сред.

II. Уравнения движения энергии в различных телах
III. Переход от законов движения энергии к частным движениям, обусловливающим явления

Кажется, как раз про это.

В той теме про различные знаки k думали.

Вот тоже интересное направление – задать ограничения. Не только по модулю, скорее по объёму.

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

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

В своей работе "Albeitung der Bewegungsgleichungen der Energie in continuirlichen Körpern", 1874, Умов писал:

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

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

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

Racket + IDE для него DrRacket. https://www.reddit.com/r/Racket/comments/lue9bl/try_creating_an_app_in_drracket_the_easy_way/

Все 5 пунктов в наличии. По п.3 +MacOS.

Насколько я могу судить по прочитанному, мне возможно подойдет С++

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

+1 за Lazarus. Минимальный порог вхождения, простой язык, куча готовых стандартных компонентов как раз для твоих целей, без проблем соберешь под linux/windows/macos. Для кроссплатформенной сборки рекомендую установить его с помощью fpcupdeluxe. Потом в проекте просто вариант сборки для второй платформы заводишь и все готово.

Мои хотелки:

1 Не слишком сложный (низкоуровневый) язык.

2 Возможность компиляции в один файл. Для меня и для тех, кто будет использовать (устанавливать) это важно. Одна из причин, почему не хочу использовать тот же python.

3 Простая кроссплатформенность разработки (линукс и винда).

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

5 Удобная разработка на линуксе. На винде буду только пересобирать, если это потребуется, и тестировать.

tcl/tk по всем пунктам со своего опыта (я их все сам использовал)

Qt - это всё танцы на граблях и жопная боль, когда нужна кроссплатформа.

Можно подробнее?

Я прочитал ветку и учитывая что ты на Mint, надо писать XApps, он сейчас в тренде, вот тема:

Linux Mint отказывается от libAdwaita и призывает остальных присоединиться к ним

Qt/Qml все это может. Но все таки упомяну что:

• На чистом Qml можно не все, поэтому иногда придется лезть в плюсы и потом разбираться в коммуникации между Qml <—> C++.

• Нужно иногда разбираться в тонкостях CMake, т.к. все таки он собирает проект.

Простой проект и qmake прекрасно собирает без необходимости разбираться в кишках.

Там специфичные баги, которые проявляются в зависимости от DE. Уже не вспомню какие, давно писал, на PyQt5. А ещё его нужно будет накатить как зависимость либо поставлять вместе с софтом — это в линуксе везде по дефолту, а на mac и win — нет.

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

А самый-самый кроссплатформенный ui — это вообще веб. Не обязательно электрон: можно просто поднимать веб-сервер и открывать локально любым браузером. Или простой html + какой-нибудь встраиваемый движок вроде dillo. Но тут уж зависит от задачи.

Назвать Си++ не слишком сложным крайне тяжело

Не наворачивай сложностей на каждый чих, и будет тебе несложно.

Не наворачивай сложностей на каждый чих, и будет тебе несложно.

Увидишь, почему эта программа падает?

std::map<std::string, int> counters = { {"hello", 5}, {"world", 5} };
std::vector<std::string_view> keys; // получаем список ключей, используем string_view, чтобы не делать лишних копий
keys.reserve(counters.size());
std::transform(std::begin(counters),
               std::end(counters),
               std::back_inserter(keys),
               [](const std::pair<std::string, int>& item) -> std::string_view {
                   return item.first;
               });

// как-то обрабатываем список ключей:
for (std::string_view k : keys) {
    std::cout << k << "\n";
}

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

В случае Racket зависимость тащить не надо. Для винды делается .exe со всем нужным для GUI кодом внутри.

зачем все эти сложности если можно сразу:

for (auto const& [key, val] : counters) 
    std::cout << key << ':' << val  << std::endl;

Может быть C++ и https://tgui.eu. Недавно добавили поддержку raylib.

Хочет программист список ключей сохранить для отдельной обработки. Нельзя?

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

Нельзя?

странное желание, нет, нельзя

но если очень хочется, то можно )

Вот в этом и есть проблема Си++. Что за программиста решает, что ему нельзя.

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

f(g(k(x)), z(y(p)));

Причём не однобуквенные имена, а длинные. Выносишь

auto p1 = g(k(x));
auto p2 = z(y(p));
f(p1, p2);

и код внезапно ломается.

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

А нехер auto использовать где не попадя.

Если явно указать тип, тоже не спасает. :-(

А в for наоборот. Так работает

auto a = f.v();
for (auto x : a) { ... }

Смотришь, что a нигде больше не используется, объединяешь:

for (auto x : f.v()) { ... }

Внезапно UB.

И при чтении кода постоянно ловушки

using namespace std::string_literals;
std::string s1 { "Modern C++",  3 };
std::string s2 { "Modern C++"s, 3 };

s1 и s2 имеют совершенно разное содержимое.

чувак, иди проспись

Лучше почитай https://github.com/Nekrolm/ubbook/

Писать на Си++ можно только если требования к производительности таковы, что всё остальное уже неважно.

UB - это следствие наличия описания B (стандарта). У многих языков стандарта нет. В этих языках нет «неопределённого поведения», потому что никакое поведение не определено.

Поведение определено описанием языка.

Например, если я в Racket напишу

(define (f x)
  (define y 1)
  (g 1)
  (displayln y))

то у меня есть гарантия, что или будет выведено 1 или не будет выведено ничего. В Си++, если в g есть UB, то может оказаться, что будет выведено любое другое значение. Более того, UB в любой функции, вызванной до f тоже может испортить вывод.

Поэтому в Racket в случае ошибки мне необходимо искать только в окрестности проявления ошибки. В Си++ любая ошибка может проявиться где угодно.

https://github.com/racket/racket/issues/2677

This program causes an «invalid memory reference» error on racketcs, but works correctly on racket.

лучше уясни, что реальные компьютеры не являются детерминированными системами, и перестань уже пороть наивную чепуху уровня «если в туристическом буклете меня не предупредили о грабителях, то проблемы грабежей нет»

Оно еще живо вообще? Да и простой проект и cmake собирает и менять там ничего не нужно.

closed this as completed in 0371075 on Jun 4, 2019

Найдена ошибка компилятора, исправлена много лет назад.

А в Си++ компилятор, производящий такой код, не считается ошибочным, потому что описание языка позволяет на определённые языковые конструкции творить дичь.

Ну вот свежая ошибка - ракета просто крашится на старте. Какой код предпочитаешь больше - идеальный и неработающий или неидеальный и работающий?

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

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

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

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

Фактически, есть два города:

• в одном в буклете написано, что грабителей нет, а если есть, то обращайтесь, мы их поймаем;

• в другом в буклете написано, что грабители не грабят если не нарушать правила из приложения J.2 на пяти страницах, а если что-то нарушили, то грабители в своём праве, ловить их не будут.

Потому что собрали кривыми руками (точнее, кривыми руками удалили в собранном ELF нужную секцию).

У меня даже на Эльбрусе успешно собралась и работает.

Там специфичные баги, которые проявляются в зависимости от DE. Уже не вспомню какие, давно писал, на PyQt5

Уж не знаю, что там с pyqt, а вот в связке c++/qt/qml все норм.

А ещё его нужно будет накатить как зависимость либо поставлять вместе с софтом — это в линуксе везде по дефолту, а на mac и win — нет.

Если это про копирование библиотек qt в состав пакета - да. Но это не проблема.

лучше выбрать ту, которая самая кроссплатформенная и легче поставляется

Фраза «самая кроссплатформенная» просто прекрасна.

А самый-самый кроссплатформенный ui — это вообще веб

Старые песни о главном.

Какой код предпочитаешь больше - идеальный и неработающий или неидеальный и работающий?

У меня сообщалка на Racket уже восемь лет работает стабильно и надёжно (ни одной порчи данных, сервер Linux, клиенты Linux и Windows).

А написанный на Си++ Adobe Acrobat Reader на оффтопике регулярно выдаёт «Код исключения: 0xc000041d» и падает.

Exception 0xC000041D means that an unhandled exception was 
encountered during a user callback. It means that 0xC000041D is a 
second chance exception. So we should capture the first chance 
exception, if we want to know the root cause. Usually it’s 
occurred in system defined callback context on Windows, for 
example message handling context. And customized callback will not 
throw the exception.

COM+ в Windows очень привередлив.
В COM всё работает, а в COM+ работает лишь супер отлаженный код.
Кстати неплохое средство для нахождения ненадёжного кода.

1С 8.3 COM+ использует.

В 1С 7.7 всё отлично работает, а в COM+ пришлось искать «плохой код».
При этом COM+ не позволяет вести отладку 32 разрядных приложений, а для 1С 7.7 нужно как раз 32-разрядное API.
Вообщем не соскучишься.

Или простой html + какой-нибудь встраиваемый движок вроде dillo.

Для такого лучше всего sciter. Хотя он и как замена электрону и подобным вполне подходит.

UB - это следствие наличия описания B (стандарта).

Ada застандартизирована так что Си и C++ тихонько курят в сторонке, но UB в ней не допускается.

У многих языков стандарта нет. В этих языках нет «неопределённого поведения», потому что никакое поведение не определено.

У rust и zig никакого стандарта нет, но UB (очень небольшой список и только в unsafe для rust, и чуть больше для zig) вполне есть.

проприетарщина ведь