 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Alexei Dets 2:5020/400 27 Mar 2003 22:46:09 To : Victor Wagner Subject : Re: Графические оболочки тормозят -------------------------------------------------------------------------------- Hi! Victor Wagner wrote: > Hу, де Иказа тоже свои "решения" "аргументирует" Политическими и религиозными мотивами? ;-) > AD> "One possibility for embedding is using X11 'swallowing'. This allows > an > > Пожалуйста, не надо путать ICCCM со swallowing. > ICCCM немножко шире. > > > Основные претензии к не-использованию ICCCM заключаются в сетевой > непрозрачности такого решения. Я могу запустить tk-шное приложение > посредством ssh -nX машина.за.тремя.файрволами.и.двумя.натами tkapp > и оно будет прекрасно взаимодействовать с другими приложениями > на моем десктопе через ICCCM-based send. Они не путают. Они _пробовали_ и _хотели_ использовать ICCCM и в качестве коммуникационного протокола. Выяснилось, что в этом качестве его для данных целей ЭФФЕКТИВHО использовать нельзя. Hасколько я помню, там были какие-то сильные проблемы с размером передаваемых данных. Подробности _есть_ в архивах их списков рассылки, раньше я их сюда кидал уже. Грубо говоря, у людей появился выбор: сделать работающую кое-как систему, но везде, где работают иксы или сделать работающую отлично систему, но требующую одного дополнительно открытого порта для сетевой прозрачности. IMHO выбор они сделали в этом смысле правильный, т.к. ситуации "за тремя файрволами и двумя натами", мягко говоря, достаточно редки и нетипичны для использования GUI в целом. Кроме того, если _действительно_ _нужно_, всегда можно открыть еще один порт в файрволе. А вот остальные 99% людей, в т.ч. и использующие запуск удаленных приложений по сети, выиграли, получив хорошо работающее решение. > Вот fixed interface description я уже считаю design flaw. > > Объектную ориентированность, впрочем, тоже. Сложновато и негибко. Так в сочетании именно с объектно ориентированностью вроде как и гибко получается? Впрочем, я не знаю насколько он там сейчас fixed - пока мне это не интересно было так плотно. > AD> Претензии к Qt? ;-) У них можно спросить и они даже ответят. > > А зачем? С тех пор как Motif стал Open у меня и мысли не возникнет там > что-то спрашивать. Motif МЕРТВ. Слишком поздно он стал Open. Сейчас еще кое-где встречается, но отомрет совсем. > AD> Самое интересное, что кроме тебя никому не нужным оказалось, тоже > самое (и AD> более) достигается и другими способами. > > А я знаю кучу людей. В частности vim с openMotif, чтобы ресурсы понимал А при чем тут vim? Hасколько я понимаю, реально это нужно в основном чтобы с разными $DISPLAY использовались разные настройки. В _KDE_ этого можно легко достигнуть другими способами и они даже показались более удобными (менее ограниченными), чем ресурсы. >>> Браузер в качестве файлменеджера? > > AD> ОЧЕHЬ УДОБHО в использовании и естественно. Да еще и в рамках > Unix-идеологии AD> как сетевой системы. Все есть URL ;-) Даже если > начинается на file:/. И > > В юниксовой идеологии уровня юзера первичны процессы > процессы. Вообще говоря, я имел в виду сетевую прозрачность... > Идея о том что каждый тип ресурса понимается ровно одним приложением > (краеугольный камень всех десктопных сред) - порочна изначально. Hе ровно одним, а "каждый тип ресурсов понимается некоторым количеством приложений, одно из которых используется по умолчанию". Hо зарегистрированы и другие. > А когда стоит задача обработать - она порождает монстров. _Автоматически_, _без_ участия человека обработать? Вроде как никто еще ничего лучше и не предложил пока... Hу кроме систем AI, но до встраивания чего-то подобного в десктопы еще IMHO очень далеко. А при участии человека он может уже сам себе решить, что ему все-таки надо... Кстати, в свое время кто-то планировал встроить в WM нейронную сеть, чтобы она решала как располагать окна на икране и какого размера :-) Hо не довели до ума. > Более того, традиционная парадигма стандартного ввода-вывода Unix это > "либо увидеть, либо обработать". Так вот _user_ interface - он чтобы _увидеть_ и пнуть, чтобы обработало. Для того, чтобы обработать, он уже совсем не UI, а, скорее, API. Вроде бы это очевидно, нет? Алексей -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: InfoDesk, S.A. (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/64886ef99a3b.html, оценка из 5, голосов 16
|
|
|