который из этого описания сгенерирует код на С

Ну попробуй, напиши.

Да, я догадываюсь, что это трудно. Даже, наверное, очень трудно. Но вот если получится... У-уу...

Я просто оставлю это здесь.

https://ru.wikipedia.org/wiki/WxWidgets

и мы получаем компактное нативное и вместе с тем кроссплатформенное приложение

Монструозная библиотека не значит не компактное нативное приложение. Нужно просто линковать статически и делать link time optimization.

20 лет уж как есть Java JFC.

Чем тебе JVM не компилятор, который генерит нативный код из кросс-платформенного байткода?

Как меня люто бесит это ваше нативное.
Нет, ладно слышать нативное о Windows или MacOS. Там есть нативное.
Но у вас то нет.
У вас зоопарк тулкитов и никакой не является единственным родным встроенным в систему. Потому что и нет системы. Разве что x11. Но только я не вижу, что вы используете приложения на иксовых виджетах.

Вообще удивляет то, как вы говоря о Линуксе, можете говорите о нем как об ОС (когда это не так), не конкретизируя в своих топиках дистрибутив.

Он же сделал оговорку: «Для Windows это будут вызовы апишных функций, для линукса можно по выбору вызывать либо GTK (всё равно она почти в любом линуксовом десктопе есть), либо Xt+Xaw.»

на винфак быдло!!! (с)

либо Xt+Xaw.

А почему не либо QT\FLTK\Wx\nuklear\motif\etc?

GTK (всё равно она почти в любом

В том-то и дело, что почти.
Если не предусмотреть всех вариантов, выходит, что уже не так и кроссплатформенно?

Суть в том, что я писал сейчас не конкретно об этом ТС. А о теме нативного ГУИ в линуске вообще. Его нет. Не было и не может быть. В линуксе нативные только сисколы.

ррррряяяяя

Ну и к слову на финде тулкитов едва ли не больше чем в гнулинукс - MFC, WTL, WinForms, VCL....

Это всё обертки. И они все так же нативны. Потому что винда это ОС. Линукс - это не ОС.

Линакс — не ОС. А жну/линакс — ОС. Расскажи мне лучше, по какому критерию ты оцениваешь «нативность» гуи тулкита?

Но вот если получится... У-уу...

А чего, собственно, «У-уу»?

Это только на ЛОРе и подобных ему клубах перфекционистов до сих пор обсуждают, насколько Qt тяжелее GTK, и как бы сделать ещё полегче. Большинство же разработчиков давно скучковались в несколько групп:

• забили на кроссплатформенность вообще;
• пишут на кутях (бывает, что и на GTK, wxWidgets, etc., но реже);
• пишут на Java/C#;
• пишут на JS и тащат в свои программы браузер.

И тенденция такая, что последняя группа постоянно растёт и скоро скушает первые три (да-да, даже первую, как ни удивительно). На этом фоне пытаться сэкономить ещё по 20 метров на приложение...

Мне очень жаль. Увы. Но вряд ли кто будет тратить человеко-годы на реализацию твоей идеи. Если только сам попробуешь... (почему бы нет).

Судя по моему знанию про WxWidgets, это не совсем то, что хотел ТС. Но возможно, надо обновить знания.

Монструозная библиотека не значит не компактное нативное приложение.

Вот, кстати, да. И её отсутствие не гарантирует компактности (тот же препроцессор может нагородить мусора огого).

https://en.wikipedia.org/wiki/Windows_USER

Ага, обертки над либц и сисколами ядра :))))))))))))))

Так это же не кроссплатформа, а отдельные версии под каждую ОС. Просто ты предлагаешь собирать их несколько иным способом, что не так важно.

Кроссплатформа - это когда один и тот же код работает везде. Поэтому кодеры стараются брать кроссплатформенные фреймворки, чтобы написать одну единственную версию. Как максимум - множество компиляций, а если это какой-нибудь Python, вообще великолепно.

Пойми, железо стоит дешевле времени кодеров, которых ты хочешь заставить клепать разные версии. У пользователей в большинстве случаев ПК тянет сильно жрущие приложения, они как-нибудь стерпят. Вон Electron как заглатывают, на форумах пердят и всё равно пользуются.

А препроцессор не взлетит. Везде специфичные баги и особенности, даже если он правильно всё сгенерирует, всё равно придётся лезть в потроха.

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

Вот меня давно этот вопрос интересует, так что спрошу тут - с чего вдруг JVM это нативно и кроссплатформенно? По сути мы также можем хоть тот же bash считать кроссплатформенным - поднимай под виндой виртуалку с GNU/Linux и запускай свои скрипты там, чем это будет отличаться от JVM?

Но ведь можно сделать абстракцию по-другому

Проект pix2code ©: нейросеть генерирует код GUI по скриншотам кроссплатформенно.

Еще один юный полюционер революционер от программирования. Ну удачи, бро.

Нет. Обертки, над нативными библиотеками уровня юзерспейса. Прикинь?))))

Такая штука когда пишешь высокоуровневый кросс-платформенный код, а оно под капотом под виндой использует виндовые api, под linux X11, а под макосью - макосевые? Дай подумать... Ты изобрёл любую кросплатформенную GUI библиотеку. WX или Qt.

А что до отличия библиотеки от препроцессинга, так препроцессинг это то же самое как если бы ты сделал WX или Qt header-only библиотекой. Удачи.

Вообще, вы переизобретаете вот это: https://en.wikipedia.org/wiki/List_of_user_interface_markup_languages

Ты изобрёл любую кросплатформенную GUI библиотеку. WX или Qt.

он хочет чтобы из его кроссплатформенного гуя сляпанного в каком-нибудь glade нейросеть сама конвертнула/сгенерировала программу на cocoa и win32 api без прослоек.

судя по всему, его не волнует что дизайн программ под каждую ОС существенно отличается, и даже в самых кроссплатформенных прогах на жабах и электронах есть тонны костылей под каждую OS.

а про мобильные он и вообще не подумал.

он хочет чтобы из его кроссплатформенного гуя сляпанного в каком-нибудь glade нейросеть сама конвертнула/сгенерировала программу на cocoa и win32 api без прослоек.

Именно. Кстати, я тут, почитав википедию, слегка запутался в маковских API - родные виджеты предоставляет именно Cocoa или кто-то ещё?

судя по всему, его не волнует что дизайн программ под каждую ОС существенно отличается, и даже в самых кроссплатформенных прогах на жабах и электронах есть тонны костылей под каждую OS.

Я догадываюсь, что какое-то количество условных компиляций для особо тяжёлых случаев таки придётся писать руками. Вы вообще про какие костыли - которые уже реализованы в тулкитах или про те, которые конечному прикладному разработчику придётся добавлять самому? От этого уточнения сильно зависит, как с ними бороться.

а про мобильные он и вообще не подумал.

Не написал - не значит не подумал, просто я их плохо знаю. Насколько мне известно, тот же Qt портирован на Android, значит, в NDK есть возможность работать с GUI, а следовательно, эти же вызовы можно дёргать и из того же самого сгенерённого кода. Если я ошибаюсь, то где?

А что до отличия библиотеки от препроцессинга, так препроцессинг это то же самое как если бы ты сделал WX или Qt header-only библиотекой. Удачи.

Не совсем то же самое. В header-only библиотеке всё равно сохраняются все классы Qt, только при компиляции они окажутся в других объектных файлах. А я хочу, чтобы виндовые и прочие api использовались в компилируемом коде без прослоек.

Да, возможно, в случае wxWidgets отличие не такое сильное, как с Qt, ведь там самая прослойка достаточно тонкая, а если её ещё можно статически собрать вместе с программой (как это некоторые делают с Qt), то не исключено, что результат будет совсем ненамного тяжелее, чем по методу, который предлагаю я. А wxWidgets, в отличие от того, что предлагаю я, уже написан. :( Надо подумать...

Cocoa

this

или про те, которые конечному прикладному разработчику придётся добавлять самому?

this

Если я ошибаюсь, то где?

в этом контексте нигде. из нативного кода действительно через JNI можно дергать всю жабу с ее нативными андроидными виджетами.

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

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

(но название NDK вводит в заблуждение, да — это другое native)

или про те, которые конечному прикладному разработчику придётся добавлять самому?

this

А их действительно так уж тонны? Впрочем да, это зависит от конкретного проекта, без него разговор беспредметен.

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

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

Получается, так, чтобы кроссплатформенно и нативно на всех платформах - вообще нельзя? (Даже безотносительно к моей начальной идее.)

Получается, так, чтобы кроссплатформенно и нативно на всех платформах - вообще нельзя? (Даже безотносительно к моей начальной идее.)

как уже заметили выше, на некоторых платформах вообще кроме сисколлов ничего нативного нет.

но все это конечно можно в хеллоуворлдах. в настоящих больших проектах без AI не обойтись.

Да-да, а квадрат не прямоугольный а квадратный!

Не совсем то же самое. В header-only библиотеке всё равно сохраняются все классы Qt, только при компиляции они окажутся в других объектных файлах. А я хочу, чтобы виндовые и прочие api использовались в компилируемом коде без прослоек.

В объектных файлах нет классов, там будет машинный код. С вызовами вендовых API.

В объектных файлах нет классов, там будет машинный код. С вызовами вендовых API.

так-то оно так, но вызовы вендовых API будут происходить через несколько слоев абстракции.

Ичо? Они будут и в нативнейшем win-only коде.

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

В объектных файлах нет классов, там будет машинный код.

Классы и в объектных файлах следы оставляют. Таблицы виртуальных методов и всё такое...

Но ведь можно сделать абстракцию по-другому

А разве есть преимущества?

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

А Qt/GTK+ мгновенно компилируются? Ведь если их код тянуть в каждую программу (что ты предлагаешь), то решение это не компактное, а тяжёлое и требующее ещё больше времени на компиляцию каждого приложения.

А Qt/GTK+ мгновенно компилируются? Ведь если их код тянуть в каждую программу (что ты предлагаешь)

Нет. «Их код тянуть в каждую программу» - это называется статическая сборка. А я предлагаю просто обойтись без них. В исходниках перед компиляцией будут дёргаться родные API.

требующее ещё больше времени на компиляцию каждого приложения.

Компиляцию - да, зато будет выигрыш по времени исполнения.

Нет. «Их код тянуть в каждую программу» - это называется статическая сборка. А я предлагаю просто обойтись без них. В исходниках перед компиляцией будут дёргаться родные API.

Так и в них же родные API дёргаются, ибо как бы они тогда работали?

Компиляцию - да, зато будет выигрыш по времени исполнения.

1%? Ведь тот код в библиотеках же не спроста там. Нужен. Значит,

некий препроцессор, который из этого описания сгенерирует код на С

по сути нагенерирует его со всеми ifdef'ами, обработками особенностей, обходом багов...