|
|
Вступление
Алексея Морозова опять "достали" в рассылке sisyphus@altlinux — результатом стала очередная серия писем, каковые и приводятся ниже. :-)
> Но - в qt поддержку всего этого вряд ли будут вносить? А заодно в GTK, FLTK, Tcl TK и т.д.
> А значит проги типа Оперы, не привязанные к конкретному D.E. будут в пролете.
> Точнее они должны будут специально заморачиваться - а скорее всего не будут,
> ибо в других операционках не будет HAL/D-BUS и необходимости явной попытки
> монтирования каждой папки :-(
Вам достаточно будет узнать, что принципы работы HAL’а совсем другие,
или требуются более подробные пояснения? В принципе, все, что нужно
можно прочитать здесь:
cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html
> > Удивляет возможность обсуждения без понимания принципов
> > работы.
> Я только хотел сказать, что на мой взгляд, принцип работы с
> дисками должен состоять в том, что поддержка их монтирования не
> должна встраиваться в KDE/GNOME и пр.
Вы поверите, что "привязанность" к KDE выражается только в использовании
инфраструктуры KDE (библиотек, стандартов, например, на механизмы
нотификации итп) и наличия живых привязок к библиотеке d-bus для
Qt/KDE event-loop’а? Аналогично для GNOME.
В принципе, А. Фролов собирался написать клиент HAL для WindowMaker’ного
окружения. Его остановило только то, что на данный момент нет
готовой библиотеки/способа, позволяющих "встраивать" обработку
событий d-bus в обработку X’овых событий. Для glib и qt (а заодно
и других технологий программирования) такая привязка уже создана.
> Действие "зайти в каталог" в командной строке не должно быть
> сложнее тыкания куда-то там в KDE.
Вы поверите, что HAL - это ни разу не про автомаунт в том его понимании,
которое используется в submount/supermount?
Монтирование, как и любое другое действие там происходит не в момент
обращения к каталогу, а в момент, когда уполномоченная программа
получает соответствующую нотификацию/требование.
Вообще, похоже, начинает складываться некая urban legend относительно
того, что умеют, а чего не умеют новые модные технологии. И легенда
эта скорее ближе к мифологии и бабушкиным сказкам в пересказе матерых
(или матереющих) администраторов компьютерных систем, чем к тому, что
происходит на самом деле. Раньше пугали кащеем и букой, а
теперь - тем что в каждое приложение, даже на винде, нужно будет
встроить код, монтирующий каталог перед открытием данного каталога.
P.S. Ссылку на архитектуру и API я привел в соседнем письме.
> > Вы поверите, что HAL - это ни разу не про автомаунт в том его
> > понимании, которое используется в submount/supermount?
> В данный момент мне всё равно что такое HAL, безразличны его
> понятия и понимания.
Ну, тогда оставайтесь, пожалуйста, на местах до полной остановки
самолета. К выходу вас пригласят.
> Результат нашей работы должен быть прост и очевиден:
> вставил диск/дискету/флэшку/фотоаппарат, перешёл в каталог
> (cd/konqueror/nautilus) и увидел файлы.
Так оно и есть, причем, уже сейчас.
> > теперь - тем что в каждое приложение, даже на винде, нужно
> > будет встроить код, монтирующий каталог перед открытием
> > данного каталога.
> Не совсем так, но похоже - иначе к чему разговоры о встраивании
> поддержки HAL в KDE/GNOME/WindowMaker при обсуждении
> монтирования.
Очень просто. Я, что характерно, уже писал об этом. Повторюсь.
HAL предполагает, очевидным образом, взаимодействие с пользователем,
Взаимодействие это может быть разным, от нотификаций о появившемся
устройстве и точке/точках его монтирования до запуска CD-плеера
для вставленных звуковых дисков.
Взаимодействие это, желательно, должно выглядеть "естественно" для
выбранной пользователем рабочей среды, то есть, во-первых, настраиваться
единообразно с остальной средой, а, во-вторых, использовать библиотеки
и методологии (различного рода треи, механизмы нотификации пользователя
итп), принятые в данной среде.
Основой для реализации возложенных на HAL задач послужил механизм обмена
сообщениями D-BUS. Для библиотеки dbus в данный момент, существует,
во-первых, низкоуровневый API, во-вторых, привязки к различным языкам и
средам программирования: python, mono, gcj (2Pavel Mironchyk: ПЕРЕСОБЕРИТЕ,
пожалуйста, mono!), - и, в-третьих, "высокоуровневый API": интеграция с glib
и qt mainloop’ами. Для других widget set’ов и технологий программирования,
также использующих парадигму циклического диспетчера событий, такой
интеграции в данный момент нет, хотя, разумеется, она возможна.
Танцевать можно, по словам Хавока, от привязки к glib.
Итак, схематично новый механизм работает следующим образом:
-- --
| Клиент HAL, осуществляющий нотификацию пользователю, |
| монтирование и другие действия по получении события |
| от демона HAL. Желательно с точки зрения пользователя, |
| чтобы этот клиент вписывался в среду данного пользователя |
-- --
/\
||
| Транспорт (системная шина D-BUS) |
||
\/
-- --
| Демон HAL, формирующий списки устройств и их свойств на |
| данном компьютере и события по изменению этих списков |
---------------------- |
/\ | |
|| | Наблюдение за устройствами (поллинг), |
\/ | не управляющимися через Hotplug |
-- -- | (CD-диски, кард-ридеры, всякие хитрые |
| Hotplug | | PCMCIA-устройства итп) |
-- -- -- --
Соответственно, в данной схеме "привязанным к декстопу" является
только клиент HAL. Причем, привязка эта, во-первых, необязательная
(никто, в принципе, не мешает использовать, тот же kvm из-под
WindowMaker, разве что, неудобно будет). Во-вторых, сам клиент
строго ограничен по функциональности, и выполняется, скорее всего,
в виде апплета, при этом остальная среда о HAL может слыхом не слыхивать.
@ 17.04.2006 20:56
См. тж.
