LINUX.ORG.RU
ФорумMobile

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

 , , ,


0

2

Интересно ваше мнение, какой язык можно выбрать для написания нового GUI-фреймворка для Linux? Я бы хотел написать для себя (и для других) удобную библиотеку для встраиваемого Linux с сенсорным вводом (планшеты с тач-скрином).

Сам я пробовал GTK+, Qt и Kivy. GTK+ не нравится своим языком разметки интерфейса на основе xml, странным видом байндингов сигналов, глючной инфраструктурой разработки и тем, что разрабы часто глухи к желаниям пользователей. Qt мне нравится многим, но в последнее время они как-то нестабильно ведут себя относительно открытости лицензии. Документация в последние годы тоже стала заметно хуже. Зато их язык разметки интерфейса, qml, довольно неплох. Kivy - GUI-фреймворк на python. Он во многих местах довольно сырой, приложения с ним довольно долго загружаются, но на нём можно легко и быстро написать приложение, и его язык разметки интерфейса, kv, тоже очень приятен.

Хотелось бы узнать ваше мнение, на каком языке лучше создать новый фреймворк?

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

C++ - прекрасный язык, если его правильно использовать. Единственная трудность с C++ - не так много людей, кто может его правильно использовать. Кажется, что язык потихоньку теряет свою популярность.

Rust - слишком мало программистов на Rust, язык пугает своим внешним видом. В последние годы язык динамично развивается, но это развитие больше похоже на хаотичные конвульсии.

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

C# - не очень популярен в Linux окружении, возможно, будет тяжеловат во встраиваемом окружении.

JVM-based - кажется, что могут быть тяжеловаты во встраиваемом окружении.

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

xaizek ★★★★★ ()

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

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

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

embden ()
Ответ на: комментарий от Shadow

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

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

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

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

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

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

MaxPower ★★ ()

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

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

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

ism ★★★ ()

GTK+

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Киви.

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

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

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

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

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

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

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

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

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

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

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

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

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

embden ()

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

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

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

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

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

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

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

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

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

embden ()
Ответ на: комментарий от hobbit

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

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

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

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

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

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

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

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

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

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

AKonia ()
Ответ на: комментарий от embden

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

AKonia ()
Ответ на: комментарий от embden

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

AKonia ()
Ответ на: комментарий от t184256

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

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

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

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

hobbit ★★★★★ ()