Представлена библиотека графического интерфейса libui

Ой, выглядит еще глупее, чем даже http://goodbye-microsoft.com

FileDialog?

static void openClicked(uiMenuItem *item, uiWindow *w, void *data)
{
	char *filename;

	filename = uiOpenFile(mainwin);
	if (filename == NULL) {
		uiMsgBoxError(mainwin, "No file selected", "Don't be alarmed!");
		return;
	}
	uiMsgBox(mainwin, "File selected", filename);
	uiFreeText(filename);
}

static void saveClicked(uiMenuItem *item, uiWindow *w, void *data)
{
	char *filename;

	filename = uiSaveFile(mainwin);
	if (filename == NULL) {
		uiMsgBoxError(mainwin, "No file selected", "Don't be alarmed!");
		return;
	}
	uiMsgBox(mainwin, "File selected (don't worry, it's still there)", filename);
	uiFreeText(filename);
}

TableView/TextView пока не завезли, ага.

Я правильно понял, что в винде оно использует напрямую родной Win32 API, а в линуксе - GTK

Да, правильно.

определённых версий

GTK+3

Если да, то получается. что линукс для этой библиотеки - не лучшим образом выглядящая платформа. Хотя в лазаревом LCL поход примерно такой же...

А какой подход в GNU/Linux можно реализовать? Если в Windows и OS X есть ЕДИНЫЙ и СТАНДАРТНЫЙ API для GUI-приложений, то что использовать в GNU/Linux? К Qt особо не привяжешься, в половине дистрибутивов он просто отсутствует из коробки и доступен лишь в репозиториях. GTK+3 тоже весьма странный выбор, так как ситуация у него похожая с Qt. Вот GTK+2 более-менее доступен во всех дистрибутивах, но устарел, не может в HiDPI. Ещё доступны всякие иксовые кнопочки и виджетики, но кто адекватный будет пилить интерфейс на них в 2000-ых годах?

Вот и получается что в GNU/Linux говно какое-то с GUI. Не зря сам Линус говорит так. Возможно, было бы проще, если графика была бы модулем в ядре. Ну или выжил лишь один тулкит, не важно: Qt или GTK+.

что линукс для этой библиотеки - не лучшим образом выглядящая платформа.

Есть мнение, что Linux вообще не лучшая платформа для графических приложений. В той же Haiku OS и даже Amiga OS, как в MS Windows и OS X, существует ЕДИНЫЙ API для графических приложений. Лишь GNU/Linux, да всякие древние Unix'ы не могут определиться с графикой, а следовательно никогда не будут пользоваться популярностью на десктопах.

Поэтому необходимости переползать с Qt на это не вижу, ну если только чья-то личная неприязнь к плюсам. Дело хозяйское.

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

Скриншоты не интересные. Наверное, самая запарная штука, которая часто выглядит паршиво при кроссплатформе - это file picker, которого тут не видно...

Хотелось бы сравнение с wxWidgets, который делает тоже самое.

Если все приложения на wxWidgets выглядят как BOINC в Ubuntu, то стоит его закопать и никогда больше не вспоминать: частичная отрисовка таблицы при рефреше [WTF?!], окно постоянно норовит выскочить на передний план как черт из табакерки и еще некоторые странности, которых с каждой новой версией Ubuntu становится все больше...

Жду биндинг к rust.

А вот это да: немного неожиданно, что у rust все довольно плохо с GUI (и когда я спрашивал в IRC, то мне это подтвердили): или использовать устаревшие биндинги к Gtk, или поднимать сервер и отдавать все в виде HTML... >_<

Ой, выглядит еще глупее, чем даже http://goodbye-microsoft.com

сайт что ты показал — призывает покончить с Майкрософт через Debian (и ещё что-то-там-какую-то утилиту)...

это довольно-таки глупо, потому что это навязывание.

а в моём сообщении — я говорю про другое — суть:

можете использовать хоть Windows хоть Linux хоть что угодно — до посинения.. но GUI будет выглядеть (должен выглядеть) наилучшим образом именно в Linux (а не быть одинаковым по качеству и в Windows и в Linux).

любая попытка сделать GUI-равновесие именно «честным» (между различными операционными системами: Windows и Linux) — ухудшает Linux-GUI-вариант относительно Linux-ONLY-GUI-варианта...

более в общем смысле:

чем более кросплатформенной является программа — тем хуже её поведение в Linux. (ну это у Linux-программистов, понятное дело)

более радикальный случай — это делать программы совсем СОВЕРШЕННО не-кросплатформенными (совершенно не способными компилироваться под Windows.. а только Linux) .....

....но этот радикальный вариант — на мой взгляд — слишком уж радикальный.. то есть, думаю, всё-таки некоторая маленькая красплатформенность быть может и не повредит. в этом случае кросплатформенность разумеется может быть только ассиметричной :-)

в случае Qt — эта ассиметричность направленая в сторону Windows.

в случае GTK+ — эта ассиметричность направленая в сторону Linux.

в случае — tk, wxwidgets, libui — мы просто получаем инвалидов и для Windows и для Linux :-)

Если в Windows и OS X есть ЕДИНЫЙ и СТАНДАРТНЫЙ API для GUI-приложений, то что использовать в GNU/Linux?

X11. Он как раз СТАНДАРТНЫЙ.

Ещё доступны всякие иксовые кнопочки и виджетики, но кто адекватный будет пилить интерфейс на них в 2000-ых годах?

Умеющий да запилит. Можно свои поверх X11. В конце концов те же Qt и GTK так и делают.

Приложение на голом win32 API, кстати, тоже смотрится не очень. А уж его исходники...

в случае Qt — эта ассиметричность направленая в сторону Windows.

Вот этот тезис надо бы подтвердить. Я на Qt пишу как раз в линуксе, под виндой потом собираю, если проект требует. Никакой «направленности в сторону Windows» не ощущаю, наоборот, в линуксах я использую Qt из репозитариев, а в винде надо DLLи с собой тащить.

это противовес всяким дибильным Windows-програмам [которые написаны приемущественно на Qt..],

Не-а. Дебильные Windows-программы пишутся либо на MFC, либо вообще на .Net. На Qt пишется то, авторы чего как минимум задумываются о будущем.

которые на Windows выглядят хорошо, а при запуске на Linux выглядят совсем не нативно.

Ну вот мой текущий Qt-хобби-проект как раз наоборот - на линуксах выглядит хорошо, а на Windows 8 - как «привет от Windows 95». Ибо в восьмёрке по умолчанию плоскота, а в моей программе кнопки (опять-таки по умолчанию) старого вида. Я не говорю, что это неизлечимо. Просто стилем пока не занимался, руки ещё не дошли. Скорее всего, мне надо просто тему какую-то подцепить явно. Но в любом случае это не показатель «направленности в сторону Windows» или наоборот, а всего лишь свидетельство того, что в хорошей кроссплатформенной программе под каждую целевую платформу надо проводить минимально оправданную адаптацию.

P.S. про инвалидность wxwidgets тоже хотелось бы обоснование увидеть.

Приложение на голом win32 API, кстати, тоже смотрится не очень.

Aero отключил ?

X11. Он как раз СТАНДАРТНЫЙ.

Это не стандарт для GUI-приложений, это стандарт для отображения графических примитивов, причём криво спроектированный стандарт, где даже двойную буферизацию надо делать руками и отсутствует понятие валидного/невалидного буфера - так что отсутствует команда синхронизации буфера с экраном (XFlush & XSync не дают гарантии, что изображение будет тотчас выведено на экран), а XClearArea & XClearWindow может привести к фликерингу (х.з. как перевести, «мерацине» - не то).

Никакой «направленности в сторону Windows» не ощущаю

судя по Qt-программам запущенным в Linux — вижу в них следущее:

* кнопки странно-мелкого размера по толщине (высоте), не такого размера как это принято в Linux.. скорее такого как это принято в Windows..

* не видил ни одной Qt-программы с client-side-decoration.. то есть Qt-програмы НЕ выглядят так элегантно как: gedit , evince , eog ... (нельзя написать хороший GUI? значит огромный жирный минус)

* ctrl+shift+u — это сочетание клавишь в Qt-программах не работает (на linux.org.ru уже много раз упомянал про это) .. ну это просто плевок в сторону Linux.. а на Windows то подозреваю наверно вендовые сочетания в Qt-программах (для ввода юникод-символов) работает?

* ну и после всего описанного объективизма — так и быть добавлю чуток субъективизма :-) ..: в мире Linux принято писать библиотеки на C а не на C++ .. (C++ это уже больше к Windows)

P.S. про инвалидность wxwidgets тоже хотелось бы обоснование увидеть.

может и хороший фреймворк, но почемуто wxwidgets-программы какие-то ппц глючные в плане GUI.. быть может совпадение? pgadmin-например — баг на баге, вплодь до того что после переключения языка (ctrl+space) нельзя писать на русском языке, до момента кратковременного нажатия ctrl

кнопки странно-мелкого размера по толщине

Размеры кнопок берутся из темы. Если автор проги сам задал их размеры, то это проблемы прогера, а не Qt.

не видил ни одной Qt-программы с client-side-decoration.. то есть Qt-програмы НЕ выглядят так элегантно как:

Шта? В KDE выглядят как родные, в то время как все GTK проги выглядят как гавно. Это не проблемы Qt, а проблемы разных движков тем у разных DE.

ctrl+shift+u — это сочетание клавишь в Qt-программах

Что оно должно делать? И при чём тут Qt? Хоткеи в проге не из воздуха берутся. Тем более что в Qt есть набор стандартных хоткеев, которые будут равны системным.

в мире Linux принято писать библиотеки на C а не на C++ .. (C++ это уже больше к Windows)

Увозите наркомана.

Из всего, что вы написали, я делаю вывод, что вы не понимается ни капли на в ОС, ни в программировании.

в случае GTK+ — эта ассиметричность направленая в сторону Linux.

GTK вообще чисто для линя делается. О какой симметричности идёт речь?

Ну вот мой текущий Qt-хобби-проект как раз наоборот - на линуксах выглядит хорошо, а на Windows 8 - как «привет от Windows 95».

Qt4? Хотя и там должно быть все нормально с темами.

X11. Он как раз СТАНДАРТНЫЙ.

После появления wayland - уже нет. И это не GUI тулкит.

Есть мнение, что Linux вообще не лучшая платформа для графических приложений. В той же Haiku OS ... существует ЕДИНЫЙ API для графических приложений.

При этом множество, если не большинство новых haiku-приложений - это порты с линукса с использованием Qt :)

Оно там выглядит нативно?

На мой взгляд ровно как Qt в линуксах. Но я тулкитопофиг. Пускай о нативности лучше beos рассказывает.

Меня скорее акцент на единый beapi насмешил.

Походу эта библиотека для Go

Qt не умеет в нативные контролы.

Кто cpp-multithread?

Кстати, во всяких вяленых свою графику не завезли?

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

Нет, там всё средствами используемого тулкита рисуется.

Кто cpp-multithread?

say what?

gtk, увы, мертв везде, кроме линя

ну так gtk+2 закопали, а третий выглядит как гуано.

а qt.. так себе, зато одинаково.

QGraphicsView, не? Вроде бы я там именно в пикселях получаю QPainter::viewport и в них же всё задаю.

Хотя вопрос хороший.

Где можно не устанавливать гтк? Кроме арча и генты (и их производных).

вантусные самые убогие.

Цитату откуда взял или в честь чего ты её написал. К нам в Linux-ы завезли потокобезопасную либу для рисования GUI?

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

Запускаю в Linux GTK3-программы — вижу в них следующее:

• Кнопки неадекватно гигантского размера, не такого, как это принято у нормальных людей — скорее такого, как это принято на всяческих планшетах и прочем пальцеориентированном ненужно.
• Видел кучу неюзабельного говна с client-side decorations, таким же гигантским, как и всё остальное: gedit, evince, eog... (нельзя написать хороший GUI? значит, огромный жирный минус).
• Для ввода юникодных символов прикручен какой-то свой костыль вместо того, чтобы придерживаться XIM.
• К тому же, изначально ориентирован на C, на котором в 2016 году писать интерфейсы — удовольствие сильно ниже среднего. Спасибо, хоть есть какой-никакой биндинг для плюсов и Glade (которому, впрочем, далеко до Qt Designer по удобству использования).

Нормально все в Haiku OS http://savepic.ru/9866460.png