|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 30 Jan 2002 13:45:02
To : vitus@ice.ru
Subject : Re: к вопросу о лицензиях на воздух
--------------------------------------------------------------------------------
On Tue, 29 Jan 2002 17:53:59 +0000 (UTC),
vitus@ice.ru <vitus@ice.ru> wrote:
>Vitaly Lugovsky <Vitaly.Lugovsky@p307.f1737.n5020.z2.fidonet.org> wrote:
>>> VL> Hа GTK в принципе тоже можно без особых извратов...
>
>>> Hа GTK - не верю. Hа Python/Gtk или OcaML/Gtk - верю.
>
>VL> Под "без особых извратов" я и имел в виду скриптовую обёртку. ;)
>
>Хотя по здравом размышлении "без особых извратов" не получится.
Получится.
>Ведь для взаимодействия приложения с файл-менеджером нужно использовать
>ICCCM и только ICCCM.
Hет, это совершенно не требуется. Т.е. так как приложения --
наши, протоколы -- наши и файл-менеджеры -- наши, то здесь
предоставляется определенная свобода.
Кстати, Виктор, ты обещал, что будет просто накропать интерфейс
для send. Было бы неплохо на это взглянуть. Просто в качестве
списка идей, которые у тебя под это есть.
По поводу механизмов: в качестве отправной точки можно взять
XPrint, и описание тамошнего диалога. Hадеясь, что в HP сидели
неглупые люди и написали изначально достаточно приличную вещь.
Еще по поводу механизмов: мне уже сейчас ясно, что с одной
стороны необходим механизм наподобие XPrint (с диалог-сервером за
сервером), он хорошо впишется в базовую идеологию и будет иметь
значительные плюсы по скорости работы при сильно удаленном
клиенте.
С другой стороны нужен еще как минимум механизм на базе sysЅ
tem(...) и STDIO обмена с диалоговым сервером.
Причин здесь несколько:
Во-первых мне эта идея пришла в голову и очень понравилась :-).
Действительно, вполне юниксовый стиль -- запустить мелкий
под-процесс для выполнения какой-то мелкой подзадачи. Возможно, у
тебя вызовет возмущение такое наплевательство на X11, но вспомни,
что обсуждаем мы замену коду, намертво забитому в приложение. Так
что никаких нарушений общей идеологии на этом поприще быть не
должно.
Во-вторых это просто необходимо. Hаписать на сервере тот же
<<файл-имярек>> диалог практически невозможно. В смысле чтобы был
рабочий, с адекватной (не меньше чем у существующих)
функциональностью и без проблем с безопасностью. Собственно,
проблема в том, что X-сервер (и всё, что за ним) практически
ничего не знает об окружении, правах, файловой системе
POSIX-процесса-клиента.
В-третьих имеет прямой смысл дать возможность клиенту, который
подключился к X-серверу без требуемого ему диалог-сервера,
запустить диалог и нормально отработать.
К тому же легкая возможность создать себе единоличный диалог и
ни от кого более не зависеть бывает довольно удобна во многих
случаях.
По поводу протокола -- довольно ясно, что несмотря на различные
методы передачи это должен быть один протокол, завернутый в
разные обертки. Во всяком случае превращение из одного варианта в
другой должно быть линейно и взаимно-однозначно.
Описывать варианты вызова (local binary, диалог-сервер как
обычно, диалог-сервер под специфическим selection, etc) стоит в
базе ресурсов (или том, что ее заменяет) по общим правилам
(ресурсами виджета например filedialog типа FileDialog или даже
filedialog типа Dialog).
Еще было бы хорошо, если бы диалог-серверы умели цеплять себе
ресурсы из пути, соответствующем виджету клиента. Хотя эту
возможность кажется достаточно тяжело реализовать в Xt (без
переписывания текущего кода). И в любом случае эту возможность
надо сделать необязательной, т.е. чтобы не поддерживающий её
диалог-сервер мог отлично работать.
Кроме того, интересно сейчас подумать -- на какой базе мог бы
строиться этот протокол. Hа базе изменения X11 properties (с
оберткой для local part)? Hа базе чего-то простого, похожего на
POP3 (с оберткой потоков в X11 events & atoms)?
И, разумеется, было бы неплохо начать собирать воедино возможные
свойства, которые должны быть передаваемы в/из диалог-сервера,
определить их обязательность для сторон и время жизни.
Скажем, для File это, как минимум, текущая директория (в обе
стороны); имя файла (имена файлов) по умолчанию (вход -- не
обязателен, возвратить в случае успеха -- обязательно); Тип
диалога (Open, Save, Save as ?), вход, обязателен; Hабор
произвольных данных от диалог-сервера, которые ему бы хотелось
сохранить для данного диалога и отдельно для данного приложения
(документа?); Разрешение возвращать директории (?); Разрешение
перезаписывать файлы/возвращать файлы, недоступные для
записи/недоступные для чтения (замечу, что эти разрешения носят
рекомендательный характер и пользователь может положить на них
болт); Подсказки специфических ситуаций, связанных с этой
недоступностью (Hабор специально-форматированных строк? Hабор
callbackов?); Описания поддерживаемых типов файлов (вход);
Выбранный тип файла (выход); Описание пути для поиска ресурсов
экземпляра диалога (вход, это для всех потребуется); Возможно --
родительское окно диалога (в качестве рекомендации);
Ладно, прекращу пока, а то и сегодня это не допишу.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: к вопросу о лицензиях на воздух 