Rust 1.11

Создавать их ничто мешать не будет

Благодаря тому, что они на GObject

В контексе такой нетривиальной задачи как гуй не путаю. Тут структурками не обойтись

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

Благодаря тому, что они на GObject

Нет, благодаря тому, что создание нового виджета ничем не отличается от расширения старого. А расширение старого - это банальная возможность выставить свои обработчики для событий (отрисовка/мышь/etc.). И никакого GObject это не требует в принципе. А дальше уже поверх сишного API в каждом языке делай так, как там лучше будет вписываться. В С++, например, в обертку можно виртуальные методы выписать, который будут этими обработчиками.

Ну такое. Плюсовые шаблоны вообще мало кто умеет.

Но в обычной работе QtC намного лучше дополняет, чем racer. И работать в нём приятнее. Clang-code-model реально тугой, это да. Но это не вина QtC.

Использую sublime + racer + rustc-linter.

Можно пример GUI без наследования? Мне реально интересно. Это одна из областей, где ООП тащит.

Да, будет выглядеть отвратительно - прямо как GObject/GTK, но что делать.

А может даже и еще хуже, если вообще не заморачиваться и предложить самый минимум:

void on_clicked( QObject* sender, void* user_data ) {
    qobject_set_property( sender, "text", qarg_pchar("Clicked") );
}

int main( int argc, char** argv ) {
    QObject* app = qobject_new( "QApplication", qarg_int( argc ), qarg_pchar_pchar( argv ) );

    QObject* btn = qobject_new( "QPushButton", qarg_pchar( "Hi!" ) );
    qobject_connect( btn, "clicked", on_clicked, NULL );
    qobject_call( btn, "show" );

    qobject_call( app, "exec" );
}

Для создания такого интерфейса к С надо написать минимум кода, и хоть он ес-но не все покроет (и не все нужно на самом деле), но диалоги/кнопочки создать будет можно. Ну и ес-но это пример именно интерфейса, чтоб писать обертки, а не интерфейса, чтоб прямо в С относительно удобно писать GUI на Qt.

Да

Примеров не дам, ибо сам не видел пока, но я не понимаю почему без ООП там нельзя обойтись. Возможно из-за недостатка опыта в программировании GUI, конечно

Нет

Ну вот QtWidgets использует ООП по полной, и как его заменить композицией/агрегацией - совершенно не понятно.

На Rust пилят свой GUI - conrod, но он еще в дикой альфе. Хз получится ли у них сделать удобный API, даже с учётом ништяков раста.

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

Это как раз-таки проблема мирка nodejs и js-макак, которые до этого клепали слайдеры в интернет-магазинах, а теперь вдруг осознали себя Программистами. Но ничего хорошего не вышло, очевидно, хипстеры и макаки (а на эти две категории подразделяются все, кто использует node, без исключений) не могут осилить ни архитектуру, ничего.

В системах pip и rubygems такого бардака нет. Я как увидел этот npm, он меня сразу поразил своей мусорностью.

Я как увидел этот npm, он меня сразу поразил своей мусорностью.

Тогда в crates.io не заходи. По крайней мере пока. Я поставил какую-то игру, запустил, а она мне в консоль Hello, world вывела. Три других не скомпилялись вообще

Это не проблема crates.io

Я поставил какую-то игру

Он для либ, вообще-то. И все что имеет публичные релизы работает нормально. Я знаю только одну кривую либу - conrod. Он у меня не собирается. Но он альфа, поэтому не страшно.

Нет конечно. Но человек же поразился именно мусорностью

правильные вещи не всегда побеждают.

Лалка. Ты про «экономику qwerty» слышал когда-нибудь?

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

Это такой сарказм? Там же лютый треш и угар. Достаточно посмотреть на их представление про «powerful layout and positioning». Люди смотрят на гуй глазами человека из 80-х.

Лалка. Он об этом же и написал.

Хз, ничего не имею против инстанциирования виджетов в draw-цикле.
С нынешними мощностями и применением какого-нибудь кэширования виджетов и переиспользования кучи так это вообще идеальный вариант.
Кто и застрял в 80х так это люди, которые бредят static layouts и разметкой при компиляции.
На immediate widgets ты можешь что угодно построить, хоть HTML DOM прикручивай и скрипты на JS и рули как хочешь.

Кто и застрял в 80х так это люди, которые бредят static layouts и разметкой при компиляции.

Это ты бредишь или просто не понимаешь простых вещей. У них тупо нет понятия size hint, size constraints, height for width и пр. Нет понятия лайаутов аналогичных Qt/GTK. Все что они могут - как раз по сути статично распихать виджеты по позициям и не дышать на них, не ресайзить окно, не менять dpi, не менять текст/содержимое и т.д. Потому-что при любом изменении у них гуй разлетется по всем швам.

Ты точно смотрел примеры кода и описание в документаци?

Поясни простые вещи, в таком случае. Я не отрицаю, что опыта у меня нет в гуях, я ими не занимался и, если честно они меня интересуют на уровне простых визуализаций, для которых эта либа — топ.

Ты точно смотрел примеры кода и описание в документаци?

Да, и запускал. Почему ты думаешь у них сколько-нибудь сложные примеры не ресайзятся вместе с окном (тормоза отрисовки - отдельный вопрос)? Потому-то их «powerful layout and positioning» умеет только статично расставить виджеты. Максимум - растягивать без всякой привязки к содержимому.

Потому-то их «powerful layout and positioning» умеет только статично расставить виджеты.

Оно еще в pre-alpha же, подожди. Хотя я тоже слабо представляю как можно без костылей это реализовать.

Поясни простые вещи, в таком случае

http://doc.qt.io/qt-5/images/lineedits-example.png

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

если честно они меня интересуют на уровне простых визуализаций, для которых эта либа — топ.

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

Оно еще в pre-alpha же, подожди.

Дело не в pre-alpha, не в недоделанности, а в том что они выбрали кривую концепцию и очевидно не считают ее кривой.

Сначала появляется философия которая должна облегчить жизнь программисту. После её применения то что решалась 10 строчками расползается на 20. Нет. не надо. ООП хорошо себя зарекомендовал. Не хотите ООП? Добро пожаловать в 80(подставте другую цифру если хотите). Потом в 2030 вы переизобретёте ООП и в 2050 ваша философия будет реализована в виде пруфа того что это работает. Только Gtk не трогайте.

Третья страница уже. Ну и где вырвиглазные мозголомки в стиле «кот на клавиатуре» и теории заговора про мазилу? Вообще тред не торт, какой то вялый срач не в тему.

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

Вот добавят оператор '?' в стабильную ветку - тогда и будет срач на тему синтаксиса.

Вот добавят оператор '?' в стабильную ветку - тогда и будет срач на тему синтаксиса.

Наоборот, станет меньше поводов для срача.

Главный поток теперь называется “main” вместо “<main>”.

А ведь могли бы и в “mn” переименовать. Добрейшей души́ люди!

Я не разделяю это неправильное мнение.

Ну, по факту это уже так. «Если твое представление о мире не соответствует объективной реальности, кому от этого хуже, тебе или реальности?»

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

«правильное мнение» ... разбилось о реальность.

А из-за чего, кстати? Экслипс-то упаковали. И для енд-лузера установка IDE'шки через rpm/dpkg всяко удобнее тех супер-нупер инсталляторов, после которых приходится потом ходить и руками дочищать права и прочие .desktop-ы.

Добавлена поддержка цвета для Windows-консолей

Ну офигеть, HKT с монадами пилили бы лучше.

Требования к реалтайму немного разные в умном доме и госпитале/электростанции/дроне/etc.

А вот на D GUI https://github.com/buggins/dlangui

Кроссплатформенное (Linux, OSX, Win), поддерживает OpenGL. Layouts, темы и ресурсы похожи на Android API. Начальная поддержка Андроид.

Скриншоты: http://buggins.github.io/dlangui/screenshots.html

Вот пример приложения на DlangUI - IDE. https://github.com/buggins/dlangide

В первую очередь — зависимые типы, HKT будет позже.

А вот на D GUI https://github.com/buggins/dlangui

И кому нужна эта ненативщина, нарушающая HIG каждой из поддерживаемых платформ?

Не-не-не, не нужно. Уноси обратно.

А вот на D GUI

Не нужно. Лучше бы запилили биндинги к культям и довели их качество до питонячьего уровня.

То есть GObject нужен ровно для того, чтобы расширять Gtk.

Не, это универсальная объектная система, с которой можно работать из разных языков, написав небольшой слой совместимости (gobject introspection). Малой кровью можно притащить в язык объекты, написанные на си — удобно для написания биндингов. К тем же культям полноценный биндинг есть только для питона, например. Остальные через одного лепят все на qml.

Например, для раста уже есть полноценные биндинги для гтк и гстримера, а как там у культей дела? Только qml.

HIG
22.08.2016

Во-первых, в каджой версии ОС/тулкитов HIG меняется (Дуров Кук гей, верни скевоморфинг)

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

В-третьих, покажи мне натив в GUI фотошопа и других больших проектах

Вот пример приложения на DlangUI - IDE. https://github.com/buggins/dlangide

«For Linux and OSX, install MonoDevelop + Mono-D plugin.»

шта?

В-третьих, покажи мне натив в GUI фотошопа и других больших проектах

Microsoft Office на macOS и Windows.

Не нужно переносить свой манямирок на реальность.

HKT с монадами пилили бы лучше.

Уолтон скептически относится к монадам.

Во-первых, в каджой версии ОС/тулкитов HIG меняется

Адаптируйся, при наличии достойных альтернатив пользователь уйдет к конкуренту.

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

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

В-третьих, покажи мне натив в GUI фотошопа и других больших проектах

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

Это для разработки DlangIDE. Для билда нужен только компилятор D + DUB.

Сама IDE + дебаггер (бинарники) = 5Mb в архиве https://github.com/buggins/dlangide/releases