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

Ты как будто гтк первый раз увидел

Я венду первый раз увидел :) Кроме того, Gtk в исполнении Eclipse выглядит попристойнее.

ей уже пару лет
сравнение с wxWidgets

Ну, imho, не о чем говорить. Ну а главное различие - C vs C++

wxWidget на сишке

Небось с теми же концепциями построения интерфейса из 90х аля mfc?

Алсо вангую как и все heavyweight тулкиты-обертки упрется в недостаток виджетов.

чего для Go нет ничего нормального?

А биндинги для на Python когда ждать?

Библиотека написана на языке программирования C.

ну, внутри она совсем не на С

Вы так рьяно пытаетесь обличить несущественные недостатки изложения, что я могу подумать, что вы всеми силами выступаете против опубликования этой новости или (не дай же боже!) являетесь тулкитофобом.

Не вижу особой разницы, кто сегодня представил эту прекрасную библиотеку миру на IT-шных ресурсах, но раз она представлена в репозитории Pietro Gagliardi, то я решил упомянуть имя разработчика, ведь именно благодаря его стараниям libui и появилась на свет, хоть и два года назад.

Между тем сегодняшний хайп на IT-шных и околоайтишных ресурсов дал интересный результат:

1,191 stars today | https://github.com/trending

Ты забыл про кроссплатформенность и скорость разработки.

Нет, не забыл. Кроссплатформенный гуй на «родных технологиях» обломает тебя сразу, как только ты решишь превратить свое кнопко-приложение в что-то более сложное. Наглядный пример - wxWidgets, где видна и убогость общего подмножества виджетов, и суррогатов для их имитации, и проблемы с тем, что UI и те же виджеты ведут себя по-разному на разных платформах. И если libui будет развиваться, она придет ровно к тому же. Что касается скорости разработки - я уже писал, разница будет только для чего-то реально сложного, где libui и так не справится.

И Qt, и эта библиотека позволят тебе быстро накидать простой UI и заняться другим делом. В противном случае ты будешь ручками ковыряться во всех этих WinAPI/Cocoa API/GTK+3 и читать доки.

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

эту прекрасную библиотеку

И в каком месте она прекрасная?

А пример хелловорльда есть?

Юниксовые выглядят самыми убогими :/

Adwaita L&F вообще-то наиболее приятный и гармоничный из всех трёх. И текст в полях там единственный правильно выровнен по вертикали по какой-то причине.

Adwaita L&F вообще-то наиболее приятный и гармоничный из всех трёх. И текст в полях там единственный правильно выровнен по вертикали по какой-то причине.

И сами поля такие... просторные. И табы тоже.

несущественные недостатки изложения

Эм.. текст новости противоречит действительности. Кто-то решил вдруг её пропиарить, но никак не её автор.

что вы всеми силами выступаете против опубликования этой новости

Я указываю на принципиальные недостатки в надежде, что они будут исправлены, и новость будет отражать факты. Пиарить, так пиарить: больше людей будут знать, авось помогут. Это неплохо, а даже хорошо.

являетесь тулкитофобом

Я знаю об этой библиотеке ещё со времени, когда была только ui для go (т.к. ищу легковесный GUI для go, что по-прежнему проблематично). Поэтому мне и бросилась в глаза дезинформация.

интересный результат:

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

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

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

А то, что под libui будет не менее жирный GTK+ тебя не смущает, не?

GTK+ стандартный тулки по LSB. И выпилить gtk+ из линя не менее проблематично, чем питон или перл. В то время, как Qt вполне себе сторонняя либа.

кроссплатформенный гуй на «родных технологиях» обломает тебя сразу

На «неродных технологиях» тоже обломает. Стоит только вспомнить стоны тех же пользователей OS X, что Qt и GTK+ приложения выглядят у них не совсем стандартно, так как мимикрируют не совсем точно, да в тот же HiDPI долго не умели. Ну и постоянное недовольство на LOR'е , что Qt-приложения отличаются от GTK+-приложений по внешнему виду, тоже стоит учитывать.

превратить свое кнопко-приложение в что-то более сложное

Это вряд ли, большинство кнопко-приложений, которые я писал для себя и для друзей, так и остались кнопками. Если мне потребуется превратить кнопко-приложение в что-то сложное, я скорее всего возьму более мощный тулкит, чем libui, да перепишу всё с нуля, аккуратно отделяя логику от представления.

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

Ты предлагаешь тратить время на изучение ненужного. Что если человек ничего не знает, кроме GTK+? Ты предлагаешь ему убить денёк, а то и два для изучения того, как создавать GUI-приложения на OS X и MS Windows? Вместо того, чтобы написать разок и откомпилить один и тот же код? Ты ведь помнишь, что в том же OS X нужно ещё иметь базовые знания ObjC, чтобы кнопки шлёпать.

Для приложения-кнопочки это жёсткий overhead. Я понимаю если проект большой и сложный, как, к примеру, VLC. В нём под OS X написан интерфейс, который юзает Cocoa API, а в случае с GNU/Linux — используется Qt.

GTK+ стандартный тулки по LSB.

rpm тоже стандарт по LSB, но на объективную реальность это никак не влияет.

И выпилить gtk+ из линя не менее проблематично, чем питон или перл. В то время, как Qt вполне себе сторонняя либа.

Qt был в наших линях, когда этих ваших GTK+ и в задумке не было. И если говорить без фанатизма, - что первое, что второе выпилить нет проблемы, но только смысла в этом нет, лучше просто пользоваться.

На «неродных технологиях» тоже обломает

Да, но масштабы трагедии и кол-во вырванных волос будут очень сильно отличаться.

Стоит только вспомнить стоны тех же пользователей OS X, что Qt и GTK+ приложения выглядят у них не совсем стандартно, так как мимикрируют не совсем точно, да в тот же HiDPI долго не умели.

GTK+ приложения мимикрируют под OS X? Смешная шутка.

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

Т.е. поддерживаемый много лет стандарт - ненужное, а поделка, которую возможно завтра выкинут, - нужное? Довольно странные приоритеты.

Ты предлагаешь ему убить денёк, а то и два для изучения того, как создавать GUI-приложения на OS X и MS Windows?

На самом деле значительно меньше. И это только для первого раза придется делать.

Ты ведь помнишь, что в том же OS X нужно ещё иметь базовые знания ObjC, чтобы кнопки шлёпать.

Во-первых это тоже тривиально. Во-вторых есть Swift.

Для приложения-кнопочки это жёсткий overhead.

Создание UI руками на С - вот это действительно «жёсткий overhead». А все остальное мелочи.

Какой пример ты хочешь, анончик?

Вот тебе кнопочка в окошке:

#include <stdio.h>
#include <string.h>

#include <ui.h>

static uiWindow *mainwin;

static int onClosing()
{
    uiControlDestroy(uiControl(mainwin));
    uiQuit();
    return 0;
}

int main(void)
{
    uiInitOptions o;
    const char *err;

    memset(&o, 0, sizeof (uiInitOptions));
    err = uiInit(&o);
    if (err != NULL) {
        fprintf(stderr, "error initializing ui: %s\n", err);
        uiFreeInitError(err);
        return 1;
    }

    uiBox *box;
    uiButton *button;

    mainwin = uiNewWindow("Hello World", 200, 50, 1);
    uiWindowSetMargined(mainwin, 1);
    uiWindowOnClosing(mainwin, (void *)(onClosing), NULL);

    box = uiNewVerticalBox();
    uiWindowSetChild(mainwin, uiControl(box));

    button = uiNewButton("Quit");
    uiButtonOnClicked(button, (void *)(onClosing), NULL);
    uiBoxAppend(box, uiControl(button), 0);

    uiControlShow(uiControl(mainwin));
    uiMain();
    uiUninit();
    return 0;
}

«cpp-multithread»: [Screen #1]

EXL, что за тема gtk/qt?

Breeze, это дефолт в KDE Plasma 5.

Использование С и C++ для ui - это такой лютый бред))

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

как и qt

И на лине бы закопать весь этот трэш. Только html5, остальное не нужно. А сишникам вообще к ui прикосаться нельзя, пилите БД.

Есть же IUP уже.

Если этого достаточно: gtk.css, тема.

Благодарю. Не подскажешь еще, можно ли запустить с этим css ровно одно приложение - для сравнения?

Не подскажешь еще, можно ли запустить с этим css ровно одно приложение - для сравнения?

Знаю только говноспособ :)

• Запускаешь приложение
• mv gtk.css gtk.css.orig
• Запускаешь ещё раз

GTK_THEME=Adwaita:dark gedit

?

Еще есть переменные типа GTK2_RC_FILES и GTK_DATA_PREFIX.

В чем отличие от WxWidgets?

В чем, то ты прав. Взять например Блендер. Яб во всех своих проектах юзал его УИ. Но ведь он для большинства платформ инопланетный (Как и Айтюнс в винде кстати).... Так, что может хрен с ним с нативным луком?

И выпилить gtk+ из линя не менее проблематично, чем питон или перл.

Гуй для пакетного менеджера отвалится?

?

Что, спрашиваю, помешает выпилить gtk+ из линя, если его можно даже не устанавливать?

В консольном лине - без проблем. А так - на gtk куча софта, в том числе все(оба) браузеры.

libui использует для отрисовки элементов управления родные технологии поддерживаемых платформ

wxWidgets?

Но на C

Он изобретает лазарус на сях.

TableView-то где? TextView? FileDialog? С этого начинать надо, а не откладывать на 2.0, кнопочки любой дурак может кросс-платформенно раскидать.

О, интересненько! Надо будет напотыкать!

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

Linux/Unix: GTK+ версии 3.4 или выше.
Mac OS X: OS X версии 10.7 или выше.
MS Windows: Windows версии Vista SP2 или выше.

Замечательно.

Я правильно понимаю, что это по сути костыль вокруг GTK+, призванный сделать его удобным и переносимым?

Блестяще.

Мда, что только люди не придумают, чтобы Qt не использовать.

Круто тогда.

Я правильно понял, что в винде оно использует напрямую родной Win32 API, а в линуксе - GTK, да ещё и определённых версий, который, в свою очередь, использует X11, ну или Wayland какой-нибудь?

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

Вряд ли ЭТО+GTK будет менее монструозным, чем Qt (с учётом того, что Qt - это не только ui). Поэтому необходимости переползать с Qt на это не вижу, ну если только чья-то личная неприязнь к плюсам. Дело хозяйское.

использует для отрисовки элементов управления родные технологии поддерживаемых платформ
GTK+ версии 3.4 или выше.
GTK+ версии 3.4 или выше.

спасибо, но НЕНУЖНО.

Воистину!

Сколько же бугурта в треде у кедерастов, гткдващеров и прочих ретроградов.

На той же Windows GTK+-проги выглядят люто ненативно.

это не баг а фича! :-)

можно делать нормальные Linux-программы, которые нормально выглядят на Linux...

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

:-D

это противовес всяким дибильным Windows-програмам [которые написаны приемущественно на Qt..], которые на Windows выглядят хорошо, а при запуске на Linux выглядят совсем не нативно. [ведь это-самое-популярное-ныне Qt как раз и нужен для написания хороших Windows-программ (хорошо выглядящих, как минимум) и их кривых портированных версий под Linux]

*** выводы (ввиде FAQ) ***

вопрос: но ведь libui как раз позволяет сделать так чтобы программа хорошо выгляд ОДНОВРЕМЕННО и на Linux и ТОЖЕ на Windows (в отличии от GTK+, который только на Linux хорошо выглядет.. и в отличии от Qt который только на Windows хорошо выглядет) — значит правильнее писать на libui а не на GTK+ ?

ответ: нет. правильнее писать на GTK+ , так как GTK+ имеет намного шире возможностей (под Linux) и меньше багов (под Linux). чем libui

вопрос: но как же тогда пользователи Windows ? они будут страдать? используя не нативный интерфейс (GTK+) в программе

ответ: да, они будут страдать :-) .. но ведь ни кто и не заставлял их использовать Windows.. они сами выбирают этот путь страдания (и им ни когда не позно перейти на Linux, как только они этого захотят)