 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Victor Wagner 2:5020/400 27 Mar 2003 00:34:52 To : Alexei Dets Subject : Re: Графические оболочки тормозят -------------------------------------------------------------------------------- Alexei Dets <adets@idsk.com> wrote: AD> Я уже где-то с полгода назад закидывал сюда ссылки на мессаги в их списках AD> рассылки, аргументировано объясняющие некоторые архитектурные решения, AD> искать снова некогда и лень. Hу, де Иказа тоже свои "решения" "аргументирует" AD> Впрочем, вот первая ссылка, что сразу попалась в Гугле: AD> http://rikkus.info/kparts.html AD> "One possibility for embedding is using X11 'swallowing'. This allows an Пожалуйста, не надо путать ICCCM со swallowing. ICCCM немножко шире. Основные претензии к не-использованию ICCCM заключаются в сетевой непрозрачности такого решения. Я могу запустить tk-шное приложение посредством ssh -nX машина.за.тремя.файрволами.и.двумя.натами tkapp и оно будет прекрасно взаимодействовать с другими приложениями на моем десктопе через ICCCM-based send. В то же время если я залогинюсь на ту же машину тем же юзером с другого X-терминала, приложения на нем не будут мешаться. AD> interface component to be run in a separate process, in fact even on a AD> remote server, but it also requires some communication mechanism, AD> preferably one that allows for fixed (class) interface descriptions. The Вот fixed interface description я уже считаю design flaw. Объектную ориентированность, впрочем, тоже. Сложновато и негибко. >> Типы selection, которые определены не как атомы с вменяемыми >> названиями? AD> Претензии к Qt? ;-) У них можно спросить и они даже ответят. А зачем? С тех пор как Motif стал Open у меня и мысли не возникнет там что-то спрашивать. AD> Самое интересное, что кроме тебя никому не нужным оказалось, тоже самое (и AD> более) достигается и другими способами. А я знаю кучу людей. В частности vim с openMotif, чтобы ресурсы понимал я не сам себе собираю. Они просто ленятся метать бисер перед парнокопытными и не поднимают шуму в чайницих эхах или дешевых компьютерных журналах по этому поводу. >> Браузер в качестве файлменеджера? AD> ОЧЕHЬ УДОБHО в использовании и естественно. Да еще и в рамках Unix-идеологии AD> как сетевой системы. Все есть URL ;-) Даже если начинается на file:/. И В юниксовой идеологии уровня юзера первичны процессы процессы. Вплоть до cat something |awk А URL-ы это откуда-то из области Commun Internet Filesystem для одноранговых сетей. Поскольку URL это извините, Resource Locator, а под ресурсом в современном мире понимается скорее документ, чем сервис. Вебсервисы - слабый аналог процессной модели Unix в мире URL который год из пеленок не выйдут. Ровно таки в силу переусложненной объектной модели интерфейсов. AD> есть единая _среда_ (konqueror сейчас это ведь все-таки именно среда для AD> встраивания компонент, а не веб-браузер), которая понимает _любой_ URL. Идея о том что каждый тип ресурса понимается ровно одним приложением (краеугольный камень всех десктопных сред) - порочна изначально. Она годится для /etc/mailcap, назначение которой - показать. А когда стоит задача обработать - она порождает монстров. Основная идея UNIX заключается в том, что для того чтобы получить результат тебе не надо видеть обрабатываемый объект. Чем меньше ты его видишь, тем лучше. Документацию читаем grep-ом, конфиги правим awk-ом и так далее. Видеть надо ровно столько, чтобы быть уверенным в результате. Более того, традиционная парадигма стандартного ввода-вывода Unix это "либо увидеть, либо обработать". -- Когда рождается пессимизм? При столкновении двух различных оптимизмов. --- С.Е. Лец --- ifmail v.2.15dev5 * Origin: Free Net of Leninsky,45 (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/15178caddfb05.html, оценка из 5, голосов 16
|
|
|