Здравствуйте, AeroSun, Вы писали:
M>>>В итоге — имеем .h и .cpp для включения в проект AS>·>Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код. AS>Потому что целый пласт задач можно закрыть только через рефлексию, а её в плюсах нет. AS>На макросах и шаблонах из-за отладки и неочевидности (говнокодовости) получается на порядки дольше + больше багов + тяжелее баги отлаживать + уродливее код (это для использования, потому что в либе будет вообще ад) + всё равно не покроет потребности. AS>К примеру RPC — любое решение на макросах и шаблонах в итоге имеет уродливый синтаксис + всё равно надо контролировать самому и серверную и клиентскую часть. В отличии от генерации.
Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включаются в проект только исходники, которые могут правиться человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Marty, Вы писали:
M>·>Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включаются в проект только исходники, которые могут правиться человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории. M>Ну, вот у нас есть протокол обмена для девайсов, и есть язык, на котором описывается, что и как передается. Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться. Вот тут тоже нужен бы визард
Всё равно непонятно. Т.е. доки плохие, куча непонятных параметров, только ты будешь знать какие кнопки в каком порядке натыкать, иначе магия не сработает... Жоп секьюрити что-ли?
Опиши конфиуграцию кодогенерации на каком-либо языке, json/xml/python/whatever и сделай частью исходников.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
M> Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
M>Для таких случаев обычно в каждой уважающей себя среде разработки есть инструментарий для создания таких мастеров, а каждая уважающая себя библиотека, особенно претендующая на звание фреймворка, поставляет свои мастера-визарды для большинства популярных сред разработки.
Обычно подобные задачи решаются cmdline скриптами. Визард — это скрипт для специализированной задачи к которому добавили UI. Не совсем понятно зачем тебе UI, так как они обычно нужны только для сложной и/или продолжительной визуализации. Вроде у тебя не этот случай. Для шаблоной генерации файлов во всяких питонах и прочих есть куча удобных библиотек.
Re[6]: Универсальный визард (мастер) - зачем таки нужно
Здравствуйте, Mamut, Вы писали:
M>>>>Потому что это фиксированный набор с заранее известными параметрами. Там нет никаких «универсальных визардов». S>>>ЕМНИП в QtCreator именно универсальный визард для новых проектов, возможные параметры, на основе которых генерится GUI, хранятся где-то в текстовом виде.
M>>Это опять вендор-лок. Так-то в итоге "параметры, на основе которых генерится GUI", у всех хранятся где-то в каком-то текстовом виде
M>А магический интерпретатор магического DSLя для магического всемогущего визарда не будет вендор-локом, естественно. Он магическим образом возникнет из неоткуда и сразу решит все твои проблемы.
Здравствуйте, Sinclair, Вы писали:
M>>Это как? Вот у меня есть опция, где-то в коде она проверяется, что равна одному из пяти-десяти фикс значений, и что, такой автокомплит бывает? S>Конечно. ValidateSet.
M>>Или, например, сам шаблон задается в ходе выбора в визарде, и последующие возможные переменные зависят от того, какой шаблон выбран. Как вот это всё нормально в консольке организовать? S>Да, такое тоже возможно. Parameter Sets.
S>https://adamtheautomator.com/the-powershell-parameter/
Есть ещё более гибкий вариант, который почему-то мало где описан: Register-ArgumentCompleter (начиная с 5 версии входит в powershell, до этого ставится через модуль TabExpansionPlusPlus), он позволяет просто зарегистрировать функцию, которая будет дополнять аргумент:
function Test($Name) {
Write-Host $Name
}
Register-ArgumentCompleter -CommandName Test -ParameterName Name -ScriptBlock { (ls C:\).Name }
После этого для Test -Name <tab> будет выведены имена файлов в C:\. Причём в эту функцию передеются уже заданные параметры, и можно на их основе делать автодополнение.
Собственно это всё старо как UI сам по себе. Был такой Dreamweaver которым можно было делать сайты-поделки одно время в режиме WYSIWYG.
Но мы уже давно ушли от ситуации когда у всех были 800x600 экранов с 96dpi и от HTML 3.2 где это имело смысл использовать.
Оказалось что для разработки UI проще всего освоить базовые понятия которые умещаются на страницу печатного текста, например.
Ну 10-20 базовых CSS свойств. CSS более-менее универсален сейчас: Web, QML, GTK, тот же Sciter.
Всяко быстрее результат будет если просто писать дефиниции в notepad каком. Ну и потом это реально полезно — хотя бы понимать как сделать сайт для своего же приложения.
Проблема в том что создание этих самых "визардов" экономически не целесообразно. Профессионалам (кто согласны платить) оно не нужно — им нужно чтобы UI дефиниции были diff`able,
а любители не освоившие базовый набор, которым это нужно на один раз, денег не платят, ибо действительно зачем оно для одного раза-то?
Apple сделал свою среду сугубо для любителей чтобы с них получить те самые 100 баксов которые стоит AppStore publishing subscription.
Т.е. для них эта разработка оправдана. В AppStore 3.06 млн. приложений, т.е. от wizard они получили 300 млн. баксов.
А полезных/популярных приложений, разрабатываемых профессионально (т.е. без этих вот визардов), реально там если 1000 будет то хорошо.
Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
Для таких случаев обычно в каждой уважающей себя среде разработки есть инструментарий для создания таких мастеров, а каждая уважающая себя библиотека, особенно претендующая на звание фреймворка, поставляет свои мастера-визарды для большинства популярных сред разработки.
Проблема в том, что для каких-то своих задач такие инструменты, предоставляемые средой разработки, обычно слишком сложны — пока разберешься что там к чему, можно уже вручную наколбасить сто раз. Ну, и при переезде на другую среду все наработки пропадают. Не, можно держать и старую систему только ради визардов, и запускать её только ради них, но это перебор. А если сменили хост платформу, и на новой нет предыдущей IDE?
В общем, на мой взгляд, есть такая проблема. Кто как её решает? Ну, если у вас есть аналогичная проблема?
ЗЫ Хотел сначала в "Средства разработки" закинуть, но, наверно, тема больше для холивара
Здравствуйте, Marty, Вы писали:
M>Проиллюстрирую.
M>Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
M>Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё. M>Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры. M>В итоге — имеем .h и .cpp для включения в проект
Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, AeroSun, Вы писали:
AS>>>К примеру RPC — любое решение на макросах и шаблонах в итоге имеет уродливый синтаксис + всё равно надо контролировать самому и серверную и клиентскую часть. В отличии от генерации. AS>·>Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включатся в проект только исходники, которые могут правится человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории. AS>У городи бузина, а в Киеве — дядько AS>Ты ж сам спрашивал зачем генерировать, раз макросы и шаблоны в плюсах есть.
Эээ... Ну про киевского дядку ты начал. У топикстартера было визарде, как я понял, генерирующий "рыбу" исходников, которые он собирался класть в проект. Я считаю, что так делать не надо. А ты привёл пример про RPC. И, как выяснилось, для RPC тоже так не делается. В итоге так никто и раскрыл накой нужен сабж.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Marty, Вы писали:
M>>>Ну, например, какой-нибудь class wizard свой. M>·>Магию в топку. Ты программист или где? M>Ок, я не программист.
Тогда найми программиста, чтобы он тебе на ангуляре сваял визарда.
M>Я не пойму, что ты мне доказать-то хочешь?
Что программистам гуй не нужен.
M>И при чем тут хорошая IDE, это только пример был для плюсиков, а в реале, допустим, надо сформировать командную строку для вызова какой-нибудь тулзы, или это
Программист напишет код, хоть там одноразовый bash-скриптик. Непрограммисту командные строки c lua не нужны.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Marty, Вы писали:
S>>Он MSVC пришиблен. M>Я тебя так сильно чем-то обидел?
Извини, я резко высказался. Мир-дружба-жевачка.
Я хотел сказать, что с моей точки зрения, студия прививает неправильную культуру управления проектами. При всей уродливости языка идеалогически подход типа CMake правильнее.
Здравствуйте, Marty, Вы писали:
S>>Скажем, в повершелле как раз это всё решено очень даже неплохо. Всяко лучше, чем в самопальном GUI-визарде.
M>Это как? Вот у меня есть опция, где-то в коде она проверяется, что равна одному из пяти-десяти фикс значений, и что, такой автокомплит бывает?
Конечно. ValidateSet.
M>Или, например, сам шаблон задается в ходе выбора в визарде, и последующие возможные переменные зависят от того, какой шаблон выбран. Как вот это всё нормально в консольке организовать?
Да, такое тоже возможно. Parameter Sets.
M>>>Или, например, сам шаблон задается в ходе выбора в визарде, и последующие возможные переменные зависят от того, какой шаблон выбран. Как вот это всё нормально в консольке организовать? S>>Да, такое тоже возможно. Parameter Sets.
S>>https://adamtheautomator.com/the-powershell-parameter/
S>Есть ещё более гибкий вариант, который почему-то мало где описан: Register-ArgumentCompleter (начиная с 5 версии входит в powershell, до этого ставится через модуль TabExpansionPlusPlus), он позволяет просто зарегистрировать функцию, которая будет дополнять аргумент: S>
S>function Test($Name) {
S> Write-Host $Name
S>}
S>Register-ArgumentCompleter -CommandName Test -ParameterName Name -ScriptBlock { (ls C:\).Name }
S>
S>После этого для Test -Name <tab> будет выведены имена файлов в C:\. Причём в эту функцию передеются уже заданные параметры, и можно на их основе делать автодополнение.
PowerShell и его крутые фичи — это конечно круто, но, на мой взгляд, уже слишком круто. А гуя с ними так и не сварить.
Вот и получается, что проще запилить свой DSL с интерпретатором, чем использовать PowerShell или что-то подобное.
Свой интерпретатор хотя бы не сломается при каких-то обновлениях.
Здравствуйте, Marty, Вы писали:
M>В общем, на мой взгляд, есть такая проблема. Кто как её решает? Ну, если у вас есть аналогичная проблема?
Когда у меня возникает необходимость в обобщении типовых случаев, делаю командно-строковые скрипты. Долгое время ваял их на убогом и кривом недоязыке cmd.exe, но сейчас заставляю себя переползать на что-то более другое. Желания сделать гуевые конфигураторы не возникало никогда — слишком геморройно и малоэффективно.
M>>ЗЫ Хотел сначала в "Средства разработки" закинуть, но, наверно, тема больше для холивара
CS>Т.к. я примерно представляю откуда у этого крика души ноги растут. Ну и в качестве иллюстрации проблемы.
Не, не представляешь, похоже
Твоё представление, похоже, инспирировано моими вопросами по скайтеру. Но тут совсем не об этом
CS>Собственно это всё старо как UI сам по себе. Был такой Dreamweaver которым можно было делать сайты-поделки одно время в режиме WYSIWYG. CS>Но мы уже давно ушли от ситуации когда у всех были 800x600 экранов с 96dpi и от HTML 3.2 где это имело смысл использовать.
Я не про UI, не смотри только под этим углом
CS>Такая вот экономика.
Проиллюстрирую.
Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё.
Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры.
В итоге — имеем .h и .cpp для включения в проект
Здравствуйте, Marty, Вы писали:
M>Проиллюстрирую.
M>Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
M>Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё. M>Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры. M>В итоге — имеем .h и .cpp для включения в проект
Здравствуйте, c-smile, Вы писали:
M>>Проиллюстрирую.
M>>Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
M>>Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё. M>>Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры. M>>В итоге — имеем .h и .cpp для включения в проект
CS>В чем проблема? Заплати кому-нибудь — напишут. Для web, sciter, или вообще command line на, скажем, nodejs. Типа этого https://expressjs.com/en/starter/generator.html
Ну, так-то любая проблема решается баблом, не?
И, так-то, я себе накидал такое, просто интересно, как люди живут и решают аналогичные проблемы
Здравствуйте, Marty, Вы писали:
M> Здравствуйте!
M>Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
А можно пример такой задачи, которую предполагается решить универсальным визардом?
M>В общем, на мой взгляд, есть такая проблема. Кто как её решает? Ну, если у вас есть аналогичная проблема?
Не понятно, в чем состоит проблема, и в чем ее универсальность.
Вот все, что ты описал:
что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
Что кликнул, куда кликнул, какие файлики, ничего не понятно
Единственное из моих задач, которые подходят под это описание — это генерация блога. Для этого я взял Hugo. Для каких-то других задач у меня набор шелл-скриптов (например, переключение gcp и kubectl контекстов). Для каких-то третьих задач у меня будет что-то еще.
Как и где мне поможет какой-то «универсальный визард», учитывая, что универсальных задач мало, не понимаю.
Здравствуйте, ·, Вы писали:
M>>В итоге — имеем .h и .cpp для включения в проект ·>Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код.
Потому что целый пласт задач можно закрыть только через рефлексию, а её в плюсах нет.
На макросах и шаблонах из-за отладки и неочевидности (говнокодовости) получается на порядки дольше + больше багов + тяжелее баги отлаживать + уродливее код (это для использования, потому что в либе будет вообще ад) + всё равно не покроет потребности.
К примеру RPC — любое решение на макросах и шаблонах в итоге имеет уродливый синтаксис + всё равно надо контролировать самому и серверную и клиентскую часть. В отличии от генерации.
Здравствуйте, Marty, Вы писали:
M>Есть где на неё посмотреть?
Нигде, у меня часть проектов — личные, являются моим конкурентным преимуществом над остальными.
Но в целом система лёгкая — берёшь смотришь как работают нужные визарды, я к примеру смотрел на msvs. И копируешь, изменяя всё, что тебе надо и делая их интелектуальными.
Если я правильно помню день ушло на систему, день на пачку из десятка визардов. Оно всё простое.
Здравствуйте, ·, Вы писали:
AS>>К примеру RPC — любое решение на макросах и шаблонах в итоге имеет уродливый синтаксис + всё равно надо контролировать самому и серверную и клиентскую часть. В отличии от генерации. ·>Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включатся в проект только исходники, которые могут правится человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории.
У городи бузина, а в Киеве — дядько
Ты ж сам спрашивал зачем генерировать, раз макросы и шаблоны в плюсах есть.
Здравствуйте, c-smile, Вы писали:
CS>Собственно это всё старо как UI сам по себе. Был такой Dreamweaver которым можно было делать сайты-поделки одно время в режиме WYSIWYG. CS>Но мы уже давно ушли от ситуации когда у всех были 800x600 экранов с 96dpi и от HTML 3.2 где это имело смысл использовать.
CS>Оказалось что для разработки UI проще всего освоить базовые понятия которые умещаются на страницу печатного текста, например. CS>Ну 10-20 базовых CSS свойств. CSS более-менее универсален сейчас: Web, QML, GTK, тот же Sciter. CS>Всяко быстрее результат будет если просто писать дефиниции в notepad каком. Ну и потом это реально полезно — хотя бы понимать как сделать сайт для своего же приложения.
А мне вот не хватает чего-то, что позволяет тупо набросать интерфейс в графическом виде. Мне не нужен сгенеренный код, нужна удобная рисовалка, а код я потом сам напишу. Но самое удобное, что удалось найти — это бумажный лист, однако на нем не задать никакого поведения.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>А мне вот не хватает чего-то, что позволяет тупо набросать интерфейс в графическом виде. Мне не нужен сгенеренный код, нужна удобная рисовалка, а код я потом сам напишу. Но самое удобное, что удалось найти — это бумажный лист, однако на нем не задать никакого поведения. https://www.qt.io/ui-design-tools? Я не пробовал.
Здравствуйте, Skorodum, Вы писали:
Ops>>А мне вот не хватает чего-то, что позволяет тупо набросать интерфейс в графическом виде. Мне не нужен сгенеренный код, нужна удобная рисовалка, а код я потом сам напишу. Но самое удобное, что удалось найти — это бумажный лист, однако на нем не задать никакого поведения. S>https://www.qt.io/ui-design-tools? Я не пробовал.
Примечательно:
А мне как раз хочется просто рисовалку, но с поведением, вроде открытия менюшек, адаптивности и т.п. Может фотошоп что-то такое и умеет, но он действительно сложен, а для простых случаев не так удобен, как лист бумаги.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ·, Вы писали:
M>>Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
M>>Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё. M>>Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры. M>>В итоге — имеем .h и .cpp для включения в проект ·>Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код.
Ну, код вроде и так написан уже с использованием либы — SPL называется. Только вот незадача — она слегка несовместима между собой для разных семейств MCU. Можно поверх еще оберток написать, или к хренам всё переписать на на регистрах, но это потребует времени, которое не окупится. А так — накидал визардик, он, в зависимости от выбранного семейства выбирает шаблон, и подставляет параметры
Здравствуйте, AeroSun, Вы писали:
AS>Но в целом система лёгкая — берёшь смотришь как работают нужные визарды, я к примеру смотрел на msvs. И копируешь, изменяя всё, что тебе надо и делая их интелектуальными. AS>Если я правильно помню день ушло на систему, день на пачку из десятка визардов. Оно всё простое.
Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё.
Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры.
В итоге — имеем .h и .cpp для включения в проект
Да, можно всё завернуть в библиотеки. Но это время, и не факт, что это когда-нибудь окупится.
Вот посмотрите — в той же MSMS — визарды проектов в количестве пары-тройки десятков. Для тех же плюсиков — class wizard, qt class wizard. Для других языков не смотрел, но, скорее всего, там свои волшебники есть.
Если взять другую среду, там будут свои аналоги. Только работают и генерят не совсем уже то и не совсем уже так. Можно использовать только готовое, можно изучать, как это сделано в конкретной среде и допиливать её средствами, но ведь удобнее, чтобы такое средство работало везде и всегда, вне зависимости от среды, и лучше — системы вообще
Здравствуйте, Marty, Вы писали:
M>Ну, код вроде и так написан уже с использованием либы — SPL называется. Только вот незадача — она слегка несовместима между собой для разных семейств MCU. Можно поверх еще оберток написать, или к хренам всё переписать на на регистрах, но это потребует времени, которое не окупится. А так — накидал визардик, он, в зависимости от выбранного семейства выбирает шаблон, и подставляет параметры
Оффтопик, и давно с stm не работал, но чего HAL не заюзаешь?
SPL разве ещё поддерживается st microelectronics (багфиксы и прочее)?
Здравствуйте, Mamut, Вы писали:
M>Единственное из моих задач, которые подходят под это описание — это генерация блога. Для этого я взял Hugo. Для каких-то других задач у меня набор шелл-скриптов (например, переключение gcp и kubectl контекстов). Для каких-то третьих задач у меня будет что-то еще.
M>Как и где мне поможет какой-то «универсальный визард», учитывая, что универсальных задач мало, не понимаю.
Ну, у тебя вот какой-то набор скриптов есть, ты что-то запускаешь, какие-то параметры небось задаешь, и тп. Для этого вполне можно графическую морду приделать — удобно, когда не слишком часто такие задачи повторяются — имена параметров/значений забываешь, приходится лазить смотреть в сорцы скриптов. Опять же, такие скрипты плохо шарятся в команде — каждому надо будет их изучать. А допустим, вот мы на плюсиках пишем продуктовый код, а я напишу таких скриптов себе на питоне. А в команде питон никто не знают и нахрен он особо никому не сдался. А так — запустил визард, прокликал что надо, забил параметры и всё, готово
Здравствуйте, Михaил, Вы писали:
М>Оффтопик, и давно с stm не работал, но чего HAL не заюзаешь?
Ну, HAL — это кал. Во, даже в рифму вышло. HAL как раз во всю такой визард используется, большой и жырный, STM32 Cube называется. Мне всё это хозяйство не нравится тем, что понять, почему нагенеренное не работает мало реально, нельзя просто взять и перекомпилить код под другой камень — нужно опять в куб лезть и заного генерить рыбу, и тп.
М>SPL разве ещё поддерживается st microelectronics (багфиксы и прочее)?
SPL — да, на неё уже забили, но у нас всё легаси на нем.
Вроде на HAL ST тоже начинает забивать, у них там какая-то новая либа, какая-то LL вроде
Здравствуйте, Ops, Вы писали:
Ops>Примечательно: Ops>Image: brB7gME.png
Ops>А мне как раз хочется просто рисовалку, но с поведением, вроде открытия менюшек, адаптивности и т.п.
Ну так чего не хватает-то? Судя по описанию это именно оно.
Ops>Может фотошоп что-то такое и умеет, но он действительно сложен, а для простых случаев не так удобен, как лист бумаги.
Планшет графический подключи к фотошопу
Здравствуйте, Marty, Вы писали:
M>·>Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код. M>Ну, код вроде и так написан уже с использованием либы — SPL называется. Только вот незадача — она слегка несовместима между собой для разных семейств MCU. Можно поверх еще оберток написать, или к хренам всё переписать на на регистрах, но это потребует времени, которое не окупится. А так — накидал визардик, он, в зависимости от выбранного семейства выбирает шаблон, и подставляет параметры
Звучит как: "Думать некогда, прыгать надо. Щаз тут я накопипастю!". В принципе иногда окупается, но если ты задумываешься о том, чтобы потратить время на автоматизацию копипасты, то это уже чересчур.
M>Вот посмотрите — в той же MSMS — визарды проектов в количестве пары-тройки десятков. Для тех же плюсиков — class wizard, qt class wizard. Для других языков не смотрел, но, скорее всего, там свои волшебники есть.
Это неимверное г-но которое тащут традиционно, т.к. когда-то было в первых версиях MSVS. Эти одноразовые визарды в топку, ибо юзабельны только для создания видеоучебников.
В той же IDEA есть рефакторинги и Intentions, которые не просто создают новые файлы, а действуют на уровне сущностей. Т.е. например, "сгенерить метод toString таким-то стилем для данных полей класса", "создать тест для данного класса", "добавить setUp метод для тестов", "первратить локальную переменную в поле класса". И если у тебя есть потребность делать такое — можно сделать плагинчик, API дан.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включаются в проект только исходники, которые могут правиться человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории.
Ну, вот у нас есть протокол обмена для девайсов, и есть язык, на котором описывается, что и как передается. Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться. Вот тут тоже нужен бы визард
Здравствуйте, novitk, Вы писали:
M>>Для таких случаев обычно в каждой уважающей себя среде разработки есть инструментарий для создания таких мастеров, а каждая уважающая себя библиотека, особенно претендующая на звание фреймворка, поставляет свои мастера-визарды для большинства популярных сред разработки.
N>Обычно подобные задачи решаются cmdline скриптами. Визард — это скрипт для специализированной задачи к которому добавили UI. Не совсем понятно зачем тебе UI, так как они обычно нужны только для сложной и/или продолжительной визуализации. Вроде у тебя не этот случай. Для шаблоной генерации файлов во всяких питонах и прочих есть куча удобных библиотек.
UI удобен тем, что не надо писать доки на скрипты — какие параметры задавать, какие значения допустимы и тп, затем, когда хочешь заюзать такой скрипт — доки надо читать, или даже в сорцы питонячьи лазить смотреть. А UI бы избавил бы от всего этого
Здравствуйте, Marty, Вы писали:
M>UI удобен тем, что не надо писать доки на скрипты — какие параметры задавать, какие значения допустимы и тп, затем, когда хочешь заюзать такой скрипт — доки надо читать, или даже в сорцы питонячьи лазить смотреть. А UI бы избавил бы от всего этого
"--help"? если выдача очень большая использовать подкоманды?
Это же и сделать намного быстрей чем UI, да еще и много удобней чем по кнопкам тыкать? Ты с командной строкой не дружишь что-ли?
Здравствуйте, Marty, Вы писали:
M>Ну, вот у нас есть протокол обмена для девайсов, и есть язык, на котором описывается, что и как передается. Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться. Вот тут тоже нужен бы визард
Зачем? Хоть 100500 параметров — запихнули все в файл "super-pupper-config_STM32_mod1234.json" с комментариями по необходимости
Здравствуйте, novitk, Вы писали:
N>"--help"? если выдача очень большая использовать подкоманды? N>Это же и сделать намного быстрей чем UI, да еще и много удобней чем по кнопкам тыкать? Ты с командной строкой не дружишь что-ли?
Он MSVC пришиблен.
M>Ну, у тебя вот какой-то набор скриптов есть, ты что-то запускаешь, какие-то параметры небось задаешь, и тп. Для этого вполне можно графическую морду приделать
Никогда не было желания
M>- удобно, когда не слишком часто такие задачи повторяются — имена параметров/значений забываешь, приходится лазить смотреть в сорцы скриптов.
Ctrl + R == поиск по истории. Если надо, записывается в документ.
M>Опять же, такие скрипты плохо шарятся в команде — каждому надо будет их изучать.
У нас для этого есть Confluence. Даже изучать не надо. Скопипастил — и вперед
M>А допустим, вот мы на плюсиках пишем продуктовый код, а я напишу таких скриптов себе на питоне. А в команде питон никто не знают и нахрен он особо никому не сдался. А так — запустил визард, прокликал что надо, забил параметры и всё, готово
Опять же. Что именно прокликал, что за визард? Неизвестно никому. Повторю. Вот твоя задача:
что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
Что за поля? Неизвестно. Что за файлы генерятся? Неизвестно. Кто это все будет описывать и создавать в этом универсальном всемогуторе? Опять же неизвестно. Как это упростит «шаринг скриптов в команде»?
M>Вот посмотрите — в той же MSMS — визарды проектов в количестве пары-тройки десятков. Для тех же плюсиков — class wizard, qt class wizard. Для других языков не смотрел, но, скорее всего, там свои волшебники есть.
Потому что это фиксированный набор с заранее известными параметрами. Там нет никаких «универсальных визардов».
Здравствуйте, Mamut, Вы писали:
M>У нас для этого есть Confluence. Даже изучать не надо. Скопипастил — и вперед
Ну, у нас тоже вики есть. Не всегда помогает
M>
M>что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
M>Что за поля? Неизвестно. Что за файлы генерятся? Неизвестно. Кто это все будет описывать и создавать в этом универсальном всемогуторе? Опять же неизвестно. Как это упростит «шаринг скриптов в команде»?
Ну, например, какой-нибудь class wizard свой.
1) На первой странице вводим имя класса
2) На второй странице выбираем, какой именно конкретно визард использовать — несколько радиокнопок или список, к примеру. Или дроп даун комбо. В зависимости от выбора задается имя файла (пары .cpp/.h) шаблона.
В зависимости от выбора последующие страницы могут быть разными. Например:
3) Вводим имя класса, от которого наследуем
4) [ ] check-box — "Добавить бла-бла-бла в protected часть класса "
5) Радиовыбор: "При реализации бла-бла-бла: ( ) — Использовать A ... / ( ) — Использовать B ..."
6) Список со множественным выбором: "Подключить опции: Опция 1/Опция 2/Опция 3/Опция 4..."
7) Финальная страничка: показываем что было выбрано (можно и без неё)
После нажатия "Finish" берется пара шаблонов .cpp/.h, в подаем их на вход шаблонизатору вместе с выбранными опциями, и он выплёвывает готовые файлики. Или, можно, например, сконфигурировать так, чтобы какая-то команда запустилась, или еще что-то.
Описываем это всё в каком-нибудь конфиге, например, в каком-то "стандартном XML" (превед Шеридану ) или в джейсоне. Первый многословен, зато всё буль менее самодокументирован, во втором — писать проще, но с валидацией похуже.
Из плюсов — такое описание само будет, как документация — видно, какие есть альтернативы, какие опции при разных альтернативах доступны, и тп. Можно по этому формальному описанию и доку человекочитаемую сгенерить.
Здравствуйте, Marty, Вы писали:
M>Ну, например, какой-нибудь class wizard свой.
Магию в топку. Ты программист или где?
M>1) На первой странице вводим имя класса
Так и пиши в коде: class MyClassName.
M>2) На второй странице выбираем, какой именно конкретно визард использовать — несколько радиокнопок или список, к примеру. Или дроп даун комбо. В зависимости от выбора задается имя файла (пары .cpp/.h) шаблона.
В любом более менее сложном приложении в этом дропдауне будет тысячи элементов.
M>В зависимости от выбора последующие страницы могут быть разными. Например: M>3) Вводим имя класса, от которого наследуем
Добавляем : MyParentClassName.
M>4) [ ] check-box — "Добавить бла-бла-бла в protected часть класса " M>5) Радиовыбор: "При реализации бла-бла-бла: ( ) — Использовать A ... / ( ) — Использовать B ..."
Пишем protected: A blaBla;.
M>6) Список со множественным выбором: "Подключить опции: Опция 1/Опция 2/Опция 3/Опция 4..."
Хз что значит и скорее всего опций будет сотни.
M>7) Финальная страничка: показываем что было выбрано (можно и без неё)
Создаём пулл-реквест и на ревью.
M>После нажатия "Finish" берется пара шаблонов .cpp/.h, в подаем их на вход шаблонизатору вместе с выбранными опциями, и он выплёвывает готовые файлики. Или, можно, например, сконфигурировать так, чтобы какая-то команда запустилась, или еще что-то.
M>Из плюсов — такое описание само будет, как документация — видно, какие есть альтернативы, какие опции при разных альтернативах доступны, и тп. Можно по этому формальному описанию и доку человекочитаемую сгенерить.
Хорошая IDE умеет autocomplete, а с хорошим языком и прдуманным API — умеет контекстно-зависимо, показывая только доступные альтернативы. Да ещё и красненьким подчеркнёт, если что-то не так.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
M>>Ну, например, какой-нибудь class wizard свой. ·>Магию в топку. Ты программист или где?
Ок, я не программист.
Я не пойму, что ты мне доказать-то хочешь?
И при чем тут хорошая IDE, это только пример был для плюсиков, а в реале, допустим, надо сформировать командную строку для вызова какой-нибудь тулзы, или это какой-то шаблон кода на lua или сквиреле каком.
Здравствуйте, Marty, Вы писали:
M>Ну, например, какой-нибудь class wizard свой. M>1) На первой странице вводим имя ...
Да поняли мы что ты хочешь. Тебя спрашивают нафига тратить время на GUI? У MS уже есть VS и им имеет какой-то смысл это туда пихать, но тебе то нафига лишние сущности?
Документации не аргумент, так как гораздо проще ее добавить в "--help" или wiki.
M>>Ну, например, какой-нибудь class wizard свой. M>>1) На первой странице вводим имя ...
N>Да поняли мы что ты хочешь. Тебя спрашивают нафига тратить время на GUI? У MS уже есть VS и им имеет какой-то смысл это туда пихать, но тебе то нафига лишние сущности?
На гуй тратить время обычно не стоит, я консольку люблю и все тулзы у меня консольные, ибо городить какой-то спец гуй действительно лишняя трата времени, просто...
N>Документации не аргумент, так как гораздо проще ее добавить в "--help" или wiki.
Ну, например, одна самописная простенька тулза по --help выдает 250 строчек, другая 700. И это чисто краткая подсказка. Дока на вторую тулзу — порядка 60 страниц. В баш добалена поддержка автокомплита, но этого не хватает.
Хочется за полчасика, ну, может за час описать в каком-то формальном текстовом виде все основные юз-кейсы, и скормить его какой-то проге, которая по шагам позволит выбрать настройки так, как нужно для моего конкретного случая.
Здравствуйте, ·, Вы писали:
M>>>>Ну, например, какой-нибудь class wizard свой. M>>·>Магию в топку. Ты программист или где? M>>Ок, я не программист. ·>Тогда найми программиста, чтобы он тебе на ангуляре сваял визарда.
M>>Я не пойму, что ты мне доказать-то хочешь? ·>Что программистам гуй не нужен.
M>>И при чем тут хорошая IDE, это только пример был для плюсиков, а в реале, допустим, надо сформировать командную строку для вызова какой-нибудь тулзы, или это ·>Программист напишет код, хоть там одноразовый bash-скриптик. Непрограммисту командные строки c lua не нужны.
Здравствуйте, Marty, Вы писали:
N>>Документации не аргумент, так как гораздо проще ее добавить в "--help" или wiki. M>Ну, например, одна самописная простенька тулза по --help выдает 250 строчек, другая 700. И это чисто краткая подсказка. Дока на вторую тулзу — порядка 60 страниц. В баш добалена поддержка автокомплита, но этого не хватает. M>Хочется за полчасика, ну, может за час описать в каком-то формальном текстовом виде все основные юз-кейсы, и скормить его какой-то проге, которая по шагам позволит выбрать настройки так, как нужно для моего конкретного случая. Это как раз про то что ты говоришь:
To make a complex subsystem easier to use, a simple interface should be provided for a set of interfaces in the subsystem.
Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?..
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Marty, Вы писали:
M>·>Это как раз про то что ты говоришь: M>·>
To make a complex subsystem easier to use, a simple interface should be provided for a set of interfaces in the subsystem.
M>·>Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?.. M>А чем консоль лучше, чем гуй?
Лучше для чего/кого? Interface бывает трёх типов: API, CLI и GUI. Программистам удобнее первое, сисадминам второе, пользователям третье.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
M>>·>Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?.. M>>А чем консоль лучше, чем гуй? ·>Лучше для чего/кого? Interface бывает трёх типов: API, CLI и GUI. Программистам удобнее первое, сисадминам второе, пользователям третье.
Здравствуйте, Marty, Вы писали:
M>>>·>Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?.. M>>>А чем консоль лучше, чем гуй? M>·>Лучше для чего/кого? Interface бывает трёх типов: API, CLI и GUI. Программистам удобнее первое, сисадминам второе, пользователям третье.
M>И? Ты сейчас это в lynx'е ответ писал?
Программист это не расовая принадлежность, а роль. Этот ответ не код, а значит я писал его не как программист, а пользователь, поэтому использовал GUI.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
M>>>>·>Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?.. M>>>>А чем консоль лучше, чем гуй? M>>·>Лучше для чего/кого? Interface бывает трёх типов: API, CLI и GUI. Программистам удобнее первое, сисадминам второе, пользователям третье.
M>>И? Ты сейчас это в lynx'е ответ писал? ·>Программист это не расовая принадлежность, а роль. Этот ответ не код, а значит я писал его не как программист, а пользователь, поэтому использовал GUI.
Здравствуйте, Marty, Вы писали:
M>>>И? Ты сейчас это в lynx'е ответ писал? M>·>Программист это не расовая принадлежность, а роль. Этот ответ не код, а значит я писал его не как программист, а пользователь, поэтому использовал GUI. M>vi/emacs и gdb — наше ффсё?
vi/emacs это не cli. Дебаггер это когда не хватает опыта и написанным кодом (ака тестами) не получается обойтись. Впрочем, это всё очень далеко от сабжа.
А ещё ты путаешь редактирование и генерацию кода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
M>>>>И? Ты сейчас это в lynx'е ответ писал? M>>·>Программист это не расовая принадлежность, а роль. Этот ответ не код, а значит я писал его не как программист, а пользователь, поэтому использовал GUI. M>>vi/emacs и gdb — наше ффсё? ·>vi/emacs это не cli.
Не cli, да.
Гуй, наверное
·>Дебаггер это когда не хватает опыта и написанным кодом (ака тестами) не получается обойтись. Впрочем, это всё очень далеко от сабжа. ·>А ещё ты путаешь редактирование и генерацию кода.
А ты путаешь конструктивный диалог с тупым флеймом ради флейма
M>Описываем это всё в каком-нибудь конфиге, например, в каком-то "стандартном XML" (превед Шеридану ) или в джейсоне. Первый многословен, зато всё буль менее самодокументирован, во втором — писать проще, но с валидацией похуже.
Ага-ага. «Все будет задокументировано», как же.
M>Из плюсов — такое описание само будет, как документация — видно, какие есть альтернативы, какие опции при разных альтернативах доступны, и тп. Можно по этому формальному описанию и доку человекочитаемую сгенерить.
С какого перепугу это описание будет, как документация?
Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться.
От того, что ты эту сотню параметров закинешь в XML, оно станет более понятным? Или описание того, что эти параметры делают, появится магическим образом из воздуха?
Кто будет эти XMLи писать? Чем они отличаются от скриптов, в которых надо разбираться? Ты заменишь «питон, который никто не знает» кривой конфигурацией, которую так же никто не знает. Потому что это будет не конфигурация, а DSL. Кто будет писать весь функционал и логику для вот этого:
— После нажатия "Finish" берется пара шаблонов .cpp/.h, в подаем их на вход шаблонизатору вместе с выбранными опциями
— Сконфигурировать так, чтобы какая-то команда запустилась, или еще что-то.
Вся эта логика магическми образом будет реализована, ага, и магическми образом самодокументируется, ага.
Вместо того, чтобы сесть:
— и написать документацию к сущесвтующим тулзам
— написать tool help и tool help option
— хотя бы просто вписать в скрипт в начало файла большой комментарий, как этим пользоваться
— вынести всю эту ненужную трахотню с отдельным запуском каких-то скриптов в настройки проекта, условные куски кода, генерацию в процессе сборки.
Здравствуйте, Mamut, Вы писали: M>>Из плюсов — такое описание само будет, как документация — видно, какие есть альтернативы, какие опции при разных альтернативах доступны, и тп. Можно по этому формальному описанию и доку человекочитаемую сгенерить. M>С какого перепугу это описание будет, как документация?
Визард, помимо всего прочего, подразумевает внятное предложение или абзац, в котором раскрывается, что предлагается выбрать на данной странице.
Каждое возможное значение чего-либо тоже обладает описанием
M>
M>Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться.
M>От того, что ты эту сотню параметров закинешь в XML, оно станет более понятным? Или описание того, что эти параметры делают, появится магическим образом из воздуха?
Не магическим, а из описания страницы. Из того описания, которое будет отображаться пользователю визарда
M>Кто будет эти XMLи писать? Чем они отличаются от скриптов, в которых надо разбираться? Ты заменишь «питон, который никто не знает» кривой конфигурацией, которую так же никто не знает. Потому что это будет не конфигурация, а DSL.
Писать будет тот, кому больше всех это надо
Вот я напилил несколько тулз, запилил статей в вики, чтобы коллегам было понятно, что к чему, но всё равно не очень — всем проще меня спросить чо как, а я в ответ уже просто ссылку на конкретный раздел доки скидываю. Мне бы проще было один раз напилить визардов, и чтобы меня никто не трогал
M>Кто будет писать весь функционал и логику для вот этого: M>- После нажатия "Finish" берется пара шаблонов .cpp/.h, в подаем их на вход шаблонизатору вместе с выбранными опциями M>- Сконфигурировать так, чтобы какая-то команда запустилась, или еще что-то.
Опять же — тот, кому больше всех надо
Вот у меня такая рутина появилась, раз, другой руцами сделал. Вижу, что часто повторяется, запилил конфиг для визарда, в следующий раз и себе меньше работы, и расшарить практику на тим легко
M>Вся эта логика магическми образом будет реализована, ага, и магическми образом самодокументируется, ага.
Не магическим образом, а интерпретатором. Который на входе берет DSL, ага, и показывает нужные странички в нужном порядке, а потом вызывает шаблонизатор или еще что-то.
M>Вместо того, чтобы сесть: M>- и написать документацию к сущесвтующим тулзам
Документация написана. На некоторые тулзы у меня мануалы на не один десяток страниц написан.
M>- написать tool help и tool help option
--help — выдает обычно 200+ строк, в пике сейчас 700 строк просто перечисления опций.
Каждая тулза абсолютно автономна (не требует какой-либо установки) и умеет сама прописывать в баш правила автокомплита, а для CMD — я нагуглил некий CLINK, который умеет примерно в тоже самое. Это помогает, но только когда сам уже хорошо понимаешь, что тулза умеет, и что ты хочешь от неё. M>- хотя бы просто вписать в скрипт в начало файла большой комментарий, как этим пользоваться
Большой коментарий — это ссылка на вики, где лежит дока
M>- вынести всю эту ненужную трахотню с отдельным запуском каких-то скриптов в настройки проекта, условные куски кода, генерацию в процессе сборки.
Трахотня вынесена в батники, которые запускаются перед сборкой проекта. Но, чтобы написать эти батники, нужно покурить доку и правильно настроить вызов соответствующих тулз.
Пример конфига такого визарда-всемогутора (всё чисто гипотетическое, чисто для теста):
Скрытый текст
{
"wizard" :
{
"dummy-first":"",
"geometry":"AUTO",
"title":"Wizardry Test",
"icon":"pw.ico",
"banner":"",
"logo":"pw-logo.png",
"image":"pw-img.png",
"style":"classic",
"generate-guids":5,
"template":"$template-file",
"template-buddies":"+.app,.rep",
"output" :"$output-file",
"output-buddies":"+.app,.rep",
"force-single-line":0,
"show-completion-message":"Job done",
"dummy-last":""
},
"values":
{
"radio-choise-1":
{
"title":"Radio button 1",
"description":"Description of radiobutton #1"
},
"radio-choise-2":
{
"title":"Radio button 2",
"description":"Description of radiobutton #2"
},
"radio-choise-3":
{
"title":"Radio button 3",
"description":"Description of radiobutton #3"
},
"welcome":
{
"title":"Welcome",
"description":"Loop to welcome page"
},
"dropdown-val-1": {
"title": "Dropval One",
"long-title": "This is the dropval one value",
"description": "Description not required if used only in dropdowns"
},
"dropdown-val-2":
{
"title":"The Second Dropval",
"description":"Description not required if used only in dropdowns"
},
"dropdown-optional-val-1":
{
"title":"First value",
"long-title":"This is the First",
"description":"Description for the first value"
},
"dropdown-optional-val-2":
{
"title":"Second value",
"description":"Second value description"
},
"edit-val-1":
{
"title":"Edit control test 1",
"description":"Edit control test 1 description"
},
"edit-val-2":
{
"title":"Edit control test 2",
"description":"Edit control test 2 description"
},
"edit-val-3":
{
"title":"Edit control test 3",
"description":"Edit control test 3 description"
},
"edit-val-phone-1":
{
"title":"Phone number #1"
},
"edit-val-phone-2":
{
"title":"Phone number #2"
},
"edit-val-phone-3":
{
"title":"Phone number #3"
},
"password1":
{
"title":"Password"
},
"password2":
{
"title":"Password"
},
"password3":
{
"title":"Password"
},
"input-file":
{
"title":"Input file"
},
"output-file":
{
"title":"Output file"
},
"template-file":
{
"title":"Template file"
}
},
"pages" :
{
"welcome":
{
"page-type":"welcome",
"title":"Welcome!",
"subtitle":"Welcome to the Wizardry Test wizard",
"description":"This wizard helps your to go through the rest of all Wizardry Test and sample pages",
"next-page":"fileselection-test",
"dummy-last":""
},
"fileselection-test":
{
"page-type":"fileselections",
"title":"Wizard File Selection",
"subtitle":"File Selection controls test",
"description":"Select files into each field",
"next-page":"edit-test",
"controls-width":"/2",
"fileselections":
[
{ "target-var":"input-file",
"default":"test.txt",
"options":"open-existing,readonly-edit,native",
"filters":"Text files - *.txt; Ini Files - *.ini; All files - *"
},
{ "target-var":"output-file",
"options":"save-dialog,not-native",
"filters":"Text files - *.txt; *.cpp *.cxx *.c; *.hpp *.hxx; Template files - *.tpl; All files - *"
},
{ "target-var":"template-file",
"options":"open-existing",
"filters":"Text files - *.txt; Template files - *.tpl; All files - *"
}
],
"dummy-last":""
},
"edit-test":
{
"page-type":"editfields",
"title":"Wizard Edit Test",
"subtitle":"Edit controls test",
"description":"Enter value into each edit control",
"next-page":"listsinglesel-test",
"controls-width":"/2",
"editfields":
[
{ "title":"Edit 1",
"target-var":"edit-val-1",
"target-var-title":"Overrided target value title",
"default":"Text1"
},
{
"target-var":"edit-val-2",
"input-mask":""
},
{ "title":"Edit 3",
"target-var":"edit-val-3"
},
{ "target-var":"edit-val-phone-1",
"default":"+1 (123) 456-78-90"
},
{ "target-var":"edit-val-phone-2",
"placeholder":"+1 (123) 456-78-90"
},
{ "target-var":"edit-val-phone-3",
"placeholder":"+1 (123) 456-78-90",
"mask":"+D (DDD) DDD-DD-DD;X"
},
{ "title":"Mode - password-echo",
"target-var":"password1",
"mode":"password-echo"
},
{ "title":"Mode - password",
"target-var":"password2",
"mode":"password"
},
{ "title":"Mode - silent",
"target-var":"password3",
"mode":"silent"
}
],
"dummy-last":""
},
"listsinglesel-test":
{
"page-type":"listsinglesel",
"title":"Wizard Single Selection List Test",
"subtitle":"Single Selection List selection and flow control choice test",
"description":"Single Selection List one of items in the list",
"next-page":"dropdowns-test",
"target-var":"listsinglesel-test",
"target-var-title":"Single Selection List test",
"list-choice":
[
{ "value":"radio-choise-1", "setwo":[ {"buddies":".def"} ] },
{ "value":"radio-choise-2", "appwo":[ {"buddies":".bla"} ] },
{ "value":"radio-choise-3" },
{ "value":"dropdown-val-1" },
{ "value":"dropdown-val-2" },
{ "value":"dropdown-optional-val-1" },
{ "value":"optional-dropdowns", "next-page":"optional-dropdowns", "text":"Go to optional dropdown test" },
{ "value":"summary", "next-page":"summary", "text":"Go to summary (skip all other pages)" }
],
"dummy-last":""
},
"dropdowns-test":
{
"page-type":"dropdowns",
"title":"Wizard Dropdown Comboboxes Test",
"subtitle":"Select value in dropdown list test",
"description":"Select value in each dropdown",
"next-page":"radiobuttons-test",
"controls-width":"/3",
"dropdowns":
[
{ "title":"Dropdown 1",
"target-var":"dropdown1-res",
"target-var-title":"Dropdown 1",
"add-values-long-title":1,
"values":
[
{ "value":"radio-choise-1" },
{ "value":"radio-choise-2", "default":1 },
{ "value":"radio-choise-3" }
]
},
{ "title":"Dropdown 2",
"target-var":"dropdown2-res",
"use-values-long-title":1,
"values":
[
{ "value":"dropdown-val-1" },
{ "value":"dropdown-val-2", "default":1 }
]
},
{ "title":"Dropdown 3 - same as Dropdown 2, but without default value",
"target-var":"dropdown3-res",
"values":
[
{ "value":"dropdown-val-1" },
{ "value":"dropdown-val-2" }
]
}
],
"dummy-last":""
},
"radiobuttons-test":
{
"page-type":"radio-choice",
"title":"Wizard Radiobuttons Test",
"subtitle":"Radiobuttons value selection and flow control choice test",
"description":"Select one of three first items or choose last one to go directly to summary final page",
"next-page":"test-page3",
"target-var":"radiobuttons-test",
"target-var-title":"Radiobuttons test",
"default-choice":"radio-choise-3",
"radio-choice":
[
{ "value":"radio-choise-1" },
{ "value":"radio-choise-2", "default":1 },
{ "value":"radio-choise-3" },
{ "value":"optional-dropdowns", "next-page":"optional-dropdowns", "text":"Go to optional dropdown test" },
{ "value":"summary", "next-page":"summary", "text":"Go to summary (skip all other pages)" }
],
"dummy-last":""
},
"optional-dropdowns":
{
"page-type":"dropdowns",
"title":"Wizard Optional Dropdown Combobox Test",
"subtitle":"Select value in taken dropdown list",
"next-page":"test-page3",
"controls-width":"/3",
"dropdowns":
[
{ "title":"Select value",
"target-var":"optional-dropdown-res",
"target-var-title":"Optional Dropdown Value",
"values":
[
{ "value":"dropdown-optional-val-1" },
{ "value":"dropdown-optional-val-2" }
]
}
],
"dummy-last":""
},
"test-page3":
{
"page-type":"info",
"title":"Test Page number three",
"subtitle":"Test Page number three subtitle",
"description":"This is a simple page number 3",
"next-page":"summary",
"dummy-last":""
},
"summary":
{
"title":"Wizardry Test Summary",
"page-type":"summary",
"subtitle":"Please check the options collected during walking through the wizard",
"dummy-last":""
}
}
}
Здравствуйте, Marty, Вы писали:
M> Здравствуйте!
M>Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
Я бы шаблонизатор прикрутил. Например ту-же j2cli, у ней унутрях привычная jinja2.
Шаблон:
server {
listen 80;
server_name {{ nginx.hostname }};
root {{ nginx.webroot }};
index index.htm;
}
Здравствуйте, Marty, Вы писали:
M>А чем консоль лучше, чем гуй?
интеграцией с другими программами (my_tool_1 | my_tool_2)
возможностью поиска (my_tool --help | grep "do all the good")
простотой (в GUI "найдите кнопку 'ФЫВА'", в CLI — "наберите 'ФЫВА'", над вторым вариантом думать вообще не надо).
Re[3]: Универсальный визард (мастер) - зачем таки нужно
Здравствуйте, Mamut, Вы писали:
M>Потому что это фиксированный набор с заранее известными параметрами. Там нет никаких «универсальных визардов».
ЕМНИП в QtCreator именно универсальный визард для новых проектов, возможные параметры, на основе которых генерится GUI, хранятся где-то в текстовом виде.
M>>С какого перепугу это описание будет, как документация?
M>Визард, помимо всего прочего, подразумевает внятное предложение или абзац, в котором раскрывается, что предлагается выбрать на данной странице. M>Каждое возможное значение чего-либо тоже обладает описанием
и тут же
M> Документация написана. На некоторые тулзы у меня мануалы на не один десяток страниц написан.
Но в визарде эта доукментация ВНЕЗАПНО станет короткой и всем понятной, ага.
M>Писать будет тот, кому больше всех это надо M>Не магическим образом, а интерпретатором. M>Пример конфига такого визарда-всемогутора (всё чисто гипотетическое, чисто для теста):
То есть точно так же, как сейчас скрипты Ты жалуешься, что народ не понимает, что в питоновых скриптах написано. А вот в твоем мега-XML'е/мега-JSON'е с каким-то магическим интерпретатором (который тоже видимо магическим образом появляется и не требует ни документации ни сопровождения — ничего) все автоматом сразу разбираются и радостно пишут на нем визарды
M>Вот я напилил несколько тулз, запилил статей в вики, чтобы коллегам было понятно, что к чему, но всё равно не очень — всем проще меня спросить чо как, а я в ответ уже просто ссылку на конкретный раздел доки скидываю. Мне бы проще было один раз напилить визардов, и чтобы меня никто не трогал
Ага. В визарде будет 100 параметров с 10 страницами документации, но тебя никто не будет спрашивать, ага.
M>Вот у меня такая рутина появилась, раз, другой руцами сделал. Вижу, что часто повторяется, запилил конфиг для визарда, в следующий раз и себе меньше работы, и расшарить практику на тим легко
Л — логика:
— скрипты на питоне никто не понимает, документацию на 10 страниц не читают, расшаривать с командой сложно
— визард на неизвестном никому DSL'е на неизвестном никому интерпретаторе это хорошо, все понимают, 10 страниц документации в визарже все будут читать, расшаривать визард с командой — легко
M>--help — выдает обычно 200+ строк, в пике сейчас 700 строк просто перечисления опций.
Ну у тебя будет 700 строк опций в визарде. Стало сильно легче?
M>>- вынести всю эту ненужную трахотню с отдельным запуском каких-то скриптов в настройки проекта, условные куски кода, генерацию в процессе сборки.
M>Трахотня вынесена в батники, которые запускаются перед сборкой проекта. Но, чтобы написать эти батники, нужно покурить доку и правильно настроить вызов соответствующих тулз.
Раз это делает несколько раз, постоянно, то вот эти несколько раз вписываются в батники.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Marty, Вы писали:
M>> Здравствуйте!
M>>Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
S>Я бы шаблонизатор прикрутил. Например ту-же j2cli, у ней унутрях привычная jinja2.
У меня пайтоновский mako
Но это не снимает вопроса способе задания аргументов
Здравствуйте, Skorodum, Вы писали:
S>>>Он MSVC пришиблен. M>>Я тебя так сильно чем-то обидел? S>Извини, я резко высказался. Мир-дружба-жевачка.
Ок
S>Я хотел сказать, что с моей точки зрения, студия прививает неправильную культуру управления проектами. При всей уродливости языка идеалогически подход типа CMake правильнее.
У тебя сложилось несколько превратное впечатление. Я конечно люблю студию, и под винду пишу под ней, но вообще не чужд и работе в консольке по ssh, а сейчас отлаживаюсь на железках через COM-порт.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Marty, Вы писали:
M>>А чем консоль лучше, чем гуй? S>интеграцией с другими программами (my_tool_1 | my_tool_2)
Консоль уже есть, если говорить о тулзах. И её возможности перестали устраивать
S>возможностью поиска (my_tool --help | grep "do all the good")
Это неудобно. Проще зайти в нашу вики и на нужной странице сделать Ctrl+F. Тоже так себе
S>простотой (в GUI "найдите кнопку 'ФЫВА'", в CLI — "наберите 'ФЫВА'", над вторым вариантом думать вообще не надо).
Если визард шаг за шагом спрашивает один-два параметра, чего тут искать? Сиди выбирай чего просят
Здравствуйте, Marty, Вы писали:
M>У меня пайтоновский mako
M>Но это не снимает вопроса способе задания аргументов
А у питона нет автокомплита?
Скажем, в повершелле как раз это всё решено очень даже неплохо. Всяко лучше, чем в самопальном GUI-визарде.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>и тут же
M>> Документация написана. На некоторые тулзы у меня мануалы на не один десяток страниц написан.
M>Но в визарде эта доукментация ВНЕЗАПНО станет короткой и всем понятной, ага.
В документации есть минус — не понятно, с какого конца копать. Её целиком никто не читает, и обо всех возможностях тулз мало кто знает, кроме авторов. В визарде может и не так детально будет, зато будет выводится только та инфа, которая нужна на конкретном шаге, чтобы произвести выбор. Это большой плюс.
M>>Писать будет тот, кому больше всех это надо M>>Не магическим образом, а интерпретатором. M>>Пример конфига такого визарда-всемогутора (всё чисто гипотетическое, чисто для теста):
M>То есть точно так же, как сейчас скрипты Ты жалуешься, что народ не понимает, что в питоновых скриптах написано. А вот в твоем мега-XML'е/мега-JSON'е с каким-то магическим интерпретатором (который тоже видимо магическим образом появляется и не требует ни документации ни сопровождения — ничего) все автоматом сразу разбираются и радостно пишут на нем визарды
Ну, для начала будет достаточно мне самому напилить визардов, чтоб другие пользовались, главный автоматизатор в основном я пока, хотя народ начал проникаться
M>>Вот я напилил несколько тулз, запилил статей в вики, чтобы коллегам было понятно, что к чему, но всё равно не очень — всем проще меня спросить чо как, а я в ответ уже просто ссылку на конкретный раздел доки скидываю. Мне бы проще было один раз напилить визардов, и чтобы меня никто не трогал
M>Ага. В визарде будет 100 параметров с 10 страницами документации, но тебя никто не будет спрашивать, ага.
Обычно меня спрашивают: "а есть такая фича", "а можно такое-то сгенерить" — на что я отвечаю ссылкой на раздел доки. В визарде все фичи и опции будут явно выдаваться
M>>Вот у меня такая рутина появилась, раз, другой руцами сделал. Вижу, что часто повторяется, запилил конфиг для визарда, в следующий раз и себе меньше работы, и расшарить практику на тим легко
M>Л — логика:
M>- скрипты на питоне никто не понимает, документацию на 10 страниц не читают, расшаривать с командой сложно M>- визард на неизвестном никому DSL'е на неизвестном никому интерпретаторе это хорошо, все понимают, 10 страниц документации в визарже все будут читать, расшаривать визард с командой — легко
В DSL смотрит только автор визарда, все остальные смотрят только на то, что визард показывает, нажимают на кнопочки и заполняют то, что визард просит. По-моему удобно. И прекрасно шарится
M>
M>>--help — выдает обычно 200+ строк, в пике сейчас 700 строк просто перечисления опций.
M>Ну у тебя будет 700 строк опций в визарде. Стало сильно легче?
Нет, не будет. Будет десяток страниц с простыми вопросами
M>>>- вынести всю эту ненужную трахотню с отдельным запуском каких-то скриптов в настройки проекта, условные куски кода, генерацию в процессе сборки.
M>>Трахотня вынесена в батники, которые запускаются перед сборкой проекта. Но, чтобы написать эти батники, нужно покурить доку и правильно настроить вызов соответствующих тулз.
M>Раз это делает несколько раз, постоянно, то вот эти несколько раз вписываются в батники.
Только параметры каждый раз могут быть разными, а так да, когда можно, выносится в батники
Здравствуйте, Marty, Вы писали:
M>У тебя сложилось несколько превратное впечатление. Я конечно люблю студию, и под винду пишу под ней, но вообще не чужд и работе в консольке по ssh, а сейчас отлаживаюсь на железках через COM-порт.
Кстати я сейчас тоже Segger/QtCreator/Atmel/IAR/FDK, но я больше интеграцией разных модулей занимаюсь и DevOps, всего понемногу: от железок до облаков и мобилок.
Вот прям сейчас простой пример с MQTT не хочет в амазоновское облако писать через мобилку
Я ничего не имею против Студии в качестве редактора и отладчика, но я категорически против студийных солюшенов: т.к. это вендор лок и у них ужасный формат.
Здравствуйте, Sinclair, Вы писали:
M>>У меня пайтоновский mako
M>>Но это не снимает вопроса способе задания аргументов S>А у питона нет автокомплита? S>Скажем, в повершелле как раз это всё решено очень даже неплохо. Всяко лучше, чем в самопальном GUI-визарде.
Это как? Вот у меня есть опция, где-то в коде она проверяется, что равна одному из пяти-десяти фикс значений, и что, такой автокомплит бывает?
Или, например, сам шаблон задается в ходе выбора в визарде, и последующие возможные переменные зависят от того, какой шаблон выбран. Как вот это всё нормально в консольке организовать?
Здравствуйте, Skorodum, Вы писали:
S>Я ничего не имею против Студии в качестве редактора и отладчика, но я категорически против студийных солюшенов: т.к. это вендор лок и у них ужасный формат.
Ну, формат-то норм — я тока ручками туда и лазаю.
А вендор-лок — это да, есть такой вопрос.
Кстати, я в этом топике именно этот вопрос и поднимаю — условно говоря можно напилить визардов под студию, и пользоваться ими, но не хочется привязываться к студии
M>>Но в визарде эта доукментация ВНЕЗАПНО станет короткой и всем понятной, ага.
M>В документации есть минус — не понятно, с какого конца копать. Её целиком никто не читает, и обо всех возможностях тулз мало кто знает, кроме авторов. В визарде может и не так детально будет, зато будет выводится только та инфа, которая нужна на конкретном шаге, чтобы произвести выбор. Это большой плюс.
И тут же
M> [В визардже] Будет десяток страниц с простыми вопросами
Сделай то же самое в документации
M>Ну, для начала будет достаточно мне самому напилить визардов, чтоб другие пользовались, главный автоматизатор в основном я пока, хотя народ начал проникаться M>В DSL смотрит только автор визарда, все остальные смотрят только на то, что визард показывает, нажимают на кнопочки и заполняют то, что визард просит. По-моему удобно. И прекрасно шарится
Это называется job security. Взять тулзу, которая никому неизвестна, делать на ней никому непонятную неведомую хрень и подавать это под соусом «хорошо шарится, всем удобно». Потом, правда, окажется, что интерпретатор и DSL надо развивать, поддерживать, документировать, что это все говно работает только на определенных версиях определенных систем и библиотек и т.д. и т.п.
Вместо того, чтобы избавится от тулзов со 100 опциями и 10 страницами документации.
Здравствуйте, Skorodum, Вы писали:
M>>Потому что это фиксированный набор с заранее известными параметрами. Там нет никаких «универсальных визардов». S>ЕМНИП в QtCreator именно универсальный визард для новых проектов, возможные параметры, на основе которых генерится GUI, хранятся где-то в текстовом виде.
Это опять вендор-лок. Так-то в итоге "параметры, на основе которых генерится GUI", у всех хранятся где-то в каком-то текстовом виде
Здравствуйте, Mamut, Вы писали:
M>И тут же
M>> [В визардже] Будет десяток страниц с простыми вопросами
M>Сделай то же самое в документации
Еще 100 страниц документации написать? Так себе идея
M>>Ну, для начала будет достаточно мне самому напилить визардов, чтоб другие пользовались, главный автоматизатор в основном я пока, хотя народ начал проникаться M>>В DSL смотрит только автор визарда, все остальные смотрят только на то, что визард показывает, нажимают на кнопочки и заполняют то, что визард просит. По-моему удобно. И прекрасно шарится
M>Это называется job security. Взять тулзу, которая никому неизвестна, делать на ней никому непонятную неведомую хрень и подавать это под соусом «хорошо шарится, всем удобно». Потом, правда, окажется, что интерпретатор и DSL надо развивать, поддерживать, документировать, что это все говно работает только на определенных версиях определенных систем и библиотек и т.д. и т.п.
M>Вместо того, чтобы избавится от тулзов со 100 опциями и 10 страницами документации.
Ну, можно писать ручками всё, что тулзы генерят, но зачем?
В команде, в общем-то, весьма довольны тулзами. Которые работают везде и всегда. Если у вас пишут так, что версии библиотек и систем прибиты гвоздями, то это у вас какая-то проблема
В общем-то, мне с начала показалось, что диалог пошел конструктивный, но теперь я вижу, что ты, как и некоторые другие в данном топике, просто хочешь убедить меня в своей точке зрения, что никакой визард не нужен и все решается батниками и тп.
Я вас услышал, но не считаю вас правыми, так все предлагаемые способы уже опробованы и не кажутся мне удобными
M>>> [В визардже] Будет десяток страниц с простыми вопросами
M>>Сделай то же самое в документации
M>Еще 100 страниц документации написать? Так себе идея
То есть документацию в стиле «вопрос-ответ» ты писать не собираешься, но в визарде ты ее обязательно напишешь. Ага, как же.
M>>Вместо того, чтобы избавится от тулзов со 100 опциями и 10 страницами документации. M>Ну, можно писать ручками всё, что тулзы генерят, но зачем?
Где ты увидел требование писать что-то ручками?
M>В команде, в общем-то, весьма довольны тулзами. Которые работают везде и всегда. Если у вас пишут так, что версии библиотек и систем прибиты гвоздями, то это у вас какая-то проблема
Где ты увидел хоть что-то про пррибитие чего-либо гвоздями куда-либо?
M>В общем-то, мне с начала показалось, что диалог пошел конструктивный, но теперь я вижу, что ты, как и некоторые другие в данном топике, просто хочешь убедить меня в своей точке зрения, что никакой визард не нужен и все решается батниками и тп. M>Я вас услышал, но не считаю вас правыми, так все предлагаемые способы уже опробованы и не кажутся мне удобными
Нет. Все способы не опробованы, что явно следует из твоих слов. Ты же уверен, что где-то есть серебрянная пуля, которая магическим способ будет понятна, магическим способ будет работать везде и всегда, магическим способом избавляет тебя от написания понятной и простой пошаговой документации, которая магическим способом не будет требовать поддержки, развития, магическим способом будет понятна всем и т.п.
На все замечания, что это не так, ты отвечаешь в духе «все будет зашибись, это вы ничего не понимаете».
M>>>Потому что это фиксированный набор с заранее известными параметрами. Там нет никаких «универсальных визардов». S>>ЕМНИП в QtCreator именно универсальный визард для новых проектов, возможные параметры, на основе которых генерится GUI, хранятся где-то в текстовом виде.
M>Это опять вендор-лок. Так-то в итоге "параметры, на основе которых генерится GUI", у всех хранятся где-то в каком-то текстовом виде
А магический интерпретатор магического DSLя для магического всемогущего визарда не будет вендор-локом, естественно. Он магическим образом возникнет из неоткуда и сразу решит все твои проблемы.
Здравствуйте, Marty, Вы писали:
M> Здравствуйте!
M>Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
Здравствуйте, Marty, Вы писали:
M>ЗЫ Хотел сначала в "Средства разработки" закинуть, но, наверно, тема больше для холивара
А чего не сделать его в виде опроса на каком-нибудь популярном движке опросов типа Google Forms?
Результаты скидываются в спредшит; дальше запускаете свой скрипт, который интерпретирует эти ответы в нужном вам виде и порождает хоть чёрта лысого.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
M>>ЗЫ Хотел сначала в "Средства разработки" закинуть, но, наверно, тема больше для холивара S>А чего не сделать его в виде опроса на каком-нибудь популярном движке опросов типа Google Forms? S>Результаты скидываются в спредшит; дальше запускаете свой скрипт, который интерпретирует эти ответы в нужном вам виде и порождает хоть чёрта лысого.
Здравствуйте, Sinclair, Вы писали:
S>>>Скажем, в повершелле как раз это всё решено очень даже неплохо. Всяко лучше, чем в самопальном GUI-визарде.
M>>Это как? Вот у меня есть опция, где-то в коде она проверяется, что равна одному из пяти-десяти фикс значений, и что, такой автокомплит бывает? S>Конечно. ValidateSet.
M>>Или, например, сам шаблон задается в ходе выбора в визарде, и последующие возможные переменные зависят от того, какой шаблон выбран. Как вот это всё нормально в консольке организовать? S>Да, такое тоже возможно. Parameter Sets.
S>https://adamtheautomator.com/the-powershell-parameter/
Ну, в принципе, довольно интересно. Но всё же не понятно, чем консолька лучше гуя?
Можно ли там выбор из списка организовать? Множественный выбор из списка, и тп?
Откат на пару шагов назад с выбором новых значений и переходом по другой ветке?
Здравствуйте, Marty, Вы писали:
M>Но это не снимает вопроса способе задания аргументов
Всмысле? я ж явно показал — json.
Или, если мимо автоматизирующей сборку тулзы, то в environment запихнуть можно. Примеры по ссылке смотрел?
Здравствуйте, Marty, Вы писали:
M>Но всё же не понятно, чем консолька лучше гуя?
Чуть более, чем всем. Гуй не атоматизируешь так же просто, как и консоль.
M>Можно ли там выбор из списка организовать? Множественный выбор из списка, и тп? M>Откат на пару шагов назад с выбором новых значений и переходом по другой ветке?
Ну так можно и dialog пользовать, ежели так нужен интерфейс
Здравствуйте, Sheridan, Вы писали:
M>>Но это не снимает вопроса способе задания аргументов S>Всмысле? я ж явно показал — json. S>Или, если мимо автоматизирующей сборку тулзы, то в environment запихнуть можно. Примеры по ссылке смотрел?
Здравствуйте, Sheridan, Вы писали:
M>>Можно ли там выбор из списка организовать? Множественный выбор из списка, и тп? M>>Откат на пару шагов назад с выбором новых значений и переходом по другой ветке? S>Ну так можно и dialog пользовать, ежели так нужен интерфейс S>Image: adventure_dialog-radiolist.png
Здравствуйте, Marty, Вы писали:
M>Консолька тут явно лишняя, не?
Интерфейс явно лишний.
Дело в том, что с ростом сложности шаблона будет расти и сложность интерфейса, причём сложность интерфейса будет расти сильно быстрее. Например, понадобился тебе именованный список именованных списков и приехали, в интерфейсе забодаешься реализовывать.
При отсутствии же интерфейса, если описывать параметры в json, то сложность json файлика никогда не превысит сложность шаблона, тебе не надо будет думать о реализации интерфейса, т.е. не надо будет отвлекатьсь на второстепенные сущности.
Ну и, наконец, при таком подходе, при необходимости, эта генерация может быть совершенно легко автоматизируема.
Здравствуйте, Marty, Вы писали:
M>Ну, в принципе, довольно интересно. Но всё же не понятно, чем консолька лучше гуя?
В основном — тем, что у неё есть кривая обучения. Начинаешь с простого, потом постепенно осваиваешь всё более новое.
При этом под рукой — хистори, и не нужно мучительно вспоминать, а что же такого я "натыкал" в прошлый раз, что получилось не совсем то, что нужно.
Можно легко строить свои "надстройки" — т.е. если тебе часто приходится вызывать утилиту с длинным списком "одинаковых" параметров, и отличиями в одном-двух местах, то в пару строк ты делаешь "свою" утилиту, которая спрашивает только пару параметров, а остальное подставляет.
Легко встраивать вызов этой утилитки в любой скриптинг. Т.е. ты не обязан интерактивно прощёлкивать шаги визарда.
M>Можно ли там выбор из списка организовать? Множественный выбор из списка, и тп?
Да. Да. M>Откат на пару шагов назад с выбором новых значений и переходом по другой ветке?
Да.
Ну, не так идеально, как в хорошем гуи-визарде, но вполне неплохо. Тут главное вот что: сам по себе ГУИ ничем не особенен. Чтобы сделать хороший гуй, надо вложить усилия.
Без усилий получится плохой гуй — какой-то непонятный вопрос, какие-то неразличимые радиобаттоны. Непонятно, почему в прошлый раз я видел страничку с выбором Х, а в этот — не вижу (зависимость страниц от уже сделанного выбора).
Со скриптом можно пробовать не только верные значения, и получать более-менее внятное объяснение причин ошибки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Marty, Вы писали:
M>Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё. M>Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры. M>В итоге — имеем .h и .cpp для включения в проект
Для таких целей я давно написал либу на плюсовых шаблонах (для остальной периферии, а не только для АЦП). Поддерживает несколько семейств, максимально простая, очень легко конфигурируется через шаблонные параметры. Непонятно для чего тут нужна кодогенерация и визарды.
PS: за счёт того, что всё конфигурируется на шаблонах, сконфигурированную периферию легко передавать в качестве параметров в другие либы, которые обслуживают более высокоуровневую периферию или девайсы. Всё очень удобно, не надо ничего копипастить/править или генерировать. Конфигурируешь прямо в коде — и всё.
