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

Может, кем-то DBUS и позиционируется, даже известно кем. Но CORB'y не заменит никогда, просто так спроектирован этот DBUS.

Тут нужно понимать, что может, для того десктопа, который хочет видеть Redhat, Dbus может и достаточен, но на полноценный же middleware DBUS не тянет.

Можно присылать уведомления о включенном сидюке, ну и так, по мелочи. А для того, что нужно пользователям, до этого далеко. Транзакций, например, нет да и быть не может. Да и сам путь обмена "сообщениями" понятен gtk-шным программистам, потому что они с x-ами работают, но для OO программирования много чего нет.

Да, DBUS - это СИЛЬНО облегченная версия OO RPC. Специально заточенная для десктопа - ни разу не претендующая на место all-singing all-dancing CORBA. CORBA была в гноме изначально (да и сейчас есть) - но, во-первых, KDE ее проигнорировал, во-вторых, оказалось уж очень сильным overkill - приходится платить цену производительности за неиспользуемые фичи...

Правильно ли я понимаю, что никакой модульности, присущей CORBA, в D-BUS нет? И ещё один вопрос: что обозначает "заточенная для десктопов"? Значит никаких служб защиты etc.?

Ничего там нет по существу. Только послать бродкаст и принять сообщение. Инерфейсы все запиханы во что-то вроде ASN, то есть некоторое дерево идентификаторов.

Кстати, про производительность не надо. Простите за некоторую голословность, но вряд ли скорость сильно падает.

Насколько я знаю - на уровне DBUS нет защиты. Разумеется, никто не мешает сделать на более высоком уровне... Минимализм и максимальное упрощение.

Ломающим копья на поприще стандартов!!!

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

Однако от лица "абстрактного пользователя" хотелось бы сказать "пару ласковых" разработчикам того, чем я пользуюсь.

1. СПАСИБО

2. Да когда ж вы договоритесь о том, как я должен пользоваться тем, что вы разрабатываете?

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

Чтобы было понятно, чего я хочу:

1. Единообразного управления разнообразными инструментами.

2. Предсказуемого поведения системы.

3. Совместимости и переносимости документооборота:

- единообразное форматирование внешнего вида документов;

- единообразная организация форматов документов;

(тут документ - это то, что я могу создать при помощи инструментов)

4. Ну и, конечно же, возможности восстановления утраченного(или испорченного) документа.

... и будет мне щастя, а вам - правильный юзер ...

> какие kdebase ? ;) см. выше про -lkdeui

А вот ты мне скажи, как его доставить, не ставя пол-KDE, и не опускаясь до сборки всего этого дела ручками?

Не говоря уже о том, что в любом случае придется качать kdebase-*.tar.bz2 и kdelibs-*.tar.bz2, чтобы вытащить из них то, что нужно...

отстали Вы коллега. В качестве десктопа можно использовать что угодно - КДЕ, Гном,... выбирай любой (для работы это большого значения не имеет). В качестве корпоративного стандарта уже используются: OpenOffice Mozilla (FireFox) Электронная почту прикручивай любую какую считаешь нужной, на твой вкус. Догнать осталось только бухгалтерские задачи и задачи по обеспечению бизнес-процессов (ERP системы вроде SAP самым что ни на есть активным образом смотрят в этом направлении). Compiere также работает в этом направлении. Если кто помнит я тоже вывел КИС OpenSource ERP и уже куча народа на эту систему перелезла даже под виндами (у меня в реестре зарегистрировано около 600 участников) - мэинтейнерство передал ребятам в Хабаровске, у самого времени нет - все убивается на вотрую версию КИС и скоро выведу ее в свет. И жаба как основа для всего этого рулит - шестую версию санки выводят на комунити если уже прочитал здесь новость, и это правильно. Для расслабона, игрушек под линух уже просто караул - недавно линуксцентр выпустил сборник игрух - новость здесь пролетала.

Десктоп и сервер уже взят опенсорсом. Мелкософтовцам только и остается что уповать на маразм патентного законодательства.

Но основной смысл опенсорса чтобы ты понял - опенсорс не клеется к твоим бизнес-процессам в плане привязывания путем лицензий на рабочие места к размерам твоей организации и количеству бизнес-процессов (это называется бизнес-интервенцией или паразитизмом). Опенсорс выдает открытые и готовые решения, что является трамллином для следующего поколения технологий и роста твоей организации без необоснованных затрат. А политика обозначенная открытыми лицензиями, яркий пример GPL, для получения отдачи за счет техподдержки и сопровождения стимулироет опенсорс развиваться а не красить одни и те же ботинки в разные цвета как это делают M$ чтобы продать свои решения и идти дальше. Это главная ошибка потери влияния микрософта и безнес в своем большинстве это уже давно понял. Не пересмотрит микрософт политику, он труп. Хотя видно что уже и там стали понимать свои ошибки. Если это понимание дойдет до топ-менеджмента микрософта, он выживет и внесет большой вклад в дело развития прогресса и технологий на основе открытых технологий. Не поймет, помрет (но брыкаться долго будет). И дело совсем не в линуксе и его противостоянии с коммерческими решениями как многие пытаются здесь пиарить.

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

> В качестве корпоративного стандарта уже используются: OpenOffice Mozilla (FireFox)

> Для расслабона, игрушек под линух уже просто караул - недавно линуксцентр выпустил сборник игрух - новость здесь пролетала.

> Десктоп и сервер уже взят опенсорсом. Мелкософтовцам только и остается что уповать на маразм патентного законодательства.


Ваши проблемы рашаемы - надо только найти в себе волю и отказаться от наркотиков. :-)))

В чем-то Вы правы.

Но единственное объяснение - иметь возможность на когото все свалить (MS).

ЗЫ. Не все и под виндой фиолетово

> И эти люди [Gnome и KDE] будут учить нас ковыряться в носу?

А чем занимается на emacs уважаемый сэр?! Кроме программирования у него какие-либо РЕАЛЬНЫЕ и востребованные обществом задачи есть?

"надписи на виджетах [Центра управления KDE] не влезают в размеры виджетов. Видно только половину"

Описание процесса воспроизведения - в студию. Можно прислать только скриншот с указанием версии KDE. :)

>И так везде практически... Не сумели широкие массы разработчиков и пользователей адаптироваться к новым реалиям : старые юниксовые стандарты уже устаревают, а новых ещё не придумали , от этого и бардак такой... Для взаимодействия программ, использующих протокол X были придуманы icccm. Лет уже 15 как, если не более. Только это не стандарт, а вполне себе вменяемые рекомендации. Только вот разработчики всяких разных DE их похоже не дочиали даже до середины...

> качество этого рвущего всё и вся софта просто-напросто откровенно говённое

Неплохо бы подкрепить аргументами. :)

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

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

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

Ясно аргументов - нуль, опыта тоже.

irsi-2.0.0-pre1-stable.noarch.rpm

:)))

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

> Неплохо бы подкрепить аргументами. :)

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

>Докачки нет ни в одном
Вранье. apt-get докачивает.

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

Конец дебатов.

а про какой ты плейер говоришь ? надо будет посмотреть

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

Ну давай посравниваем. Сравнивать будем 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 сплошь состоит из математически верифицированного софта. :-))

> "надписи на виджетах [Центра управления KDE] не влезают в размеры виджетов. Видно только половину"

> Описание процесса воспроизведения - в студию. Можно прислать только скриншот с указанием версии KDE. :)

Ты наверно пошутил, или мне действительно ради скриншота заново качать и компилить? Как воспроизвести: выбери шрифт большой. Ну раза в 2 больше того, что юзаешь сейчас. Сразу же увидишь эффект на заголовках окон. Ну там не половина на самом деле, а где-то 2/3 текста видно. Но сверху и снизу от текста должно быть немного пробельного места. Так вот, если с ним, то около половины и получается. Далее, зайди в Центр управления KDE. Где-то недалеко от верха в списке (точно не помню) есть посмотреть инфу о системе -- ну там список оборудования и т.п. Так вот, посмотреть мне не удалось: половина текста не влезала по ширине. Я, конечно, сообразил, что там написано (потому что знаю, что должно быть), но это все же не есть хорошо. Да и вообще на виджеты при таком шрифте посмотри и ужаснись. Кстати, штатный браузер KDE не позволяет выбрать большой шрифт для отображения контента -- еще один недостаток. Причем весьма существенный для меня. У него должен быть не список размеров, а поле ввода этого размера (или список, но с полем ввода). Иначе глаза сломать можно об мелкий шрифт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Респект:)

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


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

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

гон. emerge прекрасно докачивает/

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

:-)

Твоя аналогия -- о выборе не самого лучшего способа для достижения цели. Т.е. если бы 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) писаться до написания модуля, который они тестируют.

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

Но все они действуют согласно КОНСТИТУЦИИ

> Просто представь на мгновение, что DE был бы один... Можно ли было бы назвать тогда линукс свободным, открытым и .т.д. ;) Даже в псевдосвободной стране америкоссии есть ДВЕ партии, из которых можно выбирать. Представь, если была бы одна ;)

Но все оди действуют согласно КОНСТИТУЦИИ

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

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

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

Итак, почему вы так отзываетесь о качестве десктопных решений под Linux? Или вы и дальше будете прикрываться домохозяйками? :)

> Итак, почему вы так отзываетесь о качестве десктопных решений под Linux?


Просто-напросто потому что я ими довольно-таки регулярно пользуюсь.

> выбери шрифт большой. Ну раза в 2 больше того, что юзаешь сейчас. Сразу же увидишь эффект на заголовках окон.

Итак, KDE 3.3.1, шрифты , был размер шрифта 10pt, сделал 32pt. Всё показывается.

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

Места сколько нужно - столько и показывается. :)

> Далее, зайди в Центр управления KDE. Где-то недалеко от верха в списке (точно не помню) есть посмотреть инфу о системе

О! Какое старьё! Уже давно информация о системе выделена из Центра управления и показывается в отдельной программе (Система->Центр информации). И текст по ширине во всех разделах влезает. Потому что в таблицах.

> Да и вообще на виджеты при таком шрифте посмотри и ужаснись.

Ужасно то, что огромным шрифтом. Но виджеты показываются без проблем. Так сколько можно по ушам ездить? :)

> штатный браузер KDE не позволяет выбрать большой шрифт для отображения контента -- еще один недостаток.

А ЗАЧЕМ нужен размер шрифта >30pt. Вам нужно бОльший размер шрифта? Сомневаюсь...

> У него должен быть не список размеров, а поле ввода этого размера

Есть и поле ввода и бегунок. Настройка->Настроить Konqueror->Шрифты. Специально для вас можно указать _минимальный_ шрифт, чтобы глаза не ломать.

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

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

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

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

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