Ответ весьма очевиден: C++/Qt либо Vala/GTK+.

QML тоже хороший вариант, как тут подсказывали.

Ну и дела. А я же искал. У них на сайте фиг что найдешь.

UPD: никидайте FOSS проектов с использованием QML (не из KDE). А то все хвалят, а софта на нём почти нет.

Оригинальные у тебя представления о простоте.

QtCreator

Ubuntu Unity 8

QtCreator

Там очень мало QML.

Ubuntu Unity 8

Вроде как еще релиза не было.

https://github.com/Swordfish90/cool-retro-term

Ну, тогда можно еще глянуть JavaFX+Nashorn: тоже не быстро, но «на острие прогресса» :)

Про FOSS не знаю, а так 2GIS ня мобилки.

Нуклеар очень интересен, кода там очень мало, но... Если почитать issues, то впечатление чего-то сырого. Официальных бекендов, как я понимаю, не завезли, а те, что в комплекте с примерами, явно недописаны (на момент, когда я смотрел). Абстракции накладывают свои ограничения, к примеру, кнопку можно создать только внутри нарисованного окна, которое нарисовано на реальном окне (если я ничего не перепутал и правильно понял).

А кнопки button1/2 рисовать мышкой надо? Мне лениво...

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

python + gtk

А может еще ОС присоветуешь и процессорную архитектуру?

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

Зачем

на самом деле все просто - на тот момент у qt не было lgpl + решение разрабатывалось с оклядкой на встраивание (я все это даже запускал без иксов в directfb). Но в итоге на встраивание забили, софт поставляется только для винды. Сейчас естественно яб взял qt, либо вообще запилил бы на андроиде.

Почему gtk не взяли? Он умел же через framebuffer работать тоже, даже исталятор какого-то дистра так запускался.

сложно сказать. его даже не рассматривали, на сколько помню. но даже сегодня на мой взгляд gtk был бы последним в списке для такого софта.

GNU/Linux, MIPS

Нет, не мышкой:

import QtQuick 2.7
import QtQuick.Controls 1.5
import QtQuick.Layouts 1.3

Item {
    width: 640
    height: 480

    property alias button1: button1
    property alias button2: button2

    RowLayout {
        anchors.centerIn: parent

        Button {
            id: button1
            text: qsTr("Press Me 1")
        }

        Button {
            id: button2
            text: qsTr("Press Me 2")
        }
    }
}

Но можно и мышкой.

Сейчас естественно яб взял qt, либо вообще запилил бы на андроиде.

Да, QML для подобных киоск-интерфейсов просто шик. За денёк бы управился.

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

А вообще есть какой-нибудь хендбук с рассмотрением фич? Так чтобы можно сходу было заменить MFC и прочий треш.

http://qmlbook.github.io/en/ch04/index.html и офф-доки.

Ну в общем для виджетов не плохо, но наверное лучше по-старинке, с вебкитом.

С Вебкитом? Может быть уважаемый анононимус имел ввиду с Qt Widgets?

Ну если qtwebkit это оно, то да.

Эту знаю. Но в итоге даже десятка прог не наберётся. Технология как-то не ахти.

Язабан.

Но пока неплохо, гораздо проще Qt

Ты сравниваешь с QtWidgets или c QML? Последний, вообще-то, даёт весьма близкое к тому, что ты написал на t*.

Оценивать технологию по числу свободных программ — это мощно.

Эту знаю. Но в итоге даже десятка прог не наберётся. Технология как-то не ахти.

Просто технология в основном для профессионалов (HMI в первую очередь а не GUI) так что тебе по понятным причинам неизвестная.

На Quick кода будет не больше, чем в примере на Groovy.

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

C++/Qt либо Vala/GTK+

А как же C/GTK+?

Почему важно писать грамотно

никидайте FOSS проектов с использованием QML

Распарсил первое слово фонетически как «не кидайте» и долго думал, почему не надо кидать, если

все хвалят, а софта на нём почти нет.

Потом сообразил, что ты, скорее всего, имел в виду «нАкидайте».

Несвободных намного больше?

Ох лол. Сейчас приступ хватит от своей же непрофессиональности.

Несвободных намного больше?

Намного. Я за последние три месяца работал/работаю с 6 проектами на QML большая часть из которых сейчас в разработке.

Ну а кроме лично вас кто-то, что-то пилит?

На том же унылом electron уже запили кучу всякого мусора, а ему от силы год. А QML уже лет 5.

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

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

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

QML только сейчас получил вменяемые контролы, потому ничего удивительного в долгом и медленном старте нет.

QML только сейчас получил вменяемые контролы, потому ничего удивительного в долгом и медленном старте нет.

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

Очевидно, на reactdom (возможно, с electron)/reactnative.

Msegui, зависит только от иксов

Что конкретно тупит?

Сам QML. Даже в блоге Qt были заметки на эту тему. Они там всё фиксят и фиксят, а толку 0.

Вот, в описании Qt Quick Controls 2 упоминают тормоза: https://doc.qt.io/qt-5/qtquickcontrols2-differences.html

Ресайз QML окна - боль. Всё тупит. Ибо OpenGl.

Софтварного рендеринга всё еще нет, из-за чего проги в виртуалках работают с артефактами.

Потребление памяти в разы больше чем у виджетов.

Нагрузка на проц выше, если QML использовать не только для виджетов, но еще и логику туда вынести. JS тормозит как факт.

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

PSS: сама идея QML мне нравится, но исполнение, увы, - нет.

Вот, в описании Qt Quick Controls 2 упоминают тормоза

Упоминают, что их пофиксили как раз в Qt Quick Controls 2, но там речь про контролы, а не про QML.

Софтварного рендеринга всё еще нет, из-за чего проги в виртуалках работают с артефактами.

Будет в 5.8, на венде вроде как есть, потому что в виртуалке все ок.

Потребление памяти в разы больше чем у виджетов.

Не такое уж критичное потребление, это не повод отказываться

Ресайз QML окна - боль. Всё тупит. Ибо OpenGl.

С ресайзом есть проблемы, это да, но он нужен далеко не везде.

И это не считая того, что они каждый год там всё переписывают.

Я на прошлой неделе писал на QtQuick 1.0, это где-то Qt 4.7, разницы вообще не заметил, так что обратная совместимость просто отличная — переписывают только под капотом.

Упоминают, что их пофиксили как раз в Qt Quick Controls 2

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

Не такое уж критичное потребление

hello world под 50МиБ это норм?

но он нужен далеко не везде

На десктопе нужен.

Для мобилок qml наверное годится, но не для десктопа.

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

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

hello world под 50МиБ это норм?

У меня прямо сейчас стандартный пример с галереей Controls 2 кушает 23 Мб. Это норм.

У меня прога на 30к строк, на виджетах, жрёт 8МиБ.

А QML еще нехило кеширует всё, что спокойно приводит к 50+МиБ

На объемах памяти современных устройств начиная от 1Gb — это совершенно не важно.

Это ваше мнение.

Вопрос не в доступной памяти, а в эффективно занятой. Мне не улыбается забивать память всяким мусором когда есть альтернативы.

Простой пример: Atom vs Sublime. Последний потребляем на порядки меньше ОЗУ. Занимает на порядки меньше места на диске. Ощутимо быстрее работает.

Вот вы мне предлагаете использовать Atom.

А если о наболевшем - то плазмоиды в KDE5, которые все поголовно на qml, очень даже не хило жрут ОЗУ. krunner вот прямо сейчас жрёт 50МиБ, при условии, что это простое поле ввода.