LINUX.ORG.RU
Форум — Development  

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

 , , , ,


4

4

Всем привет, ребят. Недавно окончательно переехал с винды на линукс на основной рабочей лошадке. Разработкой никогда не занимался ранее, но скриптовал немного на perl, python и lua. У меня есть задумка небольшой программы с ГУИ, но т.к. в вопросе не имею экспертизы, прошу совета о тех, кто имеет.

Мои хотелки:

  1. Не слишком сложный (низкоуровневый) язык.
  2. Возможность компиляции в один файл. Для меня и для тех, кто будет использовать (устанавливать) это важно. Одна из причин, почему не хочу использовать тот же python.
  3. Простая кроссплатформенность разработки (линукс и винда).
  4. Наверное максимальная независимость от сторонних библиотек, чтобы не попасть в неприятную ситуацию.
  5. Удобная разработка на линуксе. На винде буду только пересобирать, если это потребуется, и тестировать.

Программа сама по себе, наверное, несложная… В основном это заполнение форм различными данными (текст, цифры), вычисление формул, хранение данных в какой-нибудь sqlite или на худой конец в csv файле, построение и отображение графиков и таблиц с удобным редактированием и занесением данных.

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

Дайте, пожалуйста, ваши рекомендации по языку и, возможно, фреймворку.

Читаю сам информацию в интернете. Насколько я могу судить по прочитанному, мне возможно подойдет С++ с фреймворком Qt. На форуме тоже видел одну или две темы, где такую связку советовали.

Да, к слову, с вебом и веб технологиями связываться вообще не хочу.

Система Linux Mint 21.3.

 ← 1 2 3 →
Ответ на: комментарий от saidu

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

Юное хамло

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

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

anonymous
()

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

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

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

olelookoe ★★★
()
  • 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 — тоже есть. Нативные зависимости с сексом, но можно прикрутить. Вариант хоть и экзотический, но тоже кроссплатформенный и быстрый по скорости разработки.

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

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

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

Задолго до А. Эйнштейна обсуждал в своих работах[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, Умов писал:

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

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

Из этих рассуждений видно, что Умов получил законы движения энергии в самом широком и универсальном смысле.
anonymous
()
Ответ на: комментарий от anonymous 
В 1910 году в немецком журнале «Physikalische Zeitschrift» появилась первая работа Н. А. Умова, посвященная теории относительности, созданной А. Эйнштейном в 1905 году. Эта работа носила следующее заглавие в русском переводе: «Единообразный вывод преобразований, совместных с принципом относительности». Спустя два года появилась новая его работа по тому же вопросу. Эта работа напечатана была по-немецки и по-русски под заглавием «Условия инвариантности волнового уравнения».

По свидетельству знаменитого русского ученого Н. Е. Жуковского, эти работы Н. А. Умова являются лучшим математическим толкованием принципа относительности. «Подобно тому, как неэвклидовская геометрия и геометрия многих измерений опираются на инвариантность обобщенного представления об элементе дуги, принцип относительности, по Умову, имеет свое математическое содержание в инвариантности волнового уравнения распространения света» (Н. Е. Жуковский).

Для решения поставленной задачи Умов преобразует волновое уравнение для пространства четырех измерений, вводя вместо координаты времени мнимое переменное ζ = cti, где с — скорость света; затем требует, чтобы это уравнение оставалось инвариантным при переходе от координат х, у, z, τ к координатам х', у', z', τ'. Оказывается, этого можно достичь только тогда, когда вторые дифференциальные параметры функций х', у', z' и τ', выраженных через переменные х, у, τ и будут равны нулю.

В случае, когда х, у, τ суть параметры Декартовой системы координат, а z = z' = 0, то инвариантность волнового уравнения требует, чтобы х', у', τ' были параметрами изотермической системы криволинейных триортогоналыных координат.

В частном случае можно считать х', у', τ' параметрами Декартовой системы координат, повернутой около оси у-ов на мнимый угол φi. Положив далее tgφ=v/c Н. А. Умов приходит в конечном счете к формулам преобразования Лорентц — Эйнштейна.
anonymous
()

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

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

monk ★★★★★
()

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

man-from-36
()

Мои хотелки:

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

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

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

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

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

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

futurama ★★★★★
()
Последнее исправление: futurama (всего исправлений: 1)

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

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

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

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

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

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

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

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

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

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

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";
}
monk ★★★★★
()
Ответ на: комментарий от InterVi

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

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

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

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

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

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

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

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

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

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

А нехер 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 имеют совершенно разное содержимое.

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

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

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

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

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

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

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

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

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

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

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

closed this as completed in 0371075 on Jun 4, 2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

monk ★★★★★
()
Ответ на: комментарий от monk 
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.
Вообщем не соскучишься.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 5)
Ответ на: комментарий от fluorite

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

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

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

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

anonymous
()
 ← 1 2 3 →
Development