GUI vs. текстовый конфиг (отрезано от: Нужна ли реклама GNU софту...)

[Ben Aceler]

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

Вы никогда не видели программ, у которых конфигуратор отделён от самой программы?

Видел. Во всех использовались конфиг-файлы.

[oneq]

Возможно. Визуальные редакторы SQL-запросов видел последний раз очень давно. Однако, как там дальше? Ведь SQL-запрос -- еще не вся программа.

Естественно, что "дальше" нужен какой-то исполнитель этого запроса.
Если рассматривать SQL-сервер как обособленную систему, то SQL-запрос, собственно, и будет всей программой (или подпрограммой).
Точно такой же подход, имхо, вполне возможно реализовать в GUI. При этом, что самое забавное, как раз на разработку БИНАРНОГО интерфейса потребуется гораздо меньше трудозатрат, чем на написание парсера и исполнителя plain text скрипта (даже для случая встраивания специально разработанных Lua и FORTH)

Вообще, у меня складывается впечатление, что вся эта разработка "средств разработки для пользователя" -- пустая трата усилий. Проблема основной массы потребителей в том, что они не могут формализовать, что же им на самом деле надо. Когда кто-то случайно сделает то, что надо, тогда потребитель сможет ткнуть пальцем и сказать: "мне надо вот это", но что такое "это" сказать никто не может. Отсюда и проблемы с переходом с Win на Lin, отсюда и засилье 1С. На самом деле, большинство потребителей не мыслят в терминах того, ЧТО им надо сделать (будь то написание документа или сведение годового баланса), они мыслят КАК им надо делать, поэтому при изменении программы, для потребителя полностью меняется КАК без малейшего понимания ЧТО, т.е. замене подлежат пракически 100% навыков. Никакие возможности GUI-программирования не будут ими востребованы. Возможно, скоро подрастет более развитое молодое поколение, с детства тренированное усваивать бОльшее число рефлексов, но и оно вряд ли будет так уж программировать, даже в GUI.

Не думаю.
Имхо, как раз-таки большинство неопытных пользователей как раз думают ЧТО им надо получить, но абсолютно не представляют КАК. Ситуация из разряда: есть автомобиль, надо доехать из пункта А в пункт Б, но человек не только рулить не умеет, но вообще не знает, как завести автомобиль.

Видел. Во всех использовались конфиг-файлы.

Ни разу не видели программу под Windows с отделенным конфигуратором???

[minoru-kun]

При этом, что самое забавное, как раз на разработку БИНАРНОГО интерфейса потребуется гораздо меньше трудозатрат, чем на написание парсера и исполнителя plain text скрипта (даже для случая встраивания специально разработанных Lua и FORTH)

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

Базы данных - редкий случай, когда использование бинарного формата оправдано.

[watashiwa_daredeska]

Если рассматривать SQL-сервер как обособленную систему, то SQL-запрос, собственно, и будет всей программой (или подпрограммой).
Точно такой же подход, имхо, вполне возможно реализовать в GUI. При этом, что самое забавное, как раз на разработку БИНАРНОГО интерфейса потребуется гораздо меньше трудозатрат, чем на написание парсера и исполнителя plain text скрипта (даже для случая встраивания специально разработанных Lua и FORTH)

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

На самом деле, большинство потребителей не мыслят в терминах того, ЧТО им надо сделать (будь то написание документа или сведение годового баланса), они мыслят КАК им надо делать,

Не думаю.
Имхо, как раз-таки большинство неопытных пользователей как раз думают ЧТО им надо получить, но абсолютно не представляют КАК. Ситуация из разряда: есть автомобиль, надо доехать из пункта А в пункт Б, но человек не только рулить не умеет, но вообще не знает, как завести автомобиль.

При этом есть автобус, такси, электричка и много других способов выполнить задачу "доехать из пункта А в пункт Б", которые почему-то выпали из рассмотрения. Об этом я и говорю: тихо и незаметно задача трансформировалась из ЧТО в КАК: "доехать из пункта А в пункт Б на автомобиле".

[oneq]

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

Базы данных - редкий случай, когда использование бинарного формата оправдано.

Вообще-то в данный конкретный момент времени разговор идёт не о бинарном формате, а о бинарном интерфейсе автоматизации GUI.
Очевидно, что для того, чтобы получить нормальный бинарный интерфейс к GUI в современных условиях, достаточно просто тщательно поработать головой на этапе проектирования этого самого GUI. Всё равно никто нынче не пишет монолитные программы - все разбивают на модули/библиотеки/etc. Соответственно, грамотно разработав структуру модулей и их внешние интерфейсы мы автоматически получим бинарный интерфейс для автоматизации GUI.
А скриптовый движок ещё надо прикручивать.

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

UNIX-way как раз таки подразумевает "Делайте одну вещь, но делайте её хорошо".

Кроме того, в текстовом виде запрос можно легко формировать на лету, в зависимости от ситуации, а как с этим в GUI?

Это зависит от того, о каком GUI мы ведём речь. Если о нормальном, который имеет возможности автоматизироваться скриптами - Ваш вопрос не имеет смысла.
Если про более другие, то надо конкретно разбираться. Ведь никто не заставляет Вас засылать SQL-серверу именно SQL запрос. Можете подгрузить библиотеки и используя бинарные интерфейсы получить желаемое. Если GUI поддерживает хотя бы такой подход - никаких проблем не вижу.

При этом есть автобус, такси, электричка и много других способов выполнить задачу "доехать из пункта А в пункт Б", которые почему-то выпали из рассмотрения. Об этом я и говорю: тихо и незаметно задача трансформировалась из ЧТО в КАК: "доехать из пункта А в пункт Б на автомобиле".

Не согласен. По-моему задача поставлена верно.
Потому что если рассуждать по предложенной схеме с электричками и такси, то ни о каком GUI речи вообще быть не может. И о компьютере вообще.
Ибо почти все задачи решаются без него. Налоговую декларацию можно заполнить от руки, посчитать на пальцах, ну и т.д.
Поэтому потребители мыслят именно в категории ЧТО, но с изначальной установкой "на компьютере".
Хотя наверное даже не так. Они УЖЕ знают ЧТО им нужно. И они знают что они хотят это сделать на компьютере. А вот как раз "КАК" это сделать они не знают. Ибо установленная и загруженная система не предоставляет им никакой отправной точки для решения их задач.

[diesel]

Вообще-то в данный конкретный момент времени разговор идёт не о бинарном формате, а о бинарном интерфейсе автоматизации GUI.

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

[oneq]

а Вы себе хорошо разницу представляете?

Между бинарным форматом и бинарным интерфейсом??? Вы шутите, чтоли?
file.jpeg - бинарный формат
libjpeg.so - бинарный интерфейс

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

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

[watashiwa_daredeska]

Соответственно, грамотно разработав структуру модулей и их внешние интерфейсы мы автоматически получим бинарный интерфейс для автоматизации GUI.

К сожалению, нахаляву не получим. Вот, открываю я в Fierfox'е Edit->Preferences, вкладка Applications. С точки зрения пользователя -- это отображение типа контента в настройку (навроде SWF->Adobe Flash Player). Все просто как валенок, и в API это будет очень просто. А вот с точки зрения GUI (в том виде, как оно есть) там много разных виджетов, которые, к тому же, создаются динамически в ответ на действия пользователя. Чтобы получить что-то более-менее приличное нужно не только (и не столько) разбивать на модули, а делать свои компоненты, со своим специализированным API (для примера выше, API ассоциативного массива). Чтобы этим можно было универсально пользоваться извне нужны средства интроспекции, чтобы универсальные внешние средства автоматизации знали, что вообще можно сделать с этой штуковиной. И вот реализация всего этого намного объемнее и муторнее любого конфига и текстового протокола.

UNIX-way как раз таки подразумевает "Делайте одну вещь, но делайте её хорошо".

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

Кроме того, в текстовом виде запрос можно легко формировать на лету, в зависимости от ситуации, а как с этим в GUI?

Это зависит от того, о каком GUI мы ведём речь. Если о нормальном, который имеет возможности автоматизироваться скриптами - Ваш вопрос не имеет смысла.
Если про более другие, то надо конкретно разбираться. Ведь никто не заставляет Вас засылать SQL-серверу именно SQL запрос. Можете подгрузить библиотеки и используя бинарные интерфейсы получить желаемое. Если GUI поддерживает хотя бы такой подход - никаких проблем не вижу.

А я вижу. Какое это все имеет отношение к GUI и его преимуществам? Скрипты и библиотеки прекрасно существуют и без GUI -- они самодостаточны. А мы ведем речь о GUI, а не о том, что бы такое еще можно прикрутить к программе, чтобы GUI не был так ущербен.

Не согласен. По-моему задача поставлена верно.

Ну, не буду спорить о неподходящих метафорах, черт с ними. Но на практике, почти никто не выбирает между 1C и альтернативными продуктами по формальным критериям полноты охвата требуемых функций, стоимость (покупки и владения), риски и т.п. Все руководствуются стадным инстинктом, как и с автомобилями. В недавнем сюжете НТВ на "День без автомобиля", какой-то представитель московской богемы жаловался, что каждое утро и вечер проводит 2часа в пробках на своем автомобиле, но не может без него по каким-то там дурацким причинам (не помню уже). А я вот живу в Подмосковье и каждый день езжу на работу в центр Москвы -- 1:10..1:20. На общественном транспорте. Быстрее, дешевле, 0 (ноль) затрат на обслуживание, да и сколько книжек я успел прочитать, пока автомобилисты парятся в пробках за рулем.

[diesel]

а Вы себе хорошо разницу представляете?

Между бинарным форматом и бинарным интерфейсом??? Вы шутите, чтоли?
file.jpeg - бинарный формат
libjpeg.so - бинарный интерфейс

нет, между внешним текстовым интерфейсом, в качестве примера которого вы выбрали некий скриптовый язык, и внешним бинарным интерфейсом - то есть по сути API, который может быть доступен для того же самого скриптового языка. разницу есс-но для себя, как для потенциального писателя плагинов. I mean, вот у вас есть условно говоря lua, какая принципиальная для вас будет разница - встроен он во внутрь, и поэтому для вас доступны некоторые "особые" функции, или же вы снаружи зовете опять же некоторые "особые" функции. вы все-равно будете писать _текст_ общаясь с программой, и в случае libjpeg.so, и читать вы будете _текстовое_ описание того с этим разговаривать.

При этом возможность подгрузить нужные модули и вызывать функции напрямую сохранится.

вы функции напрямую будете ассемблерными вставками звать, типа "исполни вот над этими тремя битиками инструкции которые начиная с 21-го битика в библиотеке прописаны"? или таки mycoolfunction(param1,param2,param3)? в последнем случае, для вас это будет _текст_, а как это будет видеть программа - это забота программы.

[oneq]

Чтобы этим можно было универсально пользоваться извне нужны средства интроспекции, чтобы универсальные внешние средства автоматизации знали, что вообще можно сделать с этой штуковиной. И вот реализация всего этого намного объемнее и муторнее любого конфига и текстового протокола.

Хорошо. Вот bash - это тот самый универсальный внешний (по отношению к системе и другим программам) инструмент автоматизации.
Какие средства интроспекции предоставляет ему система и другие программы?
Чем это принципиально отличается от рассматриваемой ситуации с GUI?

А я вижу. Какое это все имеет отношение к GUI и его преимуществам? Скрипты и библиотеки прекрасно существуют и без GUI -- они самодостаточны. А мы ведем речь о GUI, а не о том, что бы такое еще можно прикрутить к программе, чтобы GUI не был так ущербен.

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

Ну, не буду спорить о неподходящих метафорах, черт с ними. Но на практике, почти никто не выбирает между 1C и альтернативными продуктами по формальным критериям полноты охвата требуемых функций, стоимость (покупки и владения), риски и т.п. Все руководствуются стадным инстинктом, как и с автомобилями.

Это не совсем так. На самом деле люди, естественно, сомневаются. Некоторые ищут информацию сами, но большинство - по знакомым и прочим экспертам разной степени осведомлённости. В то же время, никак нельзя сказать, что 1С держится исключительно на стадном инстинкте. Пока что никто не смог привести пример другой программы, которая учитывала бы изменения российского законодательства хотя бы с такой же скоростью и полнотой, как это делает 1С. Ну а уж количество специалистов по стране уж точно заруливает любой другой продукт в минуса - выбор есть в любом городе.

В недавнем сюжете НТВ на "День без автомобиля", какой-то представитель московской богемы жаловался, что каждое утро и вечер проводит 2часа в пробках на своем автомобиле, но не может без него по каким-то там дурацким причинам (не помню уже). А я вот живу в Подмосковье и каждый день езжу на работу в центр Москвы -- 1:10..1:20. На общественном транспорте. Быстрее, дешевле, 0 (ноль) затрат на обслуживание, да и сколько книжек я успел прочитать, пока автомобилисты парятся в пробках за рулем.

И Ви таки будете говогить мне о стадном инстинкте?!
"Работать в Москве" - одно большое проявление большого стадного инстинкта.
И вообще - добираться до работы дольше 40 минут вредно для здоровья.

I mean, вот у вас есть условно говоря lua, какая принципиальная для вас будет разница - встроен он во внутрь, и поэтому для вас доступны некоторые "особые" функции, или же вы снаружи зовете опять же некоторые "особые" функции. вы все-равно будете писать _текст_ общаясь с программой, и в случае libjpeg.so, и читать вы будете _текстовое_ описание того с этим разговаривать.

Всё, понял о чём Вы. Да, Вы в общем-то правы. И там, и там надо писать текст.
Попробую теперь объяснить в чём я вижу разницу. Для того, чтобы использовать API зачастую нужно учить какой-либо язык программирования. Потому что далеко не факт, что автор приложения писал её на известном Вам языке. В противном случае надо ждать что-нибудь вроде PyGTK, чтобы воспользоваться функционалом.
С другой стороны - встраивание какого-либо скриптового движка позволяет эту ситуацию несколько упростить.
Да, конечно, можно наговорить очень много слов про то, что язык этого движка тоже надо будет учить, что это навязывание собственных стереотипов и вообще противоречит духу свободы, но почему-то этих нареканий на bash и SQL как-то не очень слышно.

[watashiwa_daredeska]

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

Итак, мое видение того, к чему мы пришли: GUI может работать через некоторый внешний API. Этот внешний API может использоваться для управления программой со стороны: скриптами, GUI или еще как. Автоматизировать GUI непосредственно сложно и неудобно. Таким образом, GUI выступает тупиковой оконечной веткой в цепочке автоматизации (с точки зрения программы это такая же внешняя программа, работающая через внешний API), автоматизировать которую не представляется рентабельным.

Т.е. автоматизировать GUI-приложение можно, если оно правильно спроектировано, но это именно автоматизация приложения, а не автоматизация GUI. GUI в этом вопросе вообще стоит в сторонке и нервно курит.

[watashiwa_daredeska]

Чтобы этим можно было универсально пользоваться извне нужны средства интроспекции, чтобы универсальные внешние средства автоматизации знали, что вообще можно сделать с этой штуковиной. И вот реализация всего этого намного объемнее и муторнее любого конфига и текстового протокола.

Хорошо. Вот bash - это тот самый универсальный внешний (по отношению к системе и другим программам) инструмент автоматизации.
Какие средства интроспекции предоставляет ему система и другие программы?
Чем это принципиально отличается от рассматриваемой ситуации с GUI?

Средство интроспекции для bash -- "command --help". Существует миллион и одна библиотека, которые автоматизируют для программиста разбор опций и формирование вывода "--help". Есть даже программы, которые умеют генерить заготовку man command по command --help.

Давайте разберем более-менее реальные ситуации. Попробуйте предложить вариант дизайна, позволяющий выйти из этих ситуаций.

Давайте дополним пример выше с Файрфоксом реальной ситуацией. Моя задача -- запускать Файрфокс с разными от запуска к запуску обработчиками для SWF. По некоторым причинам, я не могу завести файрфоксовые профили на все случаи.

Вот даже еще одна ситуация, даже интереснее. Мне нужен еще один профиль Файрфокс, точно такой же, как текущий, но с измененным значением пары опций. Т.е., мне надо скопировать все опции текущего профиля (один запущенный файрфокс) в другой профиль (другой запущенный файрфокс). Пару опций, я так и быть, руками потом поменяю. С текстовыми конфигами это делается командой "cp" без всякой интроспекции.

[watashiwa_daredeska]

С другой стороны - встраивание какого-либо скриптового движка позволяет эту ситуацию несколько упростить.
Да, конечно, можно наговорить очень много слов про то, что язык этого движка тоже надо будет учить, что это навязывание собственных стереотипов и вообще противоречит духу свободы, но почему-то этих нареканий на bash и SQL как-то не очень слышно.

Ну, начнем с того, что bash один. И для cat, и для find и для всех прочих. А десяток программ со встроенными скриптовыми движками с большой долей вероятности выберут не менее пяти разных языков для скриптования. Кроме того, я могу не использовать bash. Знавал я одного товарища, у которого login shell'ом был emacs. Далее, нарекания на SQL есть. Berkeley DB не даром пользуется спросом. И не даром в PostgreSQL хранимые процедуры можно писать далеко не только на PL/SQL. Сейчас вообще как-то не принято уже встраивать скриптовые движки. Принято предоставлять API для прикручивания произвольных движков. Однако, согласитесь, это совсем уже другой объем работ в плане проектирования и реализации, нежели ввод-вывод на стандартные потоки ввода-вывода и разбор параметров командной строки. Со встроенным скриптовым движком это уже не будет "маленькая программа, хорошо выполняющая одну функцию".

[oneq]

Т.е. автоматизировать GUI-приложение можно, если оно правильно спроектировано, но это именно автоматизация приложения, а не автоматизация GUI. GUI в этом вопросе вообще стоит в сторонке и нервно курит.

Стоп!
Либо я чего-то не понимаю, либо Вы утверждаете, что GUI - это НЕ приложение???

Средство интроспекции для bash -- "command --help". Существует миллион и одна библиотека, которые автоматизируют для программиста разбор опций и формирование вывода "--help". Есть даже программы, которые умеют генерить заготовку man command по command --help.

Вы катастрофически несправедливы и выдвигаете неодинаковые по уровню сложности требования к GUI и plain-text. Сравните выделенные слова в цитате и вот этом тексте:
"...нужны средства интроспекции, чтобы универсальные внешние средства автоматизации знали, что вообще можно сделать с этой штуковиной"

Давайте дополним пример выше с Файрфоксом реальной ситуацией. Моя задача -- запускать Файрфокс с разными от запуска к запуску обработчиками для SWF. По некоторым причинам, я не могу завести файрфоксовые профили на все случаи.

Вот даже еще одна ситуация, даже интереснее. Мне нужен еще один профиль Файрфокс, точно такой же, как текущий, но с измененным значением пары опций. Т.е., мне надо скопировать все опции текущего профиля (один запущенный файрфокс) в другой профиль (другой запущенный файрфокс). Пару опций, я так и быть, руками потом поменяю. С текстовыми конфигами это делается командой "cp" без всякой интроспекции.

Вы опять сбиваетесь на хранение и альтернативные способы доступа к настройкам.
Повторяю - никто не запрещает GUI, во-первых, хранить опции в текстовом файле, во-вторых, иметь опции импорта/экспорта файлов настроек.

Ну, начнем с того, что bash один. И для cat, и для find и для всех прочих. А десяток программ со встроенными скриптовыми движками с большой долей вероятности выберут не менее пяти разных языков для скриптования.

Вы опять говорите о другом. Какие "десяток программ"? Мы сейчас о GUI, а не о программах вообще.
Или Вы думаете, что внутри KDE одни выберут Lua для автоматизации (например, Kontact), вторые - Forth (Kopete), третьи - Python (Kaffeine), а остальные ещё каждый по своему???

Кроме того, я могу не использовать bash. Знавал я одного товарища, у которого login shell'ом был emacs.

Вы точно также можете не использовать GUI вообще. Все проблемы по его автоматизации отпадут сами собой

Далее, нарекания на SQL есть. Berkeley DB не даром пользуется спросом.

Опять же несравнимо. BDB не предоставляет инструментов, сравнимых с SQL. Только обращения через API.

Сейчас вообще как-то не принято уже встраивать скриптовые движки. Принято предоставлять API для прикручивания произвольных движков.

Если честно, то на LOR'е в новостях постоянно вижу анонсы вских разных игр, в которых используется Lua для написания скриптов и программирования AI.
Как такое получилось, если нынче "принято предоставлять API"?

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

GUI вообще изначально "совсем другой объём работ". Тем не менее, GUI появились, существуют и загибаться как-то не собираются.
Почему так?

[Juliette]

GUI вообще изначально "совсем другой объём работ". Тем не менее, GUI появились, существуют и загибаться как-то не собираются.
Почему так?

Потому что кнопочки -- это красиво.

[diesel]

Чтобы этим можно было универсально пользоваться извне нужны средства интроспекции, чтобы универсальные внешние средства автоматизации знали, что вообще можно сделать с этой штуковиной. И вот реализация всего этого намного объемнее и муторнее любого конфига и текстового протокола.

Хорошо. Вот bash - это тот самый универсальный внешний (по отношению к системе и другим программам) инструмент автоматизации.
Какие средства интроспекции предоставляет ему система и другие программы?

в том то и дело что bash, а вернее даже shell не задумывался как инструмент который _знает_ как работает та или иная программа - это среда для их запуска, такая же как виндовый cmd.exe, но дающая ряд преимуществ, если программа которую вы в этой среде запускаете соблюдает ряд правил - лишнего не выплевывает, полезные вывод выплевывает в stdout, ошибки в stderr и так далее. тогда мы можем строить цепочки типа: prog1|prog2|prog3 или prog1&&prog2||prog3 etc.

Чем это принципиально отличается от рассматриваемой ситуации с GUI?

Простой пример: cat /etc/passwd | awk -F: '{print $1}' | sort -u |less . Вот в данном случае пайпать вывод less куда бы то ни было уже проблематично, да и врядли нужно - ибо less - это такая себе текстовая GUI для того чтобы смотреть текст удобно. Где-то видел примеры когда тот же vi(m) в pipe'ы включают, но никогда не чувствовал необходимости в чем-то подобном. Автоматизация тут скорее важна больше "внутри", чем "снаружи".

Вобщем-то автоматизация которой от GUI может хотеться - это условно говоря - накликать что-то в одной программе, накликать что-то в другой программе, и с результатами что-то сделать в третьей(собственно тоже накликать). Например, я хочу проверить в он-лайне ли Вы сейчас у меня в jabber'е, и если в он-лайне, то завернуть мой пост OpenOffice'ом в *.doc, послать Вам его на почту, и сказать в jabber - "проверь почту". Пример, конечно, надуманный, и при большом желании это в shell-скрипт можно завернуть, но раз говорим о GUI хотелось бы чтобы это можно было как раз с помощью GUI сделать, а тут уж среда должна каким-то образом соединить те самые внешние интерфейсы которые из разных программ доступны. Это как раз то для чего мог бы быть удобен dbus, или аналогичные вещи, но оно на теперешнем этапе развития для простого смертного подходит плохо, - в скрипт положить - да, а просто накликать workflow, пусть даже в чем-то похожем на Apple'овский Automator - не получится, за наличием отсутствия оного

[Goodvin]

Т.е. автоматизировать GUI-приложение можно, если оно правильно спроектировано, но это именно автоматизация приложения, а не автоматизация GUI. GUI в этом вопросе вообще стоит в сторонке и нервно курит.

Стоп!
Либо я чего-то не понимаю, либо Вы утверждаете, что GUI - это НЕ приложение???

Именно так. GUI - это НЕ приложение, это интерфейс к приложению, к его настройке и т.д.
Точно также как и текстовый конфиг - это не приложение, это лишь интерфейс к его настройке.
В данной теме обсуждается именно эта ипостась GUI, а не GUI как основной функционал приложения (например, графический редактор, аудиоредактор и т.п. ).
Не путайте это и все встанет на свои места.

[watashiwa_daredeska]

Либо я чего-то не понимаю, либо Вы утверждаете, что GUI - это НЕ приложение???

Я думаю, все Вы прекрасно понимаете, только троллите.

Вы катастрофически несправедливы и выдвигаете неодинаковые по уровню сложности требования к GUI и plain-text.

В том посте были приведены практические задачи. Попробуйте их решить с более слабыми требованиями.

Категорически несправедливы как раз Вы, приписывая GUI то, что он не умеет. Следуя вашей же логике, я могу продолжить список замечательных свойств GUI. Точно также, как GUI хорошо автоматизируется и настраивается, если его прикрутить к программе с текстовым интерфейсом и конфигами, так вот точно также GUI имеет отличные сетевые возможности, отличную кластерность и умеет летать, если прикрутить его к сетевой кластерной софтине и поставить кластер в самолете. А двигатель внутреннего сгорания очень даже экологичен и экономичен, если прикрутить его к троллейбусу и продолжать ездить на электрическом.

Вы опять сбиваетесь на хранение и альтернативные способы доступа к настройкам.
Повторяю - никто не запрещает GUI, во-первых, хранить опции в текстовом файле, во-вторых, иметь опции импорта/экспорта файлов настроек.

Вообще-то с этого все и началось, ЕМНИП. Далее, это для GUI эти способы альтернативные. А для программы с классическим текстовым интерфейсом они основные.

Вы опять говорите о другом. Какие "десяток программ"? Мы сейчас о GUI, а не о программах вообще.
Или Вы думаете, что внутри KDE одни выберут Lua для автоматизации (например, Kontact), вторые - Forth (Kopete), третьи - Python (Kaffeine), а остальные ещё каждый по своему???

Я говорю о том, что есть. KDE -- единый пакет программ от одного производителя, сделанный по более-менее единым правилам. Естественно, они выберут что-то одно. Но KDE покрывает далеко не все потребности. Мне, допустим, нужно еще что-то типа AutoCAD, а у него унутре окажется что-то типа AutoLisp, а еще мне нужен какой-нибудь GIMP, а у него унутре Scheme. А еще я хочу поскриптовать Mozilla, а у нее унутре JavaScript. Ну и все в таком духе. Взять хоть два популярных текстовых редактора: Emacs и VIM. У Emacs унутре Emacs Lisp, у VIM вообще что-то невразумительное, хотя некоторое время назад ему прикрутили возможность использовать внешние скриптовые движки.

Вы точно также можете не использовать GUI вообще. Все проблемы по его автоматизации отпадут сами собой

Взгляните на контекст сообщения. Речь шла о встроенном скриптовом движке. Если bash можно с легкостью заменить на то, что знакомее и/или удобнее: zsh, ksh, tcsh, emacs и фиг знает что еще (и не только заменить, но и использовать одновременно) без ограничений, то прибитый гвоздями скриптовый движок вынуждает учить его язык.

Опять же несравнимо. BDB не предоставляет инструментов, сравнимых с SQL. Только обращения через API.

Если бы SQL и его инструментов было достаточно и они не вызывали нареканий, то никакого Berkeley DB бы не потребовалось.

Если честно, то на LOR'е в новостях постоянно вижу анонсы вских разных игр, в которых используется Lua для написания скриптов и программирования AI.
Как такое получилось, если нынче "принято предоставлять API"?

Ну конечно, игры -- эталон архитектурного дизайна, занимают львиную долю рынка ПО и надо брать с них пример. Учитывая, что этот наиважнейший и наикрупнейший сегмент рынка ПО практически не использует GDI, а только DirectX и OpenGL, а в качестве GUI -- трехмерные интерактывные картинки от первого или третьего лица, то это и должно стать эталоном GUI, без всяких там дурацких окошек, менюшек и пр. Я прав?

Если уж вам так греют душу игры, то пожалуйста. Quake скриптуется на каком-то там Quake C (что множит число скриптовых языков) и GUI настройки там только для галочки прикрутили -- настроить через него можно очень мало чего, все через конфиг и commandline в консольке прямо в игре. Мне даже непонятно, нафига там вообще GUI настройки?

GUI вообще изначально "совсем другой объём работ". Тем не менее, GUI появились, существуют и загибаться как-то не собираются.
Почему так?

Изначально -- да, но изначально и с текстом было не так все просто, как сейчас в Unix. Создание GUI упростилось неизмеримо, но вот ущербность в плане автоматизации никуда не делась.

[oneq]

Потому что кнопочки -- это красиво.

"Ни одна девушка не оденет ничего удобного, но некрасивого"(с)

в том то и дело что bash, а вернее даже shell не задумывался как инструмент который _знает_ как работает та или иная программа <...> если программа которую вы в этой среде запускаете соблюдает ряд правил - лишнего не выплевывает, полезные вывод выплевывает в stdout, ошибки в stderr и так далее

А вот, собственно, и всё.
bash, кроме перечисленного абсолютно никакой информацией о программе не обладает. Всё остальное должен знать человек: ключи grep, команды awk и sed и т.д. watashiwa_daredeska же требует, чтобы не человек всё это знал, а программа за него делала.

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

Собственно, никаких проблем особо и не заметно - справляются же программы с получением экспортируемых ресурсов dll в винде и so в линуксе.
Написать некий супервизор, который будет принимать команды старт/окончание записи - тоже не вопрос. В Microsoft Office сделано же.

Это как раз то для чего мог бы быть удобен dbus, или аналогичные вещи, но оно на теперешнем этапе развития для простого смертного подходит плохо, - в скрипт положить - да, а просто накликать workflow, пусть даже в чем-то похожем на Apple'овский Automator - не получится, за наличием отсутствия оного

Т.е. пришли как раз к тому, что я и утверждал ранее - СЕЙЧАС это невозможно, потому что отсутствует такой GUI, но это не значит, что ВООБЩЕ GUI не автоматизируем и посему тотально ущербен.

Именно так. GUI - это НЕ приложение, это интерфейс к приложению, к его настройке и т.д.

Следует разобраться, что мы имеем в виду под словом "приложение", чтобы не запутаться ещё больше.
В частности, является ли X-сервер приложением с Вашей точки зрения?

В том посте были приведены практические задачи. Попробуйте их решить с более слабыми требованиями.

Запросто. Ровно никаких средств интроспекции НЕ требуется. От пользователя требуется запустить программу (или нажать какую-нибудь кнопочку на инструментальной панели) после чего открывать и кликать в Firefox'е. Примерно также, как записываются макросы на VBA в Microsoft Office. При этом супервизор будет отслеживать куда чего и в каком окне нажато/вбито и записывать это в какой-либо файл для последующего использования.

Категорически несправедливы как раз Вы, приписывая GUI то, что он не умеет.

Нет. Не "не умеет", а "на настоящий момент умеет, но весьма плохо".

Вообще-то с этого все и началось, ЕМНИП. Далее, это для GUI эти способы альтернативные. А для программы с классическим текстовым интерфейсом они основные.

Основные говорите?! Да нет проблем, покажите-ка мне, где есть команда cp, которой Вы собрались пользоваться, в easy editor?

Взгляните на контекст сообщения. Речь шла о встроенном скриптовом движке. Если bash можно с легкостью заменить на то, что знакомее и/или удобнее: zsh, ksh, tcsh, emacs и фиг знает что еще (и не только заменить, но и использовать одновременно) без ограничений, то прибитый гвоздями скриптовый движок вынуждает учить его язык.

Скажите, а знания emacs оттранслировались Вам в голову так любимым Goodvin'ом волшебным лучом?
Т.е. решили Вы "вот прям с этого момента выкидываю bash и ставлю в качестве login-shell emacs и буду работать только в нём" и прям взяли и тут же и перешли без необходимости хоть что-то узнать об этом само emacs'е.
И не прибит ли синтаксис tcsh "гвоздями" к этому самому tcsh?

Если бы SQL и его инструментов было достаточно и они не вызывали нареканий, то никакого Berkeley DB бы не потребовалось.

Нет, потребовалось бы. BDB намного проще, чем SQL, а вследствие этого - быстрее. Отсутствие скриптового языка - из той же оперы. Скрипт ещё нужно транслировать (хотя бы один раз) - а это прямая потеря времени. Задачи, в которых хотя бы мизерный, но выигрыш в производительности очень важен существуют всегда. Если будет создано что-то, что будет быстрее BDB - это будет использоваться. Даже если это "это" будет сущим кошмаром с точки зрения программиста.

[oneq]

Ну конечно, игры -- эталон архитектурного дизайна, занимают львиную долю рынка ПО и надо брать с них пример. Учитывая, что этот наиважнейший и наикрупнейший сегмент рынка ПО практически не использует GDI, а только DirectX и OpenGL, а в качестве GUI -- трехмерные интерактывные картинки от первого или третьего лица, то это и должно стать эталоном GUI, без всяких там дурацких окошек, менюшек и пр. Я прав?

Дык "окошечки" - это и есть "от третьего лица" вообще-то

Изначально -- да, но изначально и с текстом было не так все просто, как сейчас в Unix. Создание GUI упростилось неизмеримо, но вот ущербность в плане автоматизации никуда не делась.

Т.е. Вы, признавая то, что и в текстовых интерфейсах с самого начала не было подобного уровня автоматизации, требуете от GUI, который появился лет на 30 позже, точно такого же уровня? Ещё и признавая попутно, что для работы над GUI требуется больше трудозатрат??? И после этого Вы будете говорить, что Вы справедливы?!