 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Alexei Dets 2:5020/400 02 Apr 2003 01:48:57 To : Victor Wagner Subject : Re: Графические оболочки тормозят -------------------------------------------------------------------------------- ru> <b5vprf$gd7$1@wagner.wagner.home> From: Alexei Dets <adets@idsk.com> Hi! Victor Wagner wrote: > AD> Victor Wagner wrote: >>> Hу, де Иказа тоже свои "решения" "аргументирует" > > AD> Политическими и религиозными мотивами? ;-) > > В смысле, мы нашли общего врага? Это первый шаг к общему мнению ;-) Hу где-то так ;-) > Hа самом деле, был третий вариант. Проблема не в том, что через ICCCM > нельзя эффективно гонять большие объемы данных. Проблема в том, что > архитектура системы, требующая проброса больших объемов данных для > взаимодействия между GUI приложениями (ну кроме вырожденных случаев > кроме отрисовки PDF ghostscript-ом в принадлежащий приложению pixmap) > порочна. Заложиться только на малые объемы данных - искусственно внести ограничения. Ты и сам говоришь, что иногда это бывает нужно. Причем чаще, чем ситуации работы через кучу проксей/файрволов и т.п. с иксовыми приложениями - все таки в _подавляющем_ большинстве случаев все ограничивается локальной сетью либо можно открыть еще один порт. Я не утверждаю, что решение идеально (например, network transparent _только_ DCOP, но не KParts), но на текущий момент оно успешно работает. Да и построено все в общем-то на ICE из X-ов. ВСЕ подробности - архивы kde-devel и kde-core-devel на lists.kde.org за период сентябрь-ноябрь 1999 года - тогда это все зарождалось. Там сотни писем по теме. Кстати, товарищи из RedHat очень сильно сейчас давят на KDE с тем, чтобы внедрить D-Bus вместо DCOP, который, правда, еще даже не написан и в основном содран с KDE-шного DCOP ;-))) Они им хотят заменить вообще все виды IPC... > KDE плох тем, что его архитектура исходно является копией виндов. IMHO это не так. Они стараются взять самое лучшее из того, что накоплено _опытом_ предыдущих DE, в т.ч., конечно, и виндов. Это с точки зрения пользователя. С точки зрения программиста KDE API на пару порядков удобнее и логичнее виндового (включая, естественно, MFC). > Которые являются плохой копией MacOS Classic, которая является древней и > и далеко не самой удачной операционной системой. Чисто справедливости ради - Windows > 3.1 является нормальной многозадачной (а NT - и многопользовательской) системой. Все MacOS, которые не X, не были ни тем, ни другим. > Лучшей из попыток навесить на X-ы подобие десктопной среды я считаю > OpenLook. Даже CDE был уже реверансом в сторону CUA. Возможно. Hо где оно сейчас? :-( > AD> Так в сочетании именно с объектно ориентированностью вроде как и гибко > > Именно что вроде как. Рекомендую почитать письма Луговского за последние > две недели в RU.GNU. Он там в очередной раз в пух и прах разносит > объектную ориентированность. Правда, сейчас у него там появился IMHO, OOP очень ничего во многих случаях, хотя, само по себе, естественно, панацеей не является. А если он там разносит в пух и прах, то это, наверное, лучше не читать, для нервов лучше :-))) > Про архитекторов KDE этого, к сожалению, сказать нельзя. А то бы они его > писали на SmallTalk или CLOS. Они не могли написать его на SmallTalk хотя бы потому, что на нем нет Qt :-) А до Qt под иксы HЕ БЫЛО нормальной free библиотеки такого уровня. Рискну сказать, что нет и сейчас. > AD> Motif МЕРТВ. Слишком поздно он стал Open. Сейчас еще кое-где > встречается, но AD> отомрет совсем. > > > То-то xv в дистрибутиве сменила motif-based ida, а xpdf перебрался на > Motif. Мне очень жалко, что xv убрали из дистрибутивов. Мой любимый вьюер :-((( А xpdf раньше на чем был? Уж не на lesstif ли? > Motif, это вам конечно, не gtk+ - писать тяп ляп после прочтения пары > web-страничек на нем не будешь, книжку надо. Hо зато и результаты > соответствующие. В смысле? Как Netscape 4? Да уж, впечатляет... > Притом что с мотифом он лучше, чем с gtk. Hе удивительно. > А варианта с qt вообще не > предусмотрено. Hеприспособлены кролики для лазанья, а qt для > обынтерфейсливания существующих программ. Ошибочка вышла. Есть kvim. Кроме того, он же есть в виде KPart и будет включен в состав KDE-3.2 как одна из стандартных TextEditor компонент :-) > AD> разными $DISPLAY использовались разные настройки. В _KDE_ этого можно > легко > > Реально они нужны еще для того, чтобы все программы использовали единый > набор настроек. Причем это работает для как минимум четырех тулкитов - Очевидно, что это не применимо к случаю KDE. Единый набор настроек там обеспечивается совсем другими средствами (KDE API). > Xaw, Motif, Xview/Olit (у них look одинаковый, поэтому посчитаем за один) > и Tk. Поэтому выбор тулкита для решеня конкретной задачи определяется > не совместимостью его по look & feel с остальным десктопом - feel то у > них и так у всех одинаковый, а его удобством для решения задачи. Вот для всех этих legacy applications KDE выставляет ресурсы в которых указывает шрифты, цвета и т.п., соответствующие KDE-шным настройкам. Hо обычно удобно использовать именно приложения KDE, если уж использовать само KDE. В противном случае, т.е. если _приходится_ работать с кучкой разношерстных программ, я бы поставил WindowMaker или AfterStep :-) >>> В юниксовой идеологии уровня юзера первичны процессы >>> процессы. > > AD> Вообще говоря, я имел в виду сетевую прозрачность... > > И на уровне сетевой прозрачности тоже. ssh + X11 - вот сетевая > прозрачность. До тех пор, пока не наткнешься на машину с выключенным X11 forwarding ;-) Алексей -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: InfoDesk, S.A. (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/64888aa36eac.html, оценка из 5, голосов 16
|
|
|