В рамках проекта libui (https://github.com/andlabs/libui) развивается многоплатформенная графическая библиотека, предназначенная для создания интерфейса пользователя на языке Си (также имеется (https://github.com/andlabs/ui) обвязка для языка Go). Особенностью libui является обеспечение родного внешнего вида интерфейса, благодаря использованию родных для каждой системы виджетов и библиотек (в Linux/BSD* - GTK+, в OS X - Cocoa, в Windows - Win32). Библиотека использует векторную модель отрисовки, которая напоминает Direct2D, Cairo и Core Graphics. При выводе используются только относительная компоновка элементов, что позволяет использовать приложения на экранах с различным разрешением. Элементы интерфейса размещаются в соответствии с определяющей внешний вид раскладкой блоков на холсте, как в GTK+ и Qt. Код распространяется под лицензией MIT.
<center><a href="https://raw.githubusercontent.com/andlabs/libui/master/examp... src="https://www.opennet.dev/opennews/pics_base/0_1463734914.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
<center><a href="https://raw.githubusercontent.com/andlabs/libui/master/examp... src="https://www.opennet.dev/opennews/pics_base/0_1463734931.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
<center><a href="https://raw.githubusercontent.com/andlabs/libui/master/examp... src="https://www.opennet.dev/opennews/pics_base/0_1463734954.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>URL: https://news.ycombinator.com/item?id=11735393
Новость: http://www.opennet.dev/opennews/art.shtml?num=44468
мне кажется или на макоси сглаживание шрифта убогое?
http://www.joelonsoftware.com/items/2007/06/12.htmltl;dr: кажется
>http://www.joelonsoftware.com/items/2007/06/12.html
>tl;dr: кажетсяОба примера по сцылке - оффтоп, и, вообще, ШГ.
так и есть.
но после перехода яблока сплошь на hdpi-мониторы, всё это перестало быть актуальным.зыж
лучшее сглаживание кстати показывал собственноручно настроенный линух с fontconfig.
По крайней мере на моем стареньком MacBookPro5,5.
На моем новом MacBookPro11,3, как я уже сказал, на hidpi-мониторе сглаживание что есть, что его нет. На всех 3-х ОС.
Но, справедливости ради, слегка замыленные шрифты (на старом ноуте) в OS X намного меньше напрягали глаза, чем на вантузе. Работать удавалось дольше, продуктивнее и комфортнее, так что… не удивлюсь если это сделано специально. Видимо и выбор системных шрифтов тоже говорит в эту пользу.
Это всегда на макоси.
Мне кажется, что на всёх трёх картинках шрифты вырвиглазные, но не могу понять причины
верхний всё же заметно лучше остальных двух
Это гельветика же.
Да. Я думаю в линуксе лучше всего выглядит. В виндовском скриншоте неплохо, но размер шрифта маленький. Если бы все три скрина с одинаковым размером шрифта были, то линуксовый думаю лучший.
> мне кажется или на макоси сглаживание шрифта убогое?Видимо, от настроек монитора зависит. На всех, где видел я, макось-шрифты выглядят лучше других.
Зачем это, когда есть GTK3?
Зачем GTK3 когда теперь есть это?
Зачем GTK3 и это когда завтра кто-нибудь придумает ещё что-нибудь?
Зачем GTK3, "это" и что-то там придумывать завтра, когда уже сегодня есть Qt?
Зачем всё это, когда есть чернила и папирус
Зачем косить? Вон накошенный лежит.
Оно поверх гытыка и работает, к сожалению.
На этом весь исходник занимает килобайт. На си. И к тому же нормально выглядит не только в *никсах, что приятно. Интересная библа.
wxwidgets на С?
> wxwidgets на С?Wxwidgets-superlight. Диэтическая версия.
> wxwidgets на С?на C++.
Неужели у GTK3 так все плохо в макоси и винде? Где КЭП, по какой причине это было придумано?
И в винде и в макоси нормально, это просто еще один велосипед.
Надеюсь, эта маленькая библиотека убьёт распухшие культи.
Ага, и Boost заодно. Каким боком в вашем сознании минималистичная библиотека для написания графических интерфейсов относится к фреймворку для написания кроссплатформенных программ?
если обвязки C++ не будет, то на винде не взлетит.
ну и как обычно - [всем известный фанфик про ещё один универсальный стандарт на xkcd].jpg
Ну еще бы, у виндузоидов студия до сих пор C99 не умеет, поэтому они плюсы используют даже там где от них больше вреда чем пользы.
Уже умеет.
> на винде не взлетит.Да, ты должен страдать.
>> на винде не взлетит.
> Да, ты должен страдать.я не страдаю, а пишу сразу на дотнете и с колакольни плевал на совместимость с чем-либо ещё кроме венды. <- как тебе такой расклад, школьничег?
> с колакольни плевал на совместимость с чем-либо ещё кроме вендыЭто значит, вы не пишете ПО масштаба предприятия. Для чего (для небольших программ, типа Word или Photoshop или там игрушек разных) .Net наверно и подходит.
>> с колакольни плевал на совместимость с чем-либо ещё кроме венды
> Это значит, вы не пишете ПО масштаба предприятия. Для чего (для небольших
> программ, типа Word или Photoshop или там игрушек разных) .Net наверно
> и подходит.мдамс? давайте вы нам назовёте такое сякое "ПО масштаба предприятия" и на чём вы его пишете.. ну так, чтобы не голословно..
> мдамс? давайте вы нам назовёте такое сякое "ПО масштаба предприятия" и на
> чём вы его пишете.. ну так, чтобы не голословно..ПО масштаба предприятия - например, система управления (диспетчеризации) движения поездов метрополитена. Части системы работают (в реальном времени!) на различном оборудовании и ОС (платформы ARM, x86_64, Linux, Windows). 100% кода написано на Java.
Или учет движения материальных потоков (сырье, продукция) металлургического завода. Также и данные на многие месяцы и годы и одновременно работа в реальном времени. 100% Java.
Эти (и другие) примеры ПО у которого есть серверная часть и десятки (и даже сотни) клиентов работающих в реальном масштабе времени. 100% кода на Java.
Мы пытались работать на C# (исключительно по неразумному запросу заказчика). Шаг влево или вправо от платформы Wintel с точно уазанными версиями и требованиями, и всё. В смысле - ничего. Ничего не сделаешь. Поэтому я и сказал, что на C# (платформа .Net) можно писать только малые программы.
На самом деле, кроме кросплатформенности есть гораздо более важная вещь - Java не только язык и базовые библиотеки (как C# или C++), еще огромная, готовая платформа из многих технологий, составляющие J2EE. Ничего похожего нет в .Net.
> ARM, x86_64, Linux, Windows...сказки, легенды, тосты.
В энтерпрайзе как раз меньше всего кроссплатформенность нужна, потому что всем всё можно купить одинаковое, в пределах одной задачи. А ты описал какую-то софтину "на Java", которая должна и на PLC электродвигателем управлять, и на сервере БД билеты учитывать, и на компе диспетчера косынку раскладывать. Нет, ИРЛ так не делается.
>> ARM, x86_64, Linux, Windows
> ...сказки, легенды, тосты.
> В энтерпрайзе как раз меньше всего кроссплатформенность нужна, потому что всем всё
> можно купить одинаковое, в пределах одной задачи. А ты описал какую-то
> софтину "на Java", которая должна и на PLC электродвигателем управлять, и
> на сервере БД билеты учитывать, и на компе диспетчера косынку раскладывать.
> Нет, ИРЛ так не делается.Круто, когда люди, похоже ничего не понмающие в чужом деле, комментируют работу других.
1. Вы меня поразили прямо в пятку, насчет ненужности кроссплатформенности в ПО масштаба предприятия. Я как-то слабо представляю систему клиент-сервер (где клиенты ПК на Windows, мобильные клиенты на Android/iOS/Win, сервер c каком-нибудь *NIX ОС), без требований к кроссплатформеннсоти. Может Вы имеете в виду, что КАЖДАЯ часть системы дложна работать на ОДНОЙ платформе?
2. я разве говорил про PLC? Их нет в проекте метро. И еще, я вообще не знаю о существовании сколь-ниубдь известных линеек PLC (ПЛК) которые позволяют запускать Java-программы.
3. Вы правильно сказали - "одинаковое в пределах одной задачи". Проект АСДУ ДП (движения поездов) состоит из нескольких "задач". Для каждой задачи подбирается своя аппаратная платформа. Обычно, каждая платформа подразумевает свои средства разработки. Как раз одинаковость платформы Java для разных задач и позволяет использовать один язык, один набор библиотек и одно средство разработки для различных частей единой системы.
4. Непонимание Вами также проявилось вот в чем: я написал "система управления (диспетчеризации) движения поездов метрополитена". Соответственно, Вы не правы в следующем: диспетчеризация (хоть и является "автоматизированой системой диспетчерского управления" - АСДУ) не подразумевает непосредственное упралвение оборудованием (например, двигателями), это задача АСУТП. Второе: продажа билетов никакого отношения не имеет к АСДУ ДП. Третье: "на компе диспетчера раскладывать косынку", это одно из основных тем, с чем воюют на всем постсоветском пространтсве - зачастую это основная причина, ставить на АРМы диспетчеров ОС с ограничением доступа к другим программа или вообще, Linux системы.
5. И самое последнее, но видимо наиболее важное, насчет того, что так не бывает в реальности. Обясните это городу-миллионнику, диспетчеризация всего метро которого сделана имеено так, как я и описал.
Вместо того, чтобы огульно утвержать "так не бывает!", правильнее будет спросить "а как это сделано?". Если Вас заинтересут ответ на последний вопрос, могу дать ссылки на более подробную информацию.
Состояние дел в метрострое сейчас простое для интерфейса используют C# и платформу с этми самыми окнами, контроллеры по старинке пишут на C, а какая-то математическая херня переделана с ActiveX на Java. Не пойму о чем Вы там спорите и зачем Вам крос платформенность? Вы ввобще в бизнесе понимаете что цель баблонских заработать и на ваши эти самые кросплатформенности кладут болт обычно
> Состояние дел в метрострое сейчас простое для интерфейса используют C# и платформу
> с этми самыми окнами,Метрострой - это что? Это метрополитен? Строительная организация? В каком городе?
> контроллеры по старинке пишут на C, а
Скорее всего Вы говорите про встраиваемые системы на базе свободно программируемых компьютерных платоформ (типа Octagon). А в обиходе контроллерами чаще называют ПЛК, которые не программруются на С (практически никогда), а на одном из языков стандарта IEC 61131.
> какая-то математическая херня переделана с ActiveX на Java. Не пойму о
> чем Вы там спорите и зачем Вам крос платформенность? Вы ввобще
> в бизнесе понимаете что цель баблонских заработать и на ваши эти
> самые кросплатформенности кладут болт обычноА тут Вы такой бред говорите, что только свет туши. "Баблонские" зарабатываются либо распилом бюджета (но мы же не про это?), либо выполнением требований заказчика. Заказчик не часто требует кросс-платформенность в явную, но совокупность других требований (на какой из имеющихся платформах должна разворачиваться в основном серверный софт) однозначно вытекает кросплатформменость разработки.
> мдамс? давайте вы нам назовёте такое сякое "ПО масштаба предприятия" и на
> чём вы его пишете.. ну так, чтобы не голословно..Да, и в добавок насчет C# и Java. Оченть непрятно удивило ограниченность средств разарботки в Visual Studio по сравнению с Eclipse. Много средств работы с кодом в Eclipse оказалось, что не имеет аналогов в VS. Обратное утверждение - неверно. По нашему мнению, у Microsoft все-таки не хватает ресурсов (по сравнению с сообществом Eclipse) сделать средства разработки сравнимого качества.
И еще поясню, что мы зарабатываем деньги программированием, а не занимаемся "холиварами". Если VS/.Net будет сраним с Eclipse/Java - будем пользоваться ими. Кстати, Microsoft движется в правильном направлении - поддержка C# в Linux, на других, кроме Windows платформах. Надеюсь, в ближайшее время C# сможет составить конкуренцию Java в ПО масштаба предприятия.
Все-таки конкуренция - это хорошо.
Главное, чтобы в процессе нарастания этой конкуренции из мозгов заказчиков успел выветриться стереотип "с Виндой же проще". Потому что вне офиса это, мягко говоря, не так.
Как только не извращаются, только чтобы не использовать Qt.
На размер библиотеки посмотри.
никто не заставляет таскать всё с собой.
> $ equery size dev-qt/qtcore:5
> * dev-qt/qtcore-5.6.0
> Total files : 1427
> Total size : 21.42 MiB
> $ equery size dev-qt/qtgui:5
> * dev-qt/qtgui-5.6.0-r1
> Total files : 755
> Total size : 18.95 MiBи это со всеми хидерами, дэбагинфо,… в общем всё что нужно для разработки и отладки. сами же библы:
> $ du -h /usr/lib64/libQt5Core.so.5.6.0 /usr/lib64/libQt5Gui.so.5.6.0
> 4,5M /usr/lib64/libQt5Core.so.5.6.0
> 4,7M /usr/lib64/libQt5Gui.so.5.6.0и сравни функциональные возможности.
> и сравни функциональные возможности.Да, qt умеет парить, жарить и крестиком вышивать. Поэтому прет под 100 мегов дряни, а время загрузки этого обвеса в память несколько напрягает.
Ты забыл про Widgets, лол. Ну и про зависимости от ICU и libGL
icu отключается.
$ equery uses dev-qt/qtcore:5
…
+ + icu : Enable ICU (Internationalization Components for Unicode) support, using dev-libs/icu
…
opengl или gles2 (или ещё что) сильно зависит от платформу куда вы это собираетесь таки выводить. (пойдите найдите мак/айфон/андроид без этого, а я на вас посмотрю)
зыж
если вы такой непритязательный к своему гую. то нафига вам его вообще писать на си? такой вид садомазо? к тому же (пройдемся тогда по зависимостям, раз пошла такая пьянка), если допустим у меня кеда (с уже предустановленым Qt) ви таки мне в систему (с этой ма-а-а-ленькой библой) и гтк притащите? да ещё без какого-нибудь интросспекшн (который нужен другой проге такого же «шустряка»).
не говоря уже о том, что новые библы — новые траблы, новые дыры. х/з кто его и как пишет, а Qt вполне себе состоявшийся, надежный проект. не говоря уже о том, что фиг его знает насколько качественно сабж будет работать на разных платформах.
ззыж
> Ты забыл про Widgets,да. а ещё и qtxml, qtx11extras, qtxmlpatterns, qtwebsockets, qtsql,… qtbluetooth наконец.
вам с комментатором ниже на пару писать.
Ты невежа. Любое UI-приложение c Qt-контроллами зависит от QtWidgets, QtGui и QtCore.
да, и?
А не всего того длинного списка, если сравнивать только UI-либы.
Ты забыл про qtcore, qtwidgets и прочий qtкудах, без которого оно просто не запустится. Еще icu на 20 метров. В общем счете там на 80 метров либ может быть
Зависимости от icu и gl можно убрать, пересобрав Qt из исходников.
Сабж из исходников пересобрать будет раз в 100 быстрее. А если это еще и распостранять потом захочется...
> Ты забыл про qtcore,серьёзно? а в первой строке что?
> qtwidgets и прочий qtкудах, без которого оно просто не запустится.
это был образец невежества? или как?
вам кастрюлю и на майдан. откуда вы такие упopoтые беретесь вообще.
Ты забыл что в Qt5 до сих пор сломана поддержка шрифтов.
ну вот детская рисовалка на qt Tux paint - она же стартует секунд 20 иногда на стареньком компе - уровня пня 3-4 с 256-512 оперативки, ну куда это годится? отзывчивость интерфейса такая же тугая
Если у разработчиков руки не из плеч, то и Qt им не поможет.
apt-cache depends tuxpaintЗависит: tuxpaint-data
Зависит: libc6
Зависит: libcairo2
Зависит: libfribidi0
Зависит: libgdk-pixbuf2.0-0
Зависит: libglib2.0-0
Зависит: libpaper1
Зависит: libpng12-0
Зависит: librsvg2-2
Зависит: libsdl-image1.2
Зависит: libsdl-mixer1.2
Зависит: libsdl-pango1
Зависит: libsdl-ttf2.0-0
Зависит: libsdl1.2debian
Зависит: zlib1g
Зависит: libvorbis0a
Зависит: libvorbisfile3
Зависит: netpbmи да, на стареньком компе с 128 мб рам довольно шустро работало и стартовало точно быстрее 20 секунд.
мож имеется ввиду "Картофельный парень"? так это kde-приложение, там тебе и звуковой сервер фонон загрузится, и ещё тысячи элементов инфраструктуры, потому что у kde всё своё, и это всё своё ношу с собой :)
>Linux/BSD* - GTK+На скриншоте какое-то GTK3 гoвнo
> Особенностью libui является обеспечение родного для каждой платформы внешнего вида интерфейса, благодаря использованию специфичных для каждой системы виджетов и библиотек (в Linux/BSD* - GTK+, в OS X - Cocoa, в Windows - Win32).
> Библиотека использует векторную модель отрисовки, которая напоминает Direct2D, Cairo и Core Graphics.Т.е. она сама рисует виджеты похожие на "родные" ? Что-то с головой у автора не так ... ну и, кстати, зачем нам ещё один wxWidgets.
Вообще-то графические фреймворки - это не только набор виджетов, а ещё и функции рисования вручную. Эта либа убивает сразу двух зайцев - позволяет одним кодом отображать нативную кнопку на всех трёх осях и также одним кодом рисовать кастомную графику опять же на всех трёх осях.
> Вообще-то графические фреймворки - это не только набор виджетов, а ещё и функции рисования вручную.Вообще то нет, UI это только виджеты которые опционально могут давать срества для отображения кастомных холcтов. А "рисовалка" это отдельная сущность вообще никаком боком не имеющая отношения к UI...
> ... позволяет одним кодом отображать нативную кнопку на всех трёх осях и также одним кодом рисовать кастомную графику ...
Упомянутый Cairo уже является таким кроссплатформенным средством которое везде практически работает одинаково .. в отличие от этой кривой обёртки.
Кстати, я тоже не понял, чем эта штука лучше wx.Но вобще конечно картина умиляет: 2016 год, а в линуксе ни одной нормальной GUI - либо раздутая с кучей всяких ненужных извращений (qt, gtk2, и особенно gtk3), либо страшная и убогая (tk, fltk), либо кривая и глючная (wx).
На этом фоне только FOX toolkit по-человечески выглядит, но я чота сыканул его использовать, т.к. мало распространён.
Есть, это gtk2 и может быть когда-нибудь такой станет gtk3/
То ли дело - Винды, где из коробки есть одна-единственная библиотека GUI - раздутая, с кучей всяких ненужных извращений, страшная и убогая, кривая и глючная...
> То ли дело - Винды, где из коробки есть одна-единственная библиотека GUIОптимизм это хорошо. Есть GDIшные контролы. Их два вида. С темой и без, как манифест пропишешь. Особо чудные программы ухитряются притащить смесь themed и unthemed контролов, по разному прописав манифесты своим частям.
Мало? В дотнете запилили винформсы. Потом решили что это не круто и устарело. И запилили WPF. В браузере захотелось вы#%$нуться и поэтому использовали какие-то другие контролы. А поскольку реюз кода это не про проприетарщиков, то в офисном пакете MS запилил еще набор виджетов. Совсем другой. В результате в типичной винде есть штук 5-6 разных подтипов виджетов. Если какая-нибудь программа не приволокла свои.
> Особенностью libui является обеспечение родного внешнего вида интерфейса, благодаря использованию родных для каждой системы виджетов и библиотекАга, они явно не слышали о Qt и QML. Всем уже давно известно что родные виджеты жрут неимоверно памяти и тормозят, а у них путь понимания сего факта только начинается...
> Ага, они явно не слышали о Qt и QML. Всем уже давно
> известно что родные виджеты жрут неимоверно памяти и тормозятЭто с чего бы это? Вот Qt в последнее время распух неимоверно и пока какой-нибудь vlc стартанет на холодную - можно задолбаться.
Ой задолбаный ты наш, иди - пожалеем
Второй пентиум? 256мб памяти?
> Второй пентиум? 256мб памяти?Лаптоп с механическим HDD и системой на GTK+, так что куть обычно не вгружен в память и плеер первый кто его использует. Тем более что сейчас с версиями кутей двойной Вандамм, двойной бардак. Половине программ прет пятый, половина четвертый. Мало того что периодически в памяти образуется ДВА варианта жирной либы, которые страницы не шарят, так еще и время старта программ - не фонтан. А в сабже кода с гулькин нос, gtk+ и так всегда загружен. Куда приятнее получается.
Так не используй зоопарк программ на пятый и четвёртый кьют. Забудьте вы уже четвёрку как страшный сон и как забыли шиндос свиста.
Год как перевёл систему на „пятёрочку“, на выходных прилетело 5.6.4.
К сожалению, в Qt 5 до сих пор есть несколько назойливых багов (типа трея, или шрифтов, или поддержки тем не как у Qt 4), из-за которых Qt 4 выглядит стабильнее и надёжнее. Самое забавное тут то, что Qt 4 начали закапывaть намного позже, чем GTK+2, но GTK+2 живее (всё ещё поддерживается ведь).Иными словами, очень хочется на Qt 5 и выкинуть Qt 4, но 5 ещё не готов. :(
>Всем уже давно известно что родные виджеты жрут неимоверно памяти и тормозят, а у них путь понимания сего факта только начинается...Что ты называешь "родными" виджетами? GTK? Qt?
А чего, неплохо, можно еще сделать обвязку в виде qml и вообще выпилить QtQuickControls.
> А чего, неплохо, можно еще сделать обвязку в виде qml и вообще
> выпилить QtQuickControls.Так QML и так для отрисовки сделан. Смысл рисовать одним через другое?
Есть же IUP
То же хотел написать. И поддерживает он gtk, motif и win32, и у него есть обвязка для Lua.
> То же хотел написать. И поддерживает он gtk, motif и win32, иMotif - это так актуально, блин. А сабж вместо этого поддерживает макось, что для кроссплатформенных программ все-таки лучше чем motif.
> у него есть обвязка для Lua.
А сабж позволяет написать гуйную программу на си. С читабельным исходником, менее чем килобайт размером. Там такого прямо в примерах к либе - есть. Лютейший win для сишников.
> Motif - это так актуально, блин. А сабж вместо этого поддерживает макось,
> что для кроссплатформенных программ все-таки лучше чем motif.Для кроссплатформенных программ конечно же лучше Motif, потому что он работает сразу, например, в SunOS, AIX и IRIX, а макось только на маках.
> А сабж позволяет написать гуйную программу на си. С читабельным исходником, менее
> чем килобайт размером. Там такого прямо в примерах к либе -
> есть. Лютейший win для сишников.То, что IUP позволяет написать гуйную программу на си, имелось ввиду по умолчанию. Я даже отдельно писать об это не стал.
> SunOSС разморозкой!
Пусть будет....
libui существует уже более года, базируется на либе ui того же автора, которой уже более двух лет. Так почему же "представлена"? Её просто кто-то вдруг для себя открыл и написал об этом "открытии" в ycombinator.
> libui существует уже более года, базируется на либе ui того же автора, которой уже болеедвух лет. Так почему же "представлена"? Её просто кто-то вдруг для себя открыл и написал об
этом "открытии" в ycombinator.Так уже давно многие новости на опеннете рождаются тут: https://github.com/trending
Ясно.Я не против новости, но в заголовке не должно быть слова "представлена".
Да сколько можно! Давайте уже что-нибудь в std::gui.
Чем IUP не угодил?
ГТК - оболчка для иксов и вин32, а это оболочка для ГТК? А потом все будут плеваться почему интерфейс такой тормазнутый - нужно больше ядер будут кричать они, нужно больше оперативы будут вторить им другие. Когда ждать гуй использующий libui?
> ГТК - оболчка для иксов и вин32, а это оболочка для ГТК?А libc - оболочка для syscalls. Вот ведь безобразие.
> благодаря использованию специфичных для каждой системы виджетов и библиотекВсё, можно уже закапывать. Этих "библиотек с нативными виджетами" - вагон и тележка, зачем ещё одно поделие? Не говоря о том, что как раз НАТИВНЫЕ контролы - самый отстоище! Тот же макрософак давно мог бы развить контролы до уровня DevExpress или DevComponents, тогда "просто врапперы" могли бы рулить.
Нам нужна совершенно новая библиотека, где "многоплатформенные" лишь события и отрисовка, сами виджеты надо создавать с нуля - терпеть мелкомягкую халтуру, которую оборачивают в байндинги уже нет никаких сил.
Виджеты должны быть стандартными в рамках ОС - для того, чтобы ориентироваться в интерфейсе любого приложения на автомате. А если в каждом приложении будут свои виджеты, да еще раскрашенные на вкус автора, то это будет кошмар.
нет, не должны. Их даже в убогой винде нет стандартных кроме древних из WinApi.
поэтому, когда я меняю gtk-тему, у меня все приложения начинают выглядеть в едином стиле. а в винде исторически - кто в лес, кто по дрова.
Это только потому, что у тебя все приложения используют gtk, но кде-растам повезло меньше, у них нет нормального набора qt/kde приложений. В винде нет HIG'а, потому там и такое гогно. Но ты не волнуйся, начиная с gtk3 будет такая же фигня и в линуксах.
вообще-то были там guidelines, только о них мало кто знал и еще меньше тех, кто следовал им
Вот правильно. Каждому пользователю по личному интерфейсу. И Свобода рулит. Мой интерфейс - это мой интерфейс!
уг gtk'шное с миллионом зависимостей и spagetti-кодом. Есть давно fltk все тоже самое но на порядок профессиональнее + opengl.
> уг gtk'шное с миллионом зависимостей и spagetti-кодом. Есть давно fltk все тоже
> самое но на порядок профессиональнее + opengl.Только выглядит уродски и почти не используется программами. Ну вот зачем мне в системе выбивающийся по внешнему виду уродец?
документации нет пока, посылают смотреть на ui.h (это файл такой).
поэтому судить о библиотеке именно как о средстве построения интерфейса - трудно, картинок для этого не достаточно. без документации проект сыр и молод.
Документацию пока можно смотреть тут: http://www.purebasic.com/documentation/gadget/index.html
> Документацию пока можно смотреть тут: http://www.purebasic.com/documentation/gadget/index.htmlПослать програмеров на си читать какую-то хню на васике - это просто хамство.
и вот тут ещё http://www.spiderbasic.com/documentation/gadget/index.html
Интересно как оно так красиво компонует компоненты без ручной подгонки для каждой платформы...
А что случилось с той lubui, на которой suse'вский yast построен? Это, я так понимаю, какой-то однофамилец?