Разработчики Gnome планируют крупные измемения API к релизу 3.0.

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

Унификация должна быть разумной, ведь в чём изначальная фишка Linux:
имеем программы tar ,gzip и bzip,
они обсолютно три разные программы но взаимодействуют
они обсолютно определённым способом ,т.е. если я возьму
и заменю gzip на bzip способ взаимодействия с tar не поме
няется и он стандартен практически для всех консольных
программ,это касается всего "изначального" Linux...
В этом направлении и нужно двигаться в графике:

1.Стандартизировать БАЗОВЫЕ функции и свойства графических приложений

а)Работа с темами отдельно от библиотеки виджетов...
б)Стандартизировать работу с меню (как с неотъемлимой частью граф.инт.)
в)Стандартизировать расположение конфигурационных файлов
(актуально вообщето для всей системы)
г)Распределить функции между приложением и wm ...
д)...
е)...

2.Стандартизировать метод взаимодействия между графическими приложениями...

а)Drag-n-Drop...
б)Система взаимодействия одна и отделена от графических библиотек...
в)...
г)...

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

>Пожалуйста - присоединяйтесь, пишите в мейллисты, убеждайте! Если, >конечно, Вам есть что сказать.

С английским плохо чтоб в мейл-листы писать :), а высказаться
хочеться ,может кто ещё со мной согласен, кто-то ещё что-то добавит,
а кто-то это всё почитает да и пошлёт в мейл-лист на freedesktop...
А вообще странно что этого всего ибеологи Linux не понимают, очевидные
ж вещи, или нет ?

>Короче следует стандартизировать основопологающие системы
>графического интерфейса,как это сделано для консоли

И сделать это следует(после проработки всех нюансов) в ультимативной форме,
т.е. если не соответствует дистр стандартам то значит не Linux...
Мы же щас Винду с Linux не путаем потому как разные системы с разными
стандартами... Был UNIX были его стандарты это было более 15-ти лет назад
Щас пришло время самим создателям GNU/Linux взять на себя ответственность !

В принципе - примерно об этих же вещах и думают на fd.o. Просто очень непросто подгонять под одну гребенку весь имеющийся зоопарк. Некоторые Ваши пункты - так прямо буквально подпадают под стандарты (например, про wm). Система взаимодействия на десктопе, отделенная от графических библиотек - это ИМХО ОЧЕНЬ геморройно (если вообще реализуемо).

ЗЫ Про стандартизацию расположения конфиг. файлов - это вы про реестр?:)

ЗЗЫ Вопрос на засыпку - как предлагаете стандартизовать диалог открытия файлов?:)

А вот этого никогда не будет. Потому как есть самые разные X terminals. Потому как fd.o работает на униховый, а не линуховый мир (и это ПРАВИЛЬНО)! Линуховый сепаратизм (и задирание носа в сторону унихового наследия) - ни к чему хорошему не приведет. Проиграют все. Выиграет МС.

>Система взаимодействия на десктопе, отделенная от графических библиотек - это ИМХО ОЧЕНЬ геморройно
>(если вообще реализуемо).

Не уверен, но другого выхода нет, или стандартизировать KDE(GNOME) или разделять и властвовать, вот
с утра люди на работу потянутся, интересно будет мнение программеров узнать...

>ЗЫ Про стандартизацию расположения конфиг. файлов - это вы про реестр?:)

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

>ЗЗЫ Вопрос на засыпку - как предлагаете стандартизовать диалог открытия файлов?:)

Никак... стандартизации подлежат только самые основные и низкоуровневые функции и свойства...

>А вот этого никогда не будет. Потому как есть самые разные X terminals.
>Потому как fd.o работает на униховый, а не линуховый мир (и это ПРАВИЛЬНО)!
>Линуховый сепаратизм (и задирание носа в сторону унихового наследия) - ни к чему хорошему не приведет.
>Проиграют все. Выиграет МС.

В "Униховом наследии" был графический интерфейс ? И были какие либо стандарты на него ?
оно это наследие было более 15 лет назад...По меркам IT индустрии это огромный срок...
Если опираться на униховое прошлое то придётся обеспечивать всё взаимодействие через
"консольная программв + фронт-енд"
И опять же ,я говорю только о стандартах ВЗАИМОДЕЙСТВИЯ и не призываю прклеиваться к
конкретным библиотекам, программам(например к иксам) и платформам, ведь наличие
стандартов в консольных программах ни кому не мешает...

>Линуховый сепаратизм (и задирание носа в сторону унихового наследия)
Это не линуховый сепаратизм, вот то что делают Gnome c KDE это всяческое
попирание "Унихового наследия"...
И потом, как же GNU Not Unix ?

гну не юникс уже давно :) линуксу долгое плавание а так как она наследница юниха - самой лучшей операционки для автономных программ, теперь вот в связи с агентами тож актуальная

> Вопрос на засыпку - как предлагаете стандартизовать диалог открытия файлов?:)

Зачем их стандартизировать? Их должно быть несколько, а вызываться должен тот, который прописан в настройках пользователя.

P.S. И кнопка отмены должна быть (опционально, конечно).

> В "Униховом наследии" был графический интерфейс ? И были какие либо стандарты на него ?

Таки да, был. Motif и CDE.

> Это не линуховый сепаратизм, вот то что делают Gnome c KDE это всяческое попирание "Унихового наследия"...

Вот гнать не надо, да! В KDE dcop kmail XXX | sed -e ''... Запросто приложениями можно управлять из командной строки. Вы не знали? :)

> ЗЗЫ Вопрос на засыпку - как предлагаете стандартизовать диалог открытия файлов?:)

Так, как принято решать подобные задачи в UNIX. Скажи мне, как ты ищешь строки в файлах по регэкспу? Наверно, popen("grep regexp files", "r")? Также и форма для запроса имени файла может быть реализована: прога с аргументами, c ее stdout -- имя файла.

> Скажи мне, как ты ищешь строки в файлах по регэкспу? Наверно, popen("grep regexp files", "r")?

Нормальный программер использует библиотечный regex. Или pcre, если подходяще. Использовать по любому поводу exec() IMHO дурной тон.

> Также и форма для запроса имени файла может быть реализована: прога с аргументами, c ее stdout -- имя файла.

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

> Наверно, popen("grep regexp files", "r")?

Жуть какая. На каждый чих процесс запускать. Уних-вей на стероидах.

>> Скажи мне, как ты ищешь строки в файлах по регэкспу? Наверно, popen("grep regexp files", "r")?

> Нормальный программер использует библиотечный regex. Или pcre, если подходяще. Использовать по любому поводу exec() IMHO дурной тон.

Ты ошибся сайтом, сынок. С таким подходом иди на http://www.windows.org.ru.

>> Также и форма для запроса имени файла может быть реализована: прога с аргументами, c ее stdout -- имя файла.

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

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

>> Наверно, popen("grep regexp files", "r")?

> Жуть какая. На каждый чих процесс запускать. Уних-вей на стероидах.

Зря ты иронизируешь. UNIX way вполне доказал свою состоятельность. Его принципы шли от практики и проверялись практикой в течение 30 лет. Лично я не вижу причин, по которым стоило бы от них отказываться. Если "оно давно появилось" для тебя достаточная причина, то, может быть, ты зря ушел из мира MS Windows? Или есть-таки другие причины?

>Компоненты в UNIX -- это мелкие программки-кубики, каждая из которых решает 1 (одну) задачу. Цельная гуевая юзер-фрэндли софтина для энд-юзера склеивается из них с помощью скриптового языка. Если ты не знал об этом раньше, так знай.

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

> UNIX way вполне доказал свою состоятельность.

Кто-нибудь с этим спорит? Просто у любого универсального подхода есть границы применимости. UNIX way - не исключение. И создание, запуск отдельной программы на _каждый_ чих - это как раз переход за эти границы (в этом месте можно сделать fork дискуссии про более эффективные ОС, где порождение процесса дешево и файлом является действительно ВСЕ - но это уже обсуждалось, и к линуху это никак не относится).

Домыслы про "оно давно появилось" и про "уход из мира MS Windows" позволю себе к той же хамоватой манере ведения дискуссии, которую Вы демонстрируйте. Еще раз (последний) прошу подумать над тем, как Вы ведете беседу - в противном случае буду вынужден записать Вас в игнор (этим Вас вряд ли испугаешь - я просто ставлю в известность).

> UNIX way вполне доказал свою состоятельность.

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

Насчёт шеллов - я прилично поюзал и sh и виндовый скриптинг. Поверьте мне - то как это сделано в винде (jscript + всевозможные COMпоненты) для большой части задач намного консистентнее и удобнее чем sh.

Правильно! Вот это именно так и надо писать! Только ещё создать отдельные команды на недостающие библиотечные вызовы и писать на shell (тут вопрос, правда, интересный: использование встроенной арифметики bash'а --- это тоже ересь?).

А ваще, забей нах на svu, он не пацан! Ща чё-нить про будершафт залепечет. Интеллигент недобитый, чё он здесь вообще делает?

> UNIX way вполне доказал свою состоятельность. Его принципы шли от практики и проверялись практикой в течение 30 лет.

За эти 30 лет компьютеры превратились из больших калькуляторов в средства коммуникаций, сложного анализа и развлечений. А теперь скажи, как UNIX way может помочь в этих трёх ипостасях.

Только про chat не надо начинать :)

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

Ну давай посравниваем. Сравнивать будем 2 подхода:

(1) UNIX way: если программе нужна доп.функциональность, она запускает другую программу.

(2) Windows way: запуск программ из программ не используется, доп.функциональность реализуется подключением библиотек.

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

Начинаем с запуска программы. Для каждой подключаемой либы динамический линкер должен совершить ряд телодвижений. Открыть либу и отобразить ее в адресное пространство процесса. В зависимости от адреса ее отображения настроить таблицу адресов экспортируемых символов. Настроить адреса импортируемых из других либ символов (например, из libc). Чем толще либа, тем больше с ней возни. Чем больше либ использует программа, тем дольше она подготавливается к запуску. Вывод: скорость запуска (1) выше.

Следующее: требования к памяти. Те данные либы, которые для чтения-записи, у каждого процесса свои (они не могут разделяться между процессами). Соответственно, (1) требует меньше памяти под сегмент данных.

Далее: API. У каждой либы он свой. Программа, использующая кучу либ, должна содержать кучу кода для взаимодействия с каждой из них. Для добавления новой функциональности к (2) нужно писать поддержку нового API. Программа, использующая кучу программ, юзает на выбор один из двух API: popen или pipe-fork-exec-wait, независимо от разнообразия запускаемых программ. Плюс парсер результата (тоже один на всю кучу). Добавление новой функциональности (за счет внешних компонент) не приводит к усложнению программы. Вывод: (1) проще в реализации. Первое следствие: (1) содержит меньший сегмент кода. Второе следствие: (1) содержит меньше багов.

Далее: возможность для юзера использовать новые фичи внешних компонент. Для (2) программист должен отслеживать развитие используемых им библиотек и прикручивать поддержку новых фич. Юзер должен ждать, пока у программиста дойдут до этого руки. Для (1) юзер, если очень захочет, может прочитать "man $extprg" и вбить нужные ему опции в Options->Advanced->${extprg}->CommandLine. Вывод: (1) удобнее для юзера. Аналогичная ситуация с фичами внешних компонент, не поддерживаемыми данной программой (не обязательно новыми).

Следующее: баги во внешних компонентах. В случае (2) любое неосвобождение системных ресурсов в либах имеет тенденцию к накоплению: если программа работает долго, она сжирает всю память или остается без файловых дескрипторов. И по этой причине в конце концов умирает. Любая фатальная ошибка (напр. segfault) в либе имеет фатальный результат для программы в целом. В случае (1) ошибки внешних компонент не имеют тенденции к накоплению, не рушат программу и вообще не влияют на остальную ее функциональность. Вывод: (1) меньше глючит.

Последнее: реализация внешней функциональности по запросу юзера. В случае (2) программа отзывается сразу же. Для (1) нужно запустить внешний процесс, что приведет к задержке отклика. Вывод: внешние компоненты-программы не должны использоваться для реализации основной функциональности данной проги. Например, если это рисовалка, нельзя запускать внешнюю программу для отрисовки графических примитивов. А вот для запроса имени файла -- можно, поскольку юзер не выбирает файл для открытия/сохранения каждые несколько секунд. И для диалога настроек можно. И для сравнения двух файлов. И т.п. -- т.е. для _дополнительной_ функциональности, а не для основной (а иначе нафига вообще данная прога нужна?).

Еще один момент остался за кадром: либа может подключаться не при старте программы, а при необходимости (т.е система плагинов). Если плагин потом не выгружается, уходит первый недостаток. Если отработав -- выгружается, уходят два первых, но появляется последний. Все прочие в любом случае остаются. Если с помощью системы плагинов с единообразным интерфейсом хочется уйти от кучи разных API, то добавляется работа по проектированию интерфейса с плагинами: сначала создается API, потом пишется куча плагинов, потом (через некоторое время) при попытке добавить кое-какую функциональность выясняется, что она не ложится на существующий API, и его надо переделывать, заодно перепахивая кучу имеющихся плагинов. Резюме: гемор тот еще.

ЗЫ: в случае использования скриптового языка (такого как shell, например) использование программ из программы-скрипта еще проще, потому задача запуска программ и парсинга результатов их выполнения вообще не стоит (это делает интерпретатор).

ЗЗЫ: вполне допускаю, что я здесь чего-то упустил (или вообще не прав по всем пунктам). В любом случае, было бы интересно услышать аргументы с противоположной стороны баррикад :-).

>> UNIX way вполне доказал свою состоятельность.

> Да ну? Последнее время всё больше слышно как народ со средних юниксовых серверов на винды переползает. [...]

И? Говорит ли это о том, что виндовый софт лучше? Удобнее? Надежнее работает и меньше глючит? В виндах что ни программа, то баг на баге.

На тот случай, если ты пожелаешь привести мне мои же вопли по поводу KDE/GNOME, сообщаю: ни тот, ни другой не соблюдают принципы UNIX way. Оба эти проекта используют виндовые подходы в разработке: "преумножим сущности без необходимости" и "чем сложнее -- тем лучше". Именно поэтому меня возмутила заява svu, что гномеры с кдешниками -- источник стандартов в мире десктопов UNIX.

> И? Говорит ли это о том, что виндовый софт лучше? Удобнее? Надежнее работает и меньше глючит?

Нет. Ни о чём по отдельности это не говорит. Это просто говорит о том, что, в целом, потребители считают его использование для себя более выгодным.

> В виндах что ни программа, то баг на баге.

Да. В противовес этому свалка трупов на sourceforge сплошь состоит из математически верифицированного софта. :-))

>> UNIX way вполне доказал свою состоятельность. Его принципы шли от практики и проверялись практикой в течение 30 лет.

> За эти 30 лет компьютеры превратились из больших калькуляторов в средства коммуникаций, сложного анализа и развлечений. А теперь скажи, как UNIX way может помочь в этих трёх ипостасях.

А ничего принципиально не изменилось. Те же файлы. Те же процессы. Те же юзера. Ну вместо управляющего терминала -- окно (или несколько окон) на графическом дисплее. Ну и что? Принципиальной разницы-то нет. В моде интерактивность и событийно-ориентированная архитектура? Так /bin/sh изначально таков. Что нового-то? Вывод не только текста, но и графики? Так опять же, принципиальной разницы между ними нет. В конце концов, текст -- тоже графика, только рисуемая аппаратно терминалом. Звук и прочая мультимедия? Так она ничем существенным не отличается от текстового ввода/вывода: тоже информация, только форма представления иная.

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

Вот тебе пример. Один из принципов UNIX way: чем проще программа -- тем лучше. Почему? Потому что ее легче написать и отладить. Этот принцип устарел по-твоему? Вот еще: для решения большой и сложной задачи ее следует разделить на кучу простых и мелких, и решить их по отдельности. Основа математики, не так ли? Собирается этот принцип устаревать в обозримом будущем?

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

>> И? Говорит ли это о том, что виндовый софт лучше? Удобнее? Надежнее работает и меньше глючит?

> Нет. Ни о чём по отдельности это не говорит. Это просто говорит о том, что, в целом, потребители считают его использование для себя более выгодным.

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

>> В виндах что ни программа, то баг на баге.

> Да. В противовес этому свалка трупов на sourceforge сплошь состоит из математически верифицированного софта. :-))

Вообще-то я коммерческий софт имел в виду. Тот, за который уплачены деньги (и немалые). Так вот: баг на баге. Почему? А потому что один толстый exe'шник и 20 dll к нему. Вся эта куча говна весит 10М. Поди-ка поотлаживай ее. Можно поступить по-другому: написать 50 мелких и простых программ, каждую из них вылизать (они ж простые, фигли их отлаживать-то?), и объединить их в один пакет с помощью "основной" программы, с которой и будет иметь дело юзер. А сама эта "основная" программа никакой обработкой данных заниматься не будет. Только запускать нужные "рабочие" программы. Но в виндах так делать не принято.

Описанный пример на 10М -- это Phyton'овская IDE для Microchip'овских PIC'ов -- дерьмо дерьмом, но я обязан ее юзать, скрипя зубами и проклиная разработчиков за нескончаемые баги. Впрочем, она не одна такая. Подобного коммерческого софта под винду -- большинство (во всяком случае, из того количества, с которым приходилось сталкиваться лично).

Давай курить вместе!

Респект:)

> Что нового-то? Вывод не только текста, но и графики? Так опять же, принципиальной разницы между ними нет.


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

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

:-)

Твоя аналогия -- о выборе не самого лучшего способа для достижения цели. Т.е. если бы Skull спросил совета по выбору текстового редактора для программиста, а я бы ему посоветовал ed, мотивируя тем, что он тоже текстовый реадктор, то твое замечание на тему "emacs для этого подходит лучше" имело бы смысл.

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

>Если опираться на униховое прошлое то придётся обеспечивать всё взаимодействие через "консольная программв + фронт-енд"

Считаешь это плохой путь? IMHO во многих случаях наилучший.

> Если опираться на униховое прошлое то придётся обеспечивать всё взаимодействие через "консольная программв + фронт-енд"

Для офисных программ типа word это, наверно, затруднительно, но против K3b и nmapfe я лично ничего не имею

> Считаешь это плохой путь? IMHO во многих случаях наилучший.


Да, это плохой путь.

1) Формат коммандной строки, набор параметров и т.п. в след версии запросто могут поменяться.

2) Командная строка задумана как human readable/writeable, нахрена спрашивается такое лишнее дрочилово - сначала данные в машинном виде перегонять в human readable для того чтобы тут же их парсить обратно в машинный вид.

Про упомянутый K3b - лично не видел ещё ни одного человека, который бы от него не проплевался и не вернулся на консольный cdrtools.

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

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

> Формат коммандной строки, набор параметров и т.п. в след версии запросто могут поменяться.

И часто они меняются? Примеры плиз. Обычно - добавляются новые. Ну, может, убираются совсем устаревшие. Однако, родной, ТО ЖЕ САМОЕ происходит с функциями в библиотеках. Так в чём разница?

> Командная строка задумана как human readable/writeable, нахрена спрашивается такое лишнее дрочилово - сначала данные в машинном виде перегонять в human readable для того чтобы тут же их парсить обратно в машинный вид.

Так и html тоже изначально human readable. Сильно это мешает MS Frontpage? Опять не убедил.

> Про упомянутый K3b - лично не видел ещё ни одного человека, который бы от него не проплевался и не вернулся на консольный cdrtools.

Чтоб быстро сляпать CD, использую его. Почему нет? А чайники учить опции командной строки ОЧЕНЬ не любят. Потому K3b у них идёт на ура.

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

IMHO ставить не забываем. Нет "правильных" решений. Есть более подходящие в той или иной ситуации.

> В винде это, между прочим, уже давным-давно так и сделано чуть ли не везде.

Потому что командная строка там... хм... Помнишь, как виртуальная DOS-машина в win98 грузила CPU? M$ намеренно её ну если не убивала, то игнорировала. Так что ситуация в винде - вынужденная.

>> Считаешь это плохой путь? IMHO во многих случаях наилучший.

> Да, это плохой путь.

> 1) Формат коммандной строки, набор параметров и т.п. в след версии запросто могут поменяться.

Не припомню ни одной программы, у которой бы за 5 прошедших лет изменился интерфейс ком.строки несовместимым образом. А вот API библиотек -- да, помню. Навскидку: freetype1->freetype2, qt2->qt3, gtk1->gtk2.

Вот есть у меня сильфида (MUA такой). Раньше она не имела встроенных средств вывода изображений. Вместо этого вызывала внешнюю программу. По умолчанию "gview %s" (могу ошибаться с именем). Этой программы у меня нет, но есть xzgv. И сильфида прекрасно ее использовала, если ей указать "xzgv %s".

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

Если же ты думаешь, что это реально, то опиши, пожалуйста, процесс переучивания qt-шных прог на gtk1 (доступный для энд-юзера, естественно). Зачем? А потому что мне не нравится тормознутая qt, предпочитаю легкий gtk1. У меня все программы, которые позволяют выбрать свой редактор, юзают emacs -- ну привык я к нему, и других мне не надо. Вот также я хочу и для тулкита: зачем мне два штуки, я один хочу. Итак, могу ли я добиться для библиотеки (gtk1) того же, что и для программы (emacs)? (т.е. чтобы все используемые мной проги юзали то, что скажу я)

> 2) Командная строка задумана как human readable/writeable, нахрена спрашивается такое лишнее дрочилово - сначала данные в машинном виде перегонять в human readable для того чтобы тут же их парсить обратно в машинный вид.

Действительно, нахрена? Имя используемой программы вместе с опциями хранится как текст, и юзеру выдается (при запросе на изменение) тоже текстом. Никаких преобразований. А вот если либу юзать, то некоторые опции, скорее всего, таки придется преобразовывать туда-обратно.

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

А еще подумай про тестирование/отладку. Либу нельзя просто так взять и оттестить/отладить. К ней нужно юзерский интерфейс прицепить сначала. Он должен будет парсить опции и выдавать результаты на stdout/stderr. Т.е. по сути нужна программа с CLI. Так почему бы не дергать в последующем именно ее, а не либу? (она ж делает проверку корректности опций)

Тем более, что либу нужно реализовывать более тщательно. В ней нельзя делать что-то типа такого:

if (!(buf = realloc(buf, size += incr))) {perror(prgname); exit(1);}

потому что, во-первых, выход может быть недопустим, во-вторых, ошибки могут идти не на stderr, а, например, в строку состояния, в-третьих, если нет памяти требуемого размера, будет утечка памяти. А во всех функциях, которые зависят от данной, нужно проверять, хватило ли ей памяти, и, если не хватило, передавать вверх по цепочке сообщение об ошибке. Т.е. трудозатрат больше. И глюков больше (где-нибудь сильно выше обязательно забудешь проверить успешность получения ресурса, и прога вылетит по segfault или еще как-нибудь заглючит).

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

> В винде это, между прочим, уже давным-давно так и сделано чуть ли не везде.

Извини, но винда не пример для подражания ни разу. С ее дико сложным IPC было бы странно, если бы его интенсивно юзали. Всякие там появляющиеся каждый год сложнющие OLE, OLE Automation, OLE2, DDE, COM, COM+, DCOM, ActiveX (я ничего не забыл?). И предлагается все это изучать? Ну нах.

> А если бы адепты юнихов в течении 30 лет меньше рассуждали про величие и непоколебимость Юних-Вея, а больше бы занимались развитием самого юниха, то соотношение на рынке сейчас могло бы быть иным.

:-)

Прикалываешься? Или на самом деле историю не знаешь?

> И предлагается все это изучать?

А как ты хотел? Закончить школу и потом всю жизнь книжек в руки не брать? Так всё равно на работе ведь заставят.

Signals, Pipes, FIFO, System V Messages, POSIX Messages, Sockets, Shared Memory, RPC, CORBA - списочек ведь тоже нехилый выходит. Нафига, вот, спрашивается всё это понавыдумывали? Сидели бы с одними пайпами, если это так круто.

> А еще подумай про тестирование/отладку. Либу нельзя просто так взять и оттестить/отладить. К ней нужно юзерский интерфейс прицепить сначала. Он должен будет парсить опции и выдавать результаты на stdout/stderr. Т.е. по сути нужна программа с CLI. Так почему бы не дергать в последующем именно ее, а не либу? (она ж делает проверку корректности опций)


Советую прочитать что можно отыскать из Бека и Ко. Потом прочитать ещё раз. И ещё раз. После этого те главы, которые посвящены тестированию, вырезать и расклеить над кроватью для чтения на ночь в качестве молитвы. :-))

Ron, ты только зря зарываешь свой недюжинный талант в землю. Мне больно на это смотреть, поэтому я нашёл тебе хорошее применение. Вот, помоги страждущему: http://winfaq.com.ru/ubb/Forum4/HTML/006903.html Заодно продемонстрируешь всем свои колоссальные знания и умения. Я вечером проверю. И, кстати, там много таких - все они, как ни странно, никак не могут справиться с самой простой, интуитивно понятной и надёжной системой. Так дай же бой ламерству! Я верю, у тебя получится!

> Signals, Pipes, FIFO, System V Messages, POSIX Messages, Sockets, Shared Memory, RPC, CORBA - списочек ведь тоже нехилый выходит.

Дело-то не только в количестве сущностей, но и в их сложности. В винде IPC _неоправданно_ сложный. У меня лежит книжка "Основы COM" (автор Дейл Роджерсон). Ее размер три с половиной сотни страниц. Это же ненормально. Если задачу можно решить несколькими способами, следует выбрать самое простое решение. В Microsoft думают иначе: чем сложнее, тем лучше.

Вот ты чуть выше выступал против текстового IPC. А ведь он проще для понимания и его легче отладить, чем двоичный. Если у тебя почтовый сервер не принимает почту, ты можешь подключиться telnet'ом к 25 порту и прямо _вручную_ с текстового терминала пообщаться с ним. Аналогично с POP3/IMAP4. Я так однажды почту забирал с POP3 сервера -- непонятно было, кто глючит, клиент или сервер, и пришлось разбираться вручную.

А теперь вернемся к win IPC. В 1999 году на WinNT-4.0 я убил месяц на DDE. Была идея двух программ и обмена данными через DDE. Этот гребаный DDE просто не работал, и хоть ты тресни. В конце концов я нашел один косяк, и оно заработало. Но теперь программа-приемник стала подвисать через нерегулярные интервалы времени. Это была жопа, и пришлось отказаться от DDE в пользу одной dll, которая использовалась обоими программами. В качестве "бонуса" я получил кривую архитектуру программного комплекса. Когда начал читать про основы COM, оказалось, что DDE -- это семечки по сравнению с COM. Вот где неисчерпаемый источник багов-то!

Ни один из методов виндового IPC не является текстовым и не предполагает легкого понимания и легкой же отладки. Поэтому на отладку просто забивают. Окно есть? Есть. Рисуется там что-то? Рисуется. Ну и ладушки, можно продавать "продукт". Единственный вид виндового IPC, являющийся прозрачным (т.е. можно с уверенностью сказать как он работает) -- это SendMessage (могу ошибиться с названием функции). Слать таким образом уведомления о событиях можно, но прокачивать через него массивы данных нереально.

UNIX IPC несравнимо проще виндового. По неочевидности и запутанности только RPC может конкурировать с виндовыми [D]COM[+]. Да и то жидковат. Наиболее же часто используемые механизмы просты и понятны. (про упомянутый тобой CORBA ничего не знаю, поэтому ничего сказать не могу.)

> Советую прочитать что можно отыскать из Бека и Ко.

Кратко, самую суть, своими словами, можешь изложить? Мне интересно. Хоть сложные либы и не пишу, но все равно может пригодиться для общего развития.

> Кратко, самую суть, своими словами, можешь изложить?

http://www.xprogramming.com

Основная суть - тесты должны:

1) быть программными;
2) выполняться полностью после каждой даже незначительной модификации программы;
3) писаться до написания модуля, который они тестируют.

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

Ok, спасибо за инфу.

> А уж каков объем этой информации и какова форма ее представления -- это несущественные детали.

Вот в этом ваша главная ошибка! Если я использую "неправильный" kaddressbook, то мне намного _быстрее_ найти контакт по категории и начать писать ему письма/звонить, чем если бы я использовали терминал и sed/grep :)

> Можно поступить по-другому: написать 50 мелких и простых программ, каждую из них вылизать (они ж простые, фигли их отлаживать-то?), и объединить их в один пакет с помощью "основной" программы, с которой и будет иметь дело юзер.

А потом помнить все ньюансы запуска каждой из этих 50-ти программ? Вы работать собираетесь или мазохизмом заниматься?!

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

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

О как тебя занесло! Ты почитай мои посты - я говорил о том, что для полёта не самолёте необязательно знать устройство реактивного двигателя и уметь заправлять самолёт. Или ты настаиваешь на том, что каждый человек должен знать и уметь всё? :))

> если бы Skull спросил совета по выбору текстового редактора для программиста, а я бы ему посоветовал ed

Супер! Я, конечно, им пользовался, но мне и работать и программировать надо. Потому я уже давно сижу на Kate. :)

Порог обучения монстрам типа Emacs крайне высок для обычного человека. Поэтому мне нужен инструмент для работы, а не игрушка для перманентного обучения. BTW, для правки конфигов ничего лучше vim не придумано (это я к тому, что я не только гуёвый фанат).

> Про упомянутый K3b - лично не видел ещё ни одного человека, который бы от него не проплевался и не вернулся на консольный cdrtools.

Хм. Ну я не плююсь. Потому как у меня реальная офисная работа и разбираться с консольными программами я могу только если крайне сильно припрёт. Или вы администратор и вам целый день делать совершенно нечего, чтобы тащиться от чистого cdrtools? :))

> если надо - фронт-енд коммандной строки, а, если надо, то гуйный.

А кто писАть-то будет, если такие программеры как вы, GUI не воспринимают как класс? Потому Linux на десктоп и не может пробиться, что программисты под ним слишком надменны, чтобы делать софт для простых пользователей. :(

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

Написал то, написал, тока .уйню сплошную. Что в унихе, что в мастдаях есть как инпрок-сервера, так и аутпрок-сервера. В компонентной архитектуре что там используются клиентские стабы и серверные скелетоны, что там. Для аутпроков используются прокси-стабы и принцип везде одинаковый. Короче, компонентные принципы в обоих платформах одинаковые и нечего их сравнивать. Но ИМХО уних всеравно круче, а линух и подавно.

А krename тоже круче чем mv? =))

Правильно, но для того чтобы летать надо чтобы в кабине сидел пилот-он умеет управлять самолётом. Для того чтобы он поднялся в воздух требуется квалифицированная команда сборщиков, а для того чтобы обслуживать существует наземная команда техников (заправщиков в том числе). Конечно обычный чел НЕ ДОЛЖЕН знать устройства реактивного двигателя для того чтобы ЛЕТЕТЬ в этом самолёте, но извините и не домохозяйки его обслуживают и строят, а уж для того чтобы обычного чела посадить за штурвал?????? Надо по меньшей мере быть идиотом. От этих предпосылок и пляшем.