В ваших словах конечно есть истина, как и в моих. Как я уже говорил — я пытался заюзать Qt для данного сценария, проблема не только в размере, официальные сборки не статические, и в винде и в дистрибутивах. В винде приходится прикладывать dll, в лине или делать appimage\snap\flatpak или универсальный бинарь в который все надо линковать статически (из реп может не стоять по дефолту, а если бы стояло — версии разношерстные), на маке тоже придется постараться, в .app формате там приложение — это структура директорий. И универсальная сборка сильно усложняется. Для бльшого софта это норм, для мелкоутилок — ужас, ужас (./util.app/Contents/MacOS/util -f file :3 ).
Размер тоже может иметь значение. Если это мелкоутилка лично моя — меня не будет сильно парить ее размер, разве что не сотни мегабайт. А вот если я в apk на андройд эту либу заюзаю, как в примере с аля-флешкой выше — меня парить уже будет. Или если я эту «флешку» в сайт какой встрою — тоже размер парить будет. Так же если это вдруг не персональная утилита, а какая-то сверх массовая, типа гнушных утилит, то мелкость по функции и черезмерная толстота тоже начнет вызывать вопросы даже на десктопе, а количество утилит в масштабах дистрибутива очень много.
Согласен, претензий к доке и средствам разработки нет. Я только про то что увы, для GPU доступ к памяти тоже еще как нужно оптимизировать, неважно CUDA это или GLSL\HLSL. Для GPU это даже более актуально, если шейдеры не совсем простые, а работают со структурами данных.
Имел счастье работать с nvida компиляторами, вовсе они не лучше. Хотя возражаете вы правильно, ничего там не «прекрасно с обработкой данных и схемами обращения к памяти», у nvidia даже есть специальные документы и статьи по оптимизации работы с памятью. Там все еще сложнее чем с CPU и разброс производительности оптимизированного — не оптимизированного кода может быть гораздо больше.
Никто и не говорит что у такого подхота тоже нету жизни, сейчас каждый второй мессенджер — электрон. И кстати в вебе сейчас тоже есть webgl, а инициализировать его через glfw даже проще. И я бы не сказал, что веб сейчас это такая простая технология сильно проще других областей. Я вот с электроном и nodejs тоже возился и проблем хватало, например когда ставится 2000 njs пакетов, у части есть native и бац — один не компилится, приехали.
Тут все же немного разные области, одно дело одна своя утилита на 400 метров, раз приемлимо и проблем нет — почему бы и нет. Другое дело если каждая такая мелкая системная утилитка типа grep, meld, git gui, kdiff3 итд начнут весить по 400м, жрать по 2 гига и тормозить. Все же во все времена есть какой-то разумный баланс и раз кто-то уже инвестировал свое время в более оптимизированное решение, которым можно воспользоваться — это же хорошо.
Нету такой фичи, у либы вообще нет зависимостей от системы и сама она такие диалоги не рисует. Но в демках и экзамплах уже есть зависимый от системы код.
Вы не сможете сделать утилиту на 100кб, портабельную и которая заработает под всеми дистрибутивами, которую просто скопировал в фаре и работай. Я пробовал, тут даже libstdc++ приходится линковать статически. Под виндой таскать с такими утилками несколько громадных dll тоже не айс, или копировать их в загрузочные пути чтобы все эти утилки заработали. Доп рантайм это гиблое дело, не заставите вы его никого ставить, все проекты эмбедят Qt внутрь. Под виндой даже С++ рантаймы новых студий ставить отдельно не хотят — эмбедят его установщик вместе с софтом. Причем версий рантайма установленных в системе придется делать 100500 т.к. разные утилки будет слинкованы с разными версиями Qt.
А так да, Qt конечно рулит.
Были, мне пришлось пропатчить emscripten, добавив loadDynamicLibrarySrc для загрузки скрипта из памяти. Т.к. скрипт грузится не из файла, а распаковывается из zip («флешка» это скрипт+ресурсы). Там еще по мелочи #ifdef EMSCRIPTEN, немного js в html чтобы загрузить флешку по линку в контейнер откуда emscripten файлы берет.
В целом ничего сложного, за выходные помоему уложился
В демо что я кинул — только nanovg, но вообще да, в невыложенных «флешках» я использую и nuklear для интерфейса\кнопочек итд. Использую glfw, но это кухня плеера, для скрипта вшитого во «флешку», эти подробности скрыты.
Через glfw там были какие то минорные проблемы, но в целом все хорошо работало. Собственно из скрипта аля-флеш мультика моего он тоже работает подо всеми платформами винда\линукс\мак\андройд\ios\веб.
Это псевдо-интерфейс вручную нарисованный nanovg (это почти то же что html5 canvas api, возможности те же). В принципе если код демки использовать — натянуть можно много куда, самому nanovg ничего кроме gl\gles не надо.
Насчет nuklear — да, собственно это уже делали, правда веб демка жаль уже 404, но я видел как она работала)
Благодаря си его еще можно например скриптовать tcc. Я его использую в мини аля-флеш плеере, у которого рантайм около 300кб (размер apk увеличивается на 100кб). Причем работает оно на десктопе, телефонах и веб через emscripten. Вот пример nanovg демки, обернутой в эту штуку (специальо для nuklear демки еще не делал).
Вы правы, это трейдоф удобство\безопасность. В appimage для решения этой проблемы можно подцепить часть пакетов, таких как openssl из системы, пожертвовав частью совместимости. В snap насколько я понял строже и надо ссылаться на снапшот ubuntu-core, хотя точно не уверен.
Так же не для всего софта это так актуально. Например в krita в основном создают контент, хотя если не рисовать, а открывать чужое — риск конечно есть.
Это Canonical`овское изобретение, как и весь http://launchpad.net.
Это не совсем интузиаст, просто на launchpad для создания ppa нужно зарегаться. Вот из команды codeblocks кто-то и зарегался, сделал ppa, и выложил линк на странице оф бинарников.
Увы, для codeblocks однофайлового универсального варианта разработчики не сделали, но сделать можно. Многие популярные проекты уже делают (еще бы, это удобно), в appimage варианте я например использую еще Krita и Avidemux. У Canonical же планы перевести большое количество софта на snap.
Ээ, какой порядок? Для убунты там оф способ этот PPA, какая распаковка? Проверил, все гладко без каких либо проблем.
Вообще для решения этой проблемы (и чтобы не делать разные пакажди под разные дистрибутивы) и придуманы такие решения как appimage\snap\flatpack.
Например KDevelop уже так и делает. И все становится не только в один клик, но обычно и даже без инсталляции.
Собственно подход «все свое ношу с собой» под виндой практикуется уже давно. В лине же он только набирает обороты, это да.
Это вы в GIMP столкнулись? Так он и под виндой system wide профиль не использует, использовать его или нет — всецело на совести приложения. У него своя настройка есть Edit->Preferences->Color Management, там можно выставить ICC профиль.
Что касаемо оболочек: и gnome и KDE — то они тоже имеют поддержку ICC, есть даже специальный демон colord, многие приложения подхватывают system wide профиль автоматически через фреймворки, как и на винде. Некоторые применяют профиль или не применяют в зависимости от условий и настроек, например firefox. Так что о каких заброшенных решениях вы говорите не понятно. У меня у самого корейский монитор для которого нужен профиль и проблем я не испытываю.
Размер тоже может иметь значение. Если это мелкоутилка лично моя — меня не будет сильно парить ее размер, разве что не сотни мегабайт. А вот если я в apk на андройд эту либу заюзаю, как в примере с аля-флешкой выше — меня парить уже будет. Или если я эту «флешку» в сайт какой встрою — тоже размер парить будет. Так же если это вдруг не персональная утилита, а какая-то сверх массовая, типа гнушных утилит, то мелкость по функции и черезмерная толстота тоже начнет вызывать вопросы даже на десктопе, а количество утилит в масштабах дистрибутива очень много.
Тут все же немного разные области, одно дело одна своя утилита на 400 метров, раз приемлимо и проблем нет — почему бы и нет. Другое дело если каждая такая мелкая системная утилитка типа grep, meld, git gui, kdiff3 итд начнут весить по 400м, жрать по 2 гига и тормозить. Все же во все времена есть какой-то разумный баланс и раз кто-то уже инвестировал свое время в более оптимизированное решение, которым можно воспользоваться — это же хорошо.
А так да, Qt конечно рулит.
В целом ничего сложного, за выходные помоему уложился
Насчет nuklear — да, собственно это уже делали, правда веб демка жаль уже 404, но я видел как она работала)
Так же не для всего софта это так актуально. Например в krita в основном создают контент, хотя если не рисовать, а открывать чужое — риск конечно есть.
Это не совсем интузиаст, просто на launchpad для создания ppa нужно зарегаться. Вот из команды codeblocks кто-то и зарегался, сделал ppa, и выложил линк на странице оф бинарников.
Увы, для codeblocks однофайлового универсального варианта разработчики не сделали, но сделать можно. Многие популярные проекты уже делают (еще бы, это удобно), в appimage варианте я например использую еще Krita и Avidemux. У Canonical же планы перевести большое количество софта на snap.
Вообще для решения этой проблемы (и чтобы не делать разные пакажди под разные дистрибутивы) и придуманы такие решения как appimage\snap\flatpack.
Например KDevelop уже так и делает. И все становится не только в один клик, но обычно и даже без инсталляции.
Собственно подход «все свое ношу с собой» под виндой практикуется уже давно. В лине же он только набирает обороты, это да.
Что касаемо оболочек: и gnome и KDE — то они тоже имеют поддержку ICC, есть даже специальный демон colord, многие приложения подхватывают system wide профиль автоматически через фреймворки, как и на винде. Некоторые применяют профиль или не применяют в зависимости от условий и настроек, например firefox. Так что о каких заброшенных решениях вы говорите не понятно. У меня у самого корейский монитор для которого нужен профиль и проблем я не испытываю.