Какой язык выбрать для разработки GUI-фреймворка для планшетного Linux?

QML или Flutter.

Lua + IUP

Qt, ждём нормальных решений на rust, я бы в сторону влива туда и смотрел, если тебе интересно.

Kotlin с Java, какие тут могут быть варианты?

C++. На C будет много синтаксического мусора, прямо как в GTK+. При желании можно будет байндинги для чего-то другого добавить потом.

Стандартный C — C99 или позднее. На C++ будет много шаблонно–метапрограммерского мусора, как в Qt. При желании можно будет байндинги для чего-то другого добавить потом.

Видимо, так и придется. Лучше варианта не вижу. Хотел было поучить раст, скачать пдфку The Rust book, оказалось, что они её в виде пдф не дают - только купить можно или распечатать веб-страницу в пдф. Так и не удалось поучить раст.

Можно попробовать Kivy - если влезет, может понравиться.

Забыл ещё написать про kivy, почему я его забросил. Оказалось, что на моём компьютере свёрнутое приложение на kivy потребляет около 3% cpu, если развернуть - 5-7%. А само приложение крайне примитивное. Такая ситуация возникает у многих, использующих kivy. У самих разрабов свернутое приложение kivy ест около 2% cpu, и они не считают это проблемой.

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

Flutter что уже доступен для десктоп приложений? Есть демо приложение на посмотреть? Ну там калькулятор например.

В 2016 PDF-версии TRPL были. Я читал и рекомендую к пропуску. Возможно, что с тех пор состояние улучшилось, но тогда её писала школота (с высерами в адрес C и C++) и редактуры, похоже, что вообще не было (всё вразнобой, непоследовательно и с кучей повторений).

Скорее свой написать хочу.

Swift 🤔

Для десктопа - нет. Но может у ТС android.

Скорее свой написать хочу.
удобную библиотеку для встраиваемого Linux

КМК мало входных данных, необходимо дальше изучать задачу и грамотно всё таки составить ТЗ.
На данном этапе ещё рано выбирать язык и решать писать свой тулкит или использовать готовый, из-за этого и твои затруднения с выбором.

Скорее свой написать хочу.

…

для macos в альфе, для windows и linux в разработке, автор как раз может помочь в доработке flutter’а под десктоп, вместо пиления своего велосипеда.

гораздо интереснее, как себя ведет kivy на расбере, в остальном выглядит идеальным средством для накидывания прототипов всякой встраиваемой херни

Если уж мутить фреймворк, то нужно учесть ошибки старых

Язык должен быть быстрый, удобный, желательно компилируемый. В этом отношении перспективен dlang

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

Ну нормальных GUI либ реально нет. Поэтому гугл и пилит Flutter.

Ну а ТС просто уныло вбрасывает.

Ну, как бы, это что-то для «наколенных» поделок, кмк.

GTK+

потому что все плохо, но в остальных-то еще хуже

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

Помню я так году в 2010 сэкономил аж мегабайт с полдюжины RAM, запуская сразу пяток pygtk-приложух в одном интерпретаторе. Уже в тамошнем embedded с 64-128 MB было непонятно, че я пластаюсь, а уж в 2020 просто даже не вякай.

QML

А чем плох тот же раст, к примеру? Или dart? У меня есть причины их не любить, но хотелось бы услышать ещё точки зрения.

Проблема с существующими фреймворками скорее в том, что репутация их держателей мне не нравится. Qt- постоянно порываются что-то закрыть, GTK+ - всё переписать и вести разработку в закрытом стиле. Для меня бы идеальным вариантом был бы kivy, но он интерпретируемый и жрёт как не в себя.

А чем плох тот же раст, к примеру? Или dart? У меня есть причины их не любить, но хотелось бы услышать ещё точки зрения.

Я уже давно перебираю разные языки на предмет именно удобства. Rust имеет запутанный синтаксис, нет классов, он явно не для быстрой разработки, для Gui это важно

Мне же нужен полноценный язык похожий на Python в плане удобства и широту функционала. С++ слишком низкоуровневый, Pascal устарел

Поэтому к критериям пока подходит Dlang, Nim

Мне нравится сочетание (c++)Qt+Qml или (python)kivy+kv. Когда есть язык разметки интерфейса и язык интерфейсной библиотеки.

Я думаю, что я остановлюсь на c++ для написания функциональности как надстройки над sdl и языке типа kv или qml для описания интерфейсов. С++ из-за того, что нужны программисты, которые будут писать на всём этом добре, sdl - потому что можно будет тестировать в разных платформах, язык интерфейса типа kv или qml, потому что удобно и компактно.

Традиционализм не всегда полезен. :-) С++ хоть и распространен, но тащит за собой много не нужного

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

Что касается нахождения программистов, то грамотному все равно на чем писать

мне кажется java и старенький awt. очень даже подойдут

PyQt.

/thread

Скорее свой написать хочу.

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

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

Red [/thread]

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

qt - всё порываются закрыть исходники (единственный их существенный минус),

kivy - приложения тянут с собой интерпретатор, потребляют свернутыми 3% cpu.

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

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

qt - всё порываются закрыть исходники

Уже открытые исходники никто не закроет. После гипотетического закрытия можно сделать форк и часть разработчиков на него перейдут. Будет ситуация как с mysql/mariadb.

Проблема в том, что qt - это гигант. Это и собственные реализации алгоритмов и структур, и несколько целевых платформ, и свой moc-компилятор, и свой интерпретатор qml, и свои виджеты. Некоторые разработчики из KDE говорят, что в случае закрытия исходников они не потянут развитие Qt. Поддерживать смогут, а развивать - вряд ли.

А в кого контрибьютить?

Киви.

У меня лично довольно важный фактор в выборе — это поддержка сообществом. Т.е. пусть будет (относительно) недоделано, неудобно, выглядит по-васянски, зато это не продукт корпорации. Тут и отметаются gtk и qt (а также гном и системд :) ).

Для вас этот фактор означает что хватит сил разобраться.

потребляют свернутыми 3% cpu

Ну и пёс с этими 3%…

Кому из пользователей не пёс, могут запустить из терминала, и останавливать по ctrl-z (я регулярно браузер (firefox) так запускаю: вкладки нужны, а они часто чего-то там втихоря делают)

Да даже и пофиксить эти 3% — будет наверняка гораздо проще чем писать всё с нуля.

тянут с собой интерпретатор

Ну t184256 написал выше, что ерунда это в 2020.

Зато скриптовое (высокоуровневое) удобство. (хотя я не спец по питону; там вроде свои заморочки есть под капотом)

Я вот абсолютно согласен со всем, кроме одного - 3% cpu. В развернутом виде у меня потребляет 5-7% cpu. А я хочу написать несколько приложений для своей наколенной тачскрин системы на арме. Так это у меня киви получается будет только 30-50% кушать впустую.

Следующий недостаток - питон. Если хочешь, чтобы работало быстро, надо писать на cython, вставлять компилируемые куски кода.

И последнее - я же как раз к кивистам и заходил, спрашивал их, мол, как же так, что 3% жрет свернутым. Мне ответили - хочешь исправляй сам, мы это недостатком не считаем. А если они это даже недостатком не считают, то примут ли они мой пулреквест?

Javascript

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

Всё там с лицензией, как и было раньше: GPL+commercial на всё и LGPL на основные модули.

Они просто хотят состричь побольше бабла с тех, кто на Qt пишет закрытое ПО. Само по себе это вполне законное желание, только они не тем путём пошли. Им бы не гайки закручивать и офлайновые инсталляторы убирать, а просто разнообразить ценовую политику, ввести дешёвые версии для инди-разработчиков и др. Вон, у Visual Paradigm цена лицензии такая, что я как-то, не заморачиваясь, подписался на квартал, потом сделал работу и так же, не заморачиваясь, отписался. Понадобится — подпишусь ещё. Все довольны. Было бы такое у Qt — они бы нагребли больше, чем потеряли. И убрать нелепое требование о запрете смешивания лицензий. Эти их «игры в Oracle» могут добром не кончиться.

Но для тех, кто на Qt пишет СПО, вроде бы практически ничего не поменялось. Меня вот куда больше огорчило выбрасывание из Qt6 работы с неюникодными кодировками. Поскольку в реальном мире программы, работающие с ним, никуда не девались. И если я буду свой проект переводить на Qt6, мне для поддержки как минимум одного из актуальных форматов придётся в свою программу тащить libiconv.

Документация в последние годы тоже стала заметно хуже.

Не замечал. В чём это выражается?

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

Я выше в комментариях погорячился, что хочу на SDL реализовать первый прототип. Я лучше для начала поковыряюсь в иксах, вэйлэнде, может попробую в X.Org Endless Vacation of Code поучаствовать. А дальше посмотрим, как пойдет.

Поскольку в реальном мире программы, работающие с ним, никуда не девались.

На свалку истории. Как можно писать под Qt6 и при этом юзать не-юникод? Зачем?

На свалку истории. Как можно писать под Qt6 и при этом юзать не-юникод? Зачем?

Например, если в приложении требуется открыть какие-нибудь файлы с Windows в Win-1251. Как я понимаю, если раньше это можно было решить средствами самого Qt, то сейчас придётся тянуть дополнительную либу и через неё делать. И кросс-платформенность у такой либы будет уровня libiconv, а не Qt.

Под кросс-платформенностью ты сейчас подразумеваешь возможность запуска на том странном дистрибутиве Linux, который Windows 10? Че там, iconv не найдется?

Че там, iconv не найдется?

Когда мне нужно было нечто подобное делать, то не нашлось. Пришлось пердолиться с MinGW/MSYS2 и т. д. А на macOS нужно будет пердолиться с каким-нибудь brew. Всё это минус к удобству использования Qt.

Rust Book на русском

А в том и суть, что исправить ошибки старого сложнее, да и не даст никто - у них своя дорожная карта, все дела. Я бы предолжил в свою очередь либо Qt, либо FLTK, либо что мне больше всего в последнее время импонирует написать свою LPC SDL+lua GUI библиотеку, вдохновлён lite

А вы чего хотели от ускоренного с ГПУ kiwi, да и 3% это немного, для холостого конвеера, я бы попробовал сначала, что-то осязаемое написать, чтобы уже затем делать вывод, чем kivy не устраивает и в случае чего переходить на другую связку язык/библиотека, пока вы не сделали проекта или не выстроили подробную дорожную карту развития, в том числе с зложенными вами требованиями к проекту оценка того подходит вам библиотека/язык - 99%-ое словоблудие

Повторюсь, попробуйте, пока такая оценка в 30-50 очень голословная, т.к. во-первых холостой загруз может быть связан с холостым прогоном конвеера на графическом ускорителе, во-вторых такой рост загрузки процессора может быть только на весьма загруженных графических или трудоёмких вычислительных задачах, а также с кривой оптимизацией, поэтому лучше не искать идеального, а взять то, что вам уже сейчас ближе, писать свой можно только разработав грамотный проект и дорожную карту, т.к. иначе быстро всё сведётся либо к багованному Сишному коду, либо к перегруженному ООП коду с десятком нахер не нужных наследований и использования парадигм - главное правило любого дела «главное не средства, а цель, которая требует своих(в смысле под задачу) средств», т.е. определитесь с целью и уже под неё расспрашивайте библиотеку/язык/бубен.

Как можно писать под Qt6 и при этом юзать не-юникод?

Да легко. Если осознать, что программа пишется не ради циферки в версии Qt, а для того, чтобы делать что-то полезное. Вот есть программа, которая пишет свои данные в cp1251, например. А я пишу другую программу, которая должна (помимо прочего) уметь читать файлы от первой программы. Это, может, не главная функция, но существенно облегчающая переход со старой программы.

Я могу, конечно, косплеить напыщенного индюка и потенциальным пользователям объяснять, что их программа и их данные — это «легаси», которому в современном мире не место. И я примерно представляю, что на это скажут люди, большая часть которых и слов-то таких не знает, но которые не хотят потерять свои данные. И я идиотом выглядеть не хочу.

Есть музыкальные файлы с неюникодными тегами. Авторы вменяемых плееров дают возможность выбрать кодировку, хотя могли бы кричать «на свалку истории». Есть ZIP-архивы, приготовленные в винде. Да дохрена чего есть, о чём не ведает дивный народ.