Редактирование: UNИX, осень 2007, 06 лекция (от 09 ноября)

В прошлый раз был рассказ про клиент-серверную модель, ей больше 20 лет. И то ли потому, что эту разработку подхватил МИТ, то ли люди, которые занимались этой разработкой, не поскупились на ум, что архитектура оказалась настолько всеобъемлющей, что ещё 3---4 года назад в ней не надо ничего менять, и другие оконные системы потихоньку догоняли, вот, в Висте анонсировали передовую технологию --- ядро отдельно от оконной системы, хотя бы частично. Но, тем не менее, особенно с выходом очередного МакОС 10 выяснилось, что Х.Орг надо бы доработать. Доработать в части программно-интерфейсной, например, там не специфицировано, что такое иконка.

== Организация рабочего стола ==

Кроме праймари буффера есть секнодари и дерево подбуферов... Х11 это такая программа, которая за 25 лет обросла таким количеством вещей, что никто уже и не помнит, что это и зачем.

* XhotKey --- поддержка горячих клавиш

== Потребность в объектной модели ==

* Startup-shutdown notification --- если в консоли интерфейс управления совмещён с интерфейсом передачи данных, и там явно видно, когда запустилось приложение, как оно работает и как умирает; в случае с оконной системой действия по запуску и завершению могут никак не обозначаться визуально. В принципе, если бы народ соблюдал некую дисциплину программирования, то это можно было бы организовать даже на уровне наборного десктопа: был такой xtoolwait, который ждал, пока запущенное приложение зарегистрирует окно через xtool. Это решение, которое позволяет разруливать race condition, но возникает непонятное требование использовать xtool, ну и отслеживать хочется не только запуск.

Ни одна из этих задач не является неразрешимой, отличие в том, что если предыдущие задачи решаются в соответствии со стандартом х11, то есть, классически, и если нет у вас меню, запустили одну из десяти имеющихся, и будет вам меню, или свой photkeys, который поддерживает vaio, или ещё что-нибудь. Тут же, если хочется скопировать файл из одной программы в другую, то нужно, чтобы сначала программы договорились, нужен фреймворк. И садятся ребята и пишут фремворк, некий абстрактный рабочий стол, который оперировал бы не с окнами, а с объектами, и позволял с этими объектами работать.

В прошлом семестре говорилось, что графический интерфейс --- матрица пикселей, то рабочий стол --- работа с объектами. То есть нужна объектная модель, поверх которой всё будет работать. Так сделали ребята из кде. Кроме этого, нужна единая интерфейсная библиотека (например, qt). И если две программы написаны на qt, то они смогут обмениваться объектами. Так, собственно, и сделано в виндовсе --- там есть винапи, точнее был, пока не появился дотнет, и винапи теперь не поддерживается. Так что wine поддерживает винапи, а виндовз --- всё меньше.

== Существующие решения ==

Но тут возникает проблема: такие вещи, как интерфейс с системой, подсистема помощи, и так далее, представляете себе уровень бессмысленной работы --- дали много денег и написать огромную графическую конфигурилку для системы, которая отвечает на вопросы типа «где моя флешка», она смотрит на системные логи и показывает всё пользователю. Но чреез полгода мог поменяться формат системных сообщений, линукс тоже не стоит на месте, кде изменяется. Первая проблема в том, что взаимодействие с системой и внешними источниками активности --- задача двойная и очень большая работа. Поэтому, сколько бы не писались такие программы, это работа на вчера.

Вторая проблема состоит в том, что все программы должны быть собраны с использованием этой системной библиотеки. Если запустить гткшное приложение в кде, то (по крайней мере, лет 5 назад), общаться с ним можно не более, чем в рамках х-протокола. Потому что оно не знает о кдешной модели.

Если хочется специфицировать для всех окон сразу, то можно использовать звёздочку: *.background:gray

Artwork --- иконки. В танго уже 1500 иконок

== freedesktop ==

** Ещё не поддержано, но предлагается

 

В линуксе, а также и во freebsd используется общая шина передачи данных --- dbus. Люди, работающие с линуксом, знают её в связке с hal в качестве связки работы железа и приложений. Всё это уехало в будущее --- передавать по dbus настройки и power management.