Re: [sisyphus] Re: qt (KDe, amaroK) vs automount (subfs?) /media/cd ? [JT]

[Alexey Morozov <alex-altlinux@idisys.iae.nsk.su>]

[-- Attachment #1: Type: text/plain, Size: 3778 bytes --]

On Thu, Mar 24, 2005 at 09:22:45PM +0300, Vitaly Lipatov wrote:
> > Вы поверите, что 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 может слыхом не слыхивать.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]