Вышел GNOME 2.4

Да я собственно и говорили про синюю курву и умолчательный офтопик ХР. Виноват, умолчательного химиана не видел. Синяя курва меня не раздражает (и даже я ее не менял ни на что), но все-таки она слегка мультиковая. Хотя ХР, мне кажется, сильно хуже. Но это уже офтопик. Вообще, конечно, это все вопросы вкуса - тут даже спорить глупо...

Компонентная система - необходимая часть любого приличного десктопа. И ничего Вы с этим не поделаете. То, что KPart неполноценна (как мне неоднократно объясняли), а bonobo местами кривовато - никак не опровергает общую идею.

>Компонентная система - необходимая часть любого приличного десктопа. И
>ничего Вы с этим не поделаете. То, что KPart неполноценна (как мне
>неоднократно объясняли), а bonobo местами кривовато - никак не
>опровергает общую идею.
2svu. Компонентная оно хорошо, никто не спорит, вот только, как давно в GNOME появилась эта самая компонентная модель? Еще глюкавая местами, тормозная и с проблемами. KPart тоже не сахар, но он работает дольше и достаточно хорошо работает. В том то и прелесть KDE vs. GNOME, что они оба заставляют друг друга находиться в тонусе! Вот Apple, насколько помню по новостям, взялась за KPart чтобы сделать из нее конфетку с возможностью интегрирования в свой desktop.

В гноме бонобо появилось чуть не с самого начала. Да, есть у нее некоторые проблемы - в реализации точно, может, и в архитектуре (я не очень большой спец по компонентным архитектурам). Но идеологически она действительно пытается охватить все, что требуется от компонентной архитектуры. KParts же ставит перед собой более скромные цели (может, более достижимые:) - комплексные документы. Лично мне больше нравится "максимализм" бонобо. Особенно - когда я, наконец, увижу openoffice view в nautilus (впрочем, и абивордовский сойдет - а он уже почти работает).

>Лично мне больше нравится "максимализм" бонобо. Особенно - когда я,
>наконец, увижу openoffice view в nautilus (впрочем, и абивордовский
>сойдет - а он уже почти работает).
:) А в Konqueror уже можно видеть в view документы openoffice именно движком OO. :) Да и Mozilla встраивалась туда же... Так чта... :)


А в общем согланен с svu, вот только при идеи охватить все все вспоминается CORBA которая тоже пыталась охватитить все и вся и в итоге получилась большой, сложной и практически не имеющая качественных реализация (opensource).

а бонобо и есть корба

Ну не сделали пока бонобовский контрол для ООо! А мозила (точнее, галеон) - вполне работает.

CORBA безусловно рулит. Именно потому, что стандарт - продуманный, логичный. А вот обсуждать кривости реализаций можно бесконечно (и, безусловно, GNOME должен бороться за улучшение качества ORBit-а). И в этом смысле бонобо рулит гораздо меньше - он никак не стандартизован и растет достаточно хаотически и бессистемно. А почему KDE не использует корбу - мне не очень понятно (или все-таки...?).

Кстати, а как реализован просмотр ОО-документов в конкверере? Сделан честный мост KPart-OOo?

Бонобо НАД CORBA. По сути, это набор idl и их реализация. Опять же, мне не очень понятны отношения между bonobo и стандартным сервисом компонентов CORBA (вроде, такой был определен OMG - или я вру?)

2svu
По поводу KPart и Bonobo я не спец. Но, вроде KDE не исп. CORBA из-за ее сложности в реализации и поддержке - это как стрельба из пушки по воробьям.

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

Кстати, CORBA дает возможность приложениям достаточно удобно и кроссплатформенно (настолько кроссплатформенно, насколько кроссплатформен сам GNOME) организовывать любой тип (не только компонентный) межпроцессного взаимодействия. Что в этом случае делает KDE? Каков стандартный механизм IPC в KDE?

2ANDI: > Окно настроек часов - это как раз один из немногих примеров неудачного
> дизайна в КДЕ.
Это где он неудачный? Вы бы хотели ходить строем и настраивать только шрифт в часах? Я (и не только я) - не хочу. KDE ориентирован на ПОЛЬЗОВАТЕЛЯ. И надо радоваться, что каждому пользователю найдётся то, что по вкусу. И ему не надо лезть в жёсткие рамки программ, разработанных ленивыми программерами. Так что лучше будет настраиваемо, чем топорно.

> Каков стандартный механизм IPC в KDE?
DCOP
http://developer.kde.org/documentation/library/kdeqt/kde3arch/dcop.html
Кстати, а можно рулить Гномовским CORBA через консоль и GUI (dcop/kdcop)?

>Это где он неудачный? Вы бы хотели ходить строем и настраивать только шрифт в часах? Я (и не только я) - не хочу. KDE ориентирован на ПОЛЬЗОВАТЕЛЯ. И надо радоваться, что каждому пользователю найдётся то, что по вкусу. И ему не надо лезть в жёсткие рамки программ, разработанных ленивыми программерами. Так что лучше будет настраиваемо, чем топорно.

:) Мне нравится KDE, то я не собираюсь из-за этого закрывать глаза на его недостатки.

>Компонентная система - необходимая часть любого приличного десктопа.
Ой ли! То есть, MacOS в этом отношении не полноценна?
По-моему, все это лишнее и только утяжеляет десктоп, создавая отрицательную репутацию Гному и КДЕ в частности.

>И ничего Вы с этим не поделаете. То, что KPart неполноценна (как мне неоднократно объясняли), а bonobo местами кривовато - никак не опровергает общую идею.

Никто с этим не спорит.

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

Кстати, не прокомментируете ли, почему Вам нужно настраивать параметры внешнего вида в каждом апплете независимо? Почему Вас не устраивают настройки темы?

Спасибо за указание на DCOP. Посмотрю. Только прямо на первой же страничке заявляется, что DCOP is built on top of the Inter Client Exchange (ICE) protocol, which comes standard as a part of X11R6 and later. Значит ли это, что DCOP не работает под Windows? Как же быть со знаменитой кросс-платформенностью KDE - или я что-то путаю, и только Qt кроссплатформен? Впрочем, это все мелочи.

Другой вопрос - а чем именно Вы хотите рулить? В принципе, можно написать консольную прогу с использованием glib/orbit. А зачем?

Интересно, а на MacOS не было OLE? Как же там MSOffice работал?:)

Да, я не знал, что своей компонентной модели там нет. Действительно, с этой точки зрения она меня удивляет своей неполноценностью:). А как же там вообще сложные документы делать (самая очевидная задача компонентной системы на десктопе)?

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

Вот, и я о том же.

>Значит ли это, что DCOP не работает под Windows?
Я думаю, да, не работает.

>Как же быть со знаменитой кросс-платформенностью KDE - или я что-то путаю, и только Qt кроссплатформен?
Только Qt. (если под другими платформами мы подразумеваем Windows).

>Да, я не знал, что своей компонентной модели там нет.
Это мое предположение, судя по тому, что, если верить, они занялись KParts.

>Действительно, с этой точки зрения она меня удивляет своей неполноценностью:). А как же там вообще сложные документы делать (самая очевидная задача компонентной системы на десктопе)?

Наверно, в пределах MS-офиса таки работает и OLE, если MS решилась его портировать.
Если нет - то тогда наверно никак.
Вообще тут Irsi явно не хватает)

А разве создание сложных документов невозможно обеспечить без компонентов ?
А зачем тогда существуют библиотеки?

Ну, под кроссплатформенностью мы еще и Заурус подразумеваем:)

А, а я думал Вы точно про MacOS знаете... Irsi, помогите, может, Вы что-то про это знаете? Типа, ау...

Библиотеки - это очень полезно (и, кстати, бонобо умеет работать не только out-proc, но и in-proc). Только нужен унифицированный интерфейс. Невозможно работать в мире, где интерфейс visio.dll отличается от интерфейса excel.dll. Точнее, можно - но такая система абсолютно не расширяема. А вот продумать интерфейс так, чтобы работало для любого типа компонента - это надо СИЛЬНО подумать. И результат будет называтся вашей компонентной моделью. Так что библиотеки - это просто нижний уровень, технологическая среда. А компонентная модель - верхний уровень, концептуальный подход.

я тут немного не в тему влезу, но вот меня давно интересует вопрос такого плана: как бы грамотно поставить гном без всяких garnome (те из rpm) просто там все одно за одно цепляется, замучался уже. Насколько все-таки portage в этом отношении лучше!

>Библиотеки - это очень полезно (и, кстати, бонобо умеет работать не только out-proc, но и in-proc). Только нужен унифицированный интерфейс. Невозможно работать в мире, где интерфейс visio.dll отличается от интерфейса excel.dll. Точнее, можно - но такая система абсолютно не расширяема. А вот продумать интерфейс так, чтобы работало для любого типа компонента - это надо СИЛЬНО подумать. И результат будет называтся вашей компонентной моделью. Так что библиотеки - это просто нижний уровень, технологическая среда. А компонентная модель - верхний уровень, концептуальный подход.

Ок. Учитывая то, что на сегодняшний день имеется уже более 4 комонентных моделей, несовместимых между собой, то зачем вообще такая компонентность нужна? Как вы можете объяснить пользователю, что вот этот компонент из OpenOffice не работает, предположим, в Abiword, а bonobo и KDE вообще никак скрестить нельзя. Чем ему (пользователю) такие компоненты могут быть полезны, если они все равно остаются "вещь в себе"? Как может быть Linux-desktop однообразен, если только на сегодняшний день имеется 3(?) компонентных моделей?

Вот это и заставляет меня считать, что необходимость использования компонентов в тех-иных случаях следует рассматривать индивидуально. И в этих случаях стараться ограничиться использованием библиотек, а не изобретать очередного монстра. Пример - OpenOffice. Я не смотрел его исходный код, но думаю, что можно было бы ограничиться одними библиотеками (родными!), а не создавать свою ни с кем не совместимую объектную модель...

А потуги в этом направлении разработчиков Gnome и KDE - дань моде IMHO.
К сожалению.

То, что сегодня на линухе мы имеем 3 модели - действительно беда. Но все-таки я бы был очень огорчен, если бы ООо не создал своей (единственной реально работающей кросс-платформенной!) компонентной модели - к тому же, им все равно приходится работать с OLE - так уж лучше (правильнее) это делать в виде моста из одной компонентной модели в другую. Да, нужны мосты. Был (заглох) проектик моста из ООо в бонобо. В принципе, это возможно - просто никто, увы, этим не занимается. KParts, не являясь полноценной компонентной моделью, скорее всего, не может участвовать во "взаимовыгодном обмене компонентами" (впрочем, рад буду ошибиться). Короче, компонентные модели - нужны. То, что их много - неприятность. Но эту неприятность можно уменьшать созданием хороших мостов. И "потуги" - это не "дань моде". Вы так мне и не ответили - как обеспечить единство интерфейса visio.dll (abiword.so) и excel.dll (gnumeric.so), не прибегая к компонентной модели?

>То, что сегодня на линухе мы имеем 3 модели - действительно беда. Но все-таки я бы был очень огорчен, если бы ООо не создал своей (единственной реально работающей кросс-платформенной!) компонентной модели - к тому же, им все равно приходится работать с OLE - так уж лучше (правильнее) это делать в виде моста из одной компонентной модели в другую. Да, нужны мосты.

Ну вот. Теперь программистам кроме собственно создания своей "что ни на есть самой" компонентной модели нужно создавать мосты ко всем имеющемся... Не проще ли было прилинковать библиотеку напрямую?

>Был (заглох) проектик моста из ООо в бонобо. В принципе, это возможно - просто никто, увы, этим не занимается.

Лично я таким не стал бы заниматься. То есть, я хотел сказать, что понимаю тех, кто бросил это. (А можно было и не начинать)

>KParts, не являясь полноценной компонентной моделью, скорее всего, не может участвовать во "взаимовыгодном обмене компонентами" (впрочем, рад буду ошибиться).

Я тоже так думаю. То, что KParts не развивается, говорит только об одном: это не востребовано!

>Короче, компонентные модели - нужны.

Неочевидный вывод. Лично мне - нет. Да, кстати, созданием "сложных документов" я не занимаюсь. И большинство людей тоже.

>То, что их много - неприятность. Но эту неприятность можно уменьшать созданием хороших мостов. И "потуги" - это не "дань моде". Вы так мне и не ответили - как обеспечить единство интерфейса visio.dll (abiword.so) и excel.dll (gnumeric.so), не прибегая к компонентной модели?

Никак!
Потому как приложений, где необходимо использовать и abiword.so, и gnumeric.so - единицы! Возразите мне - приведите примеры, давайте посчитаем вместе.
И мне жаль, что ради "единства интерфейса" программистам приходится тратить свои силы на создание многочисленных компонентных моделей, в несколько раз больше сил на создание мостов между ними (легко сказать - создание моста. Для этого, как минимум, нужно в совершенстве знать работу двух компонентных моделей. А много таких знатоков?), и жаль пользователей, которые потом будут плеваться на Gnome&KDE и возвращаться к IceWM только из-за того, что он быстрей работает.

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

Разумеется, не нужно каждому программисту создавать свою компонентную модель. Например, я в gswitchit вполне обхожусь фиксированным интерфейсом дин. библиотек. Но проекты масштаба desktop environment (KDE/GNOME) - должны. Проекты масштаба OOo - либо должны, если хотят быть кросс-платформенными, либо нет - если могут использовать модель той платформы, где живут. Все это - про очень массивные проекты, где ресурсов много и где разработчики могут позволить себе думать о действительно динамическом взаимодействии подсистем.

Те, кто бросили bonobo-ooo - просто не нашли времени для продолжения, к тому же - проект был сделан просто как демонстрация такой возможности, не больше. Возможно, однажды проект будет возрожден (если раньше abiword не сделает хорошего компонента:).

Не знаю как там KParts, а bonobo разивается. Особено этому способствует наутилус. Да и abiword/gnumeric вовсю используют это дело.

Примеры приложений, говорите...

# ls /usr/lib/bonobo/servers/ | wc -l

107

# rpm -qf /usr/lib/bonobo/servers/* | sort |uniq | wc -l

46

107 cерверов из 46 пакетов (кстати, это и про "невостребованность большинством разработчиков"). Но это только компоненты. Посчитать контейнеры так просто, наверное, не удастся. Но очевидно, что обычно это либо навороченные файл-менеджеры, либо офисные проги. Конечно, возможны и извраты типа keyboard layout preview в gswitchit (и сама возможность таких извратов - тоже удобна).

Да, написание моста может, дело и непростое (ни разу не пробовал:). Но, как мы выяснили, реально сегодня нужно 3 моста, при этом возможность построения 2-х из них (для KParts) - под вопросом. Это не ТАК много. Кстати, скорее всего построением моста KParts-bonobo будет заниматься freedesktop.org. Или они вообще договорятся о каком-нибудь хитром выверте, чтобы стандартизовать компонентную модель под иксами (например, на основе DBus).

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

А приложения, кстати, иногда упрощаются - особенно "маленькие". Мой пример - я не должен был искать доки на API ggv (или даже сырцы читать) - мне вполне хватило idl и тех базовых интерфейсов bonobo, которые ggv реализует. Другое дело, что реализация оказалась не без проблем - но тут уж компоненты не при чем (хотя, конечно, можно попробовать обвинить bonobo в том, что она провоцирует писателей компонентов на ошибки - но это уже про продуманность конкретной архитектуры).

> То, что сегодня на линухе мы имеем 3 модели - действительно беда

еще 5 копеек: mozilla предлагает свою компонентную модель -- XPCOM; Java -- JavaBeens, Kylix -- CLX.

> как обеспечить единство интерфейса visio.dll (abiword.so) и excel.dll (gnumeric.so), не прибегая к компонентной модели?

при помощи патенов Bridge или Fasade например (если я правильно понял, речь шла о программных интерфейсах, а не о GUI. последнее возможно только тогда, когда обе библиотеки будут использовать одинаковые гуерисовальные тулкиты, ну или похожие скины, что к используемой модели не отностится. :) ).

># ls /usr/lib/bonobo/servers/ | wc -l
>107

В последнее время стало модным из любого приложения делать bonobo-компонент. Ну да ладно.

>107 cерверов из 46 пакетов (кстати, это и про "невостребованность большинством разработчиков"). Но это только компоненты. Посчитать контейнеры так просто, наверное, не удастся. Но очевидно, что обычно это либо навороченные файл-менеджеры, либо офисные проги.

А интересно ведь именно количество контейнеров. Неужели это все делается ради одного файл-менеджера?

>Кстати, скорее всего построением моста KParts-bonobo будет заниматься freedesktop.org.
Вот они обрадуются, когда узнают :)

>Или они вообще договорятся о каком-нибудь хитром выверте, чтобы стандартизовать компонентную модель под иксами (например, на основе DBus).

Стандарты не изменяют своим традициям появляться после нескольких несовместимых реализаций)

>А приложения, кстати, иногда упрощаются - особенно "маленькие". Мой пример - я не должен был искать доки на API ggv (или даже сырцы читать) - мне вполне хватило idl и тех базовых интерфейсов bonobo, которые ggv реализует.

Почему бы для просмотра pdf не вызвать ggv напрямую? Или зачем, если не секрет, понадобилось в gswitchit вызывать ggv ?
А если пользователю больше нравится acrobat reader?

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

Неужели все так плохо? И в чем заключаются недостатки Bonobo?

Ну, уж Вы под одну гребенку всех запихали:) Хотя да, конечно, это все про компоненты.

А как Вы будете обеспечивать встраивание пользовательских интерфейсов. Динамическое расширение menu? А составные документы - в чисто физическом смысле, как ole storage (кстати, bonobo пока до этого не дошло)?

А где прочитать про Bridge/Fasade?

Ага! Стало модным! Значит, разработчики все-таки работают в рамках этой концепции - не так уж это геморройно!

Про freedesktop.org и мост bonobo-KParts - это только моя догадка. Просто они любят над-средные стандарты заделывать.

А стандарты действительно появляются из несовместимых реализаций - а потом эти реализации "утрясаются". Что же тут поделать? Хотя почему bonobo не взял компонентный сервис от OMG - я все-таки не очень понимаю...

Я хотел видеть preview раскладки _внутри_ моего пользовательского интерфейса - прямо рядом с виджетами настройки (acrobat reader отдыхает). xkbprint сгенерил ps, дальше я его запихиваю в ggv-control. Проблема оказалась только в том, что bonobo controls (и ggv) плохо живут в условиях, отличных от bonobo window - но это уже детали кривостей архитектуры и реализации.

>А как Вы будете обеспечивать встраивание пользовательских интерфейсов. Динамическое расширение menu?

Я не думаю, что встраивание пользовательских интерфейсов является действительно хорошей затеей. Поэтому я старался бы избежать этого вообще или использовал бы запуск внешнего приложения. Также всегда можно БЫСТРО сделать маленький API для данного конкретного случая и его использовать. Впрочем, так всегда и делалось...

Да и вообще лучше <a href="..."> :)

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

>Ага! Стало модным! Значит, разработчики все-таки работают в рамках этой концепции - не так уж это геморройно!
Я вобщем-то только о Gnome-разработчиках говорил. Наверно, каждому просто хотелось, чтобы его приложение кто-нибудь когда-нибудь куда-нибудь встроил :)

>Я хотел видеть preview раскладки _внутри_ моего пользовательского интерфейса - прямо рядом с виджетами настройки (acrobat reader отдыхает). xkbprint сгенерил ps, дальше я его запихиваю в ggv-control. Проблема оказалась только в том, что bonobo controls (и ggv) плохо живут в условиях, отличных от bonobo window - но это уже детали кривостей архитектуры и реализации.

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

Угу. И еще с функциями зума и поворотов. И потом еще уважаемый Jaka однажны поломает этот API - добавит или уберет функции. Нахрен. У меня есть Bonobo:Zoomable и другие Bonobo: интерфейсы - и я с ними работаю. Собственно, если завтра Acroread начнет их имплементить, или другой ggvplus появится - мне будет все равно, я и с ними работать буду. Например, с pdf так и было - сначала в gnome его обрабатывал ggv, потом появился gpdf. И если бы xkbprint выводил pdf - моя прога бы даже не заметила подмены. БОльшая стабильность интерфейсов - одна из положительных сторон компонентных моделей. Чтобы поменять интерфейсы bonobo - это нужно убедить многих. Чтобы поломать интерфейс конкретной либки - нужно просто проставиться пивом ее хозяину.

Так я о чем и говорю. Каждое приложение, которое обрабатывает какие-то документы, считает своим долгом иметь возможность вежливо общаться с другими приложениями (nautilus/mozilla/abi/gnumeric)... Что же здесь плохого? И раз среди разработчиков это модно - значит, и сложности явно не превышают полезного эффекта (или хотя бы интереса и желания наиболее тесной интеграции в платформу)?

Кстати, так ли популярны KParts в KDE, как bonobo в GNOME?

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

Должен это признать. Таки да. Для API это важно. Но при стабильном API это не сильный аргумент.

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

Лично я в шоке :((( Решил таки пересесть с 1.4 на 2.4(пробовал раньше и на 2.0 и на 2.2 - возвращялся к 1.4)... И что? Опять все гораздо хуже :(((

Я вот так на вскидку скажу парочку неприятностей которые просто меня из себя выводят: Windows Manager. Этот долбаный метасити ну ведь нихера не умеет а sawfish 1.3 косячит здорово(может в гноме все под метасити заточено). А как плохо жить без хоткеев на все что угодно :( Окошки постоянно терят фокус(при переключение между рабочими столами и тд) что очень бесит. Окошки не умеют автоматом магнититься к другим(как в sawfish), а если и умеют то как то тупо и с shift'ом что бесит еще больше(может еще педали для этого придумать?). Панели. Если раньше настраивалось все что хочешь(анимация, скорость сокрытия и тд) то сейчас я даже разместить панельки не могу по краям - либо в центре либо во всю ширь...

В общем ужас охеренный. Нахера они так все залажали? Я понима - красиво и все такое... но Нахера нам еще один КДЕ - ну неудобно же...

Может посоветует кто нить бывшему гномовцу, идеалом для которого был Gnome 1.4 ???

Где же на нынешнем десктопе взять стабильный API? Только Xlib:)

Хоткеи можно через gconf-editor задавать (что я и делаю). Про остальное не знаю, не искал.

А KDE не оскорбляйте - у них с usability совсем другие отношения.

Все, что могу посоветовать - лезть в desktop-devel по каждому удобному поводу и ругаться. Только они уже это все проходили - их так просто не проймешь. Еще требовать фич в виде багов в багзилле. А куды деваться?

> Только все-таки по любым нормальным стандартам пользовательского интерфейса
> ... - это сильный перебор (соотношение функциональности системы - показ
> времени - и кол-ва настроек)
Ну давайте sendmail.cf или httpd.conf укоротим до трёх строчек! Зачем столько настроек? Поймите, проприетарные ОС гребут всех под одну гребёнку. Зачем им подстраиваться под каждого пользователя? В ломы - надо писать дополнительный код и пр. KDE имеет столько настроек поскольку стоит к конечному пользователю лицом, а не задом. Кстати, никто вам не мешает туда (в настройки) лазить вообще. Запускайте kpersonalizer и меняйте общий стиль работы.

> И совсем не потому, что MacOS не знает, что такое удобный интерфейс.
А одной кнопки мыши вполне достаточно для удобной работы. Ага! :)

> почему Вам нужно настраивать параметры внешнего вида в каждом апплете
> независимо?
Потому как это специфичные для данного аплета настройки. Умолчательные настройки меняются в стиле.

> Значит ли это, что DCOP не работает под Windows?
KDE портирован под Windows, однако не думаю, что совместим с подобными службами Windows.

> Другой вопрос - а чем именно Вы хотите рулить? В принципе, можно написать
> консольную прогу с использованием glib/orbit. А зачем?
Чтобы рулить и получать данные из консоли, а не прыгать по меню. И не надо ручками лабать программу. В скриптах обрабатывать рульнее.. :)

> Кстати, так ли популярны KParts в KDE, как bonobo в GNOME?
Да, даже более того! :)
После выхода KDE 2.x процесс переписывания на совместимую с KParts реализацию принял масштабы эпидемии. Зато сейчас в Konqueror можно хрен-знает-что посмотреть безо всякого геморроя. И компонент Kate используется как редактор во всех мыслимых местах. Зато программировать стало НАМНОГО проще...

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

Ну, как здесь уже писалось, для продвинутого юзера это может и лицо, а для простого смертного - самая что ни на есть ж%па!

> а для простого смертного - самая что ни на есть ж%па!
А вы спрашивали этого самого "простого смертного". Того, который в настройки сам не полезет. Ему достаточно kpersonalizer. Вот и получается, что KDE доступен для понимания любому пользователю: как простому смертному, так и нерду :))

Вы действительно считаете, что сложность (кол-во параметров) настройки апплета часов должна быть сравнима со сложностью настройки веб-сервера?

И я ни разу не слышал от пользователей Маков о том, что им мало одной клавиши. Разумеется, только пользователи иксов знают, что НА САМОМ ДЕЛЕ нужно 3 (без учета колесиков - причем в обе стороны:).

И Вы действительно считаете, что каждое приложение должно иметь возможность иметь вид, отличный от вида темы? Т.е. нужно тратить ресурсы на то, чтобы сделать десктоп как можно более "попугаистым"?

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

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

Кстати, судя по тому, что скрипт написать можно, но никто этого не сделал (насколько я знаю) - я делаю вывод, что это реально никому не нужно. Задача управления гуевыми приложениями из не-гуя никого не прельщает. А негуевых клиентов bonobo я не знаю.

> сложность (кол-во параметров) настройки апплета часов должна быть сравнима со
> сложностью настройки веб-сервера?
А вы считаете, что настройки часов и их функциональность надо делать так, как в Windows? Бррр! Мне такое ограниченное Г... не нужно. Зачем ограничивать использование часов, если есть спрос? К тому же настройки разумно разбиты по вкладкам...

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

> Т.е. нужно тратить ресурсы на то, чтобы сделать десктоп как можно более
> "попугаистым"
KDE гибок, а не попугаистен. Мы не хотим идти по пути Gnome, слепо копирующего XP с его ограниченностью... :)

> Ну и хорошо, что портирован. Тогда пусть поменяют надпись на первой странице:)
Порт под Windows неофициален и нестабилен. Да и политика использования QT на Виндах отличается. В общем, политически верно не напоминать на первой странице про порт на Windows... :)

> А скрипт, конечно, можно написать - благо, привязок к скриптовым языкам в гноме
> хватает. Вроде, из перла дергать орбит вполне можно. Устраивает?
Писать программу? На низком уровне? Эх, не заботятся Гномовцы о разработчиках...
Мне проще написать прямо из командной строки:
dcop kalarm kalarm-mainwindow#1 restore
И не надо ни каких самописанных программ :)
Все интерфейсы визуально можно посмотреть и запустить kdcop. Лепота!