Изучение рабочего стола: продолжение

В прошлый раз говорили про то, что человек видит, впервые загрузив Линух, и эти впечатления сильно разнятся.

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

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

В прошлой части мы выяснили, что для организации рабочего стола существует следующее:

плюс всевозможные паттерны: драг-н-дроп, trash

Копирование: если есть текстовый виджет, то текст в нём можно всегда выделить, и этот текст оказывается в primary buffer. Это некий атрибут самого главного окна. При нажатии средней кнопки содержимое primary buffer вставляется в едитбокс. Недостатки:

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

Все перечисленные пункты делаются с помощью отдельных программ:

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

Что с помощью отдельных программ не делается:

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

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

Но теперь надо делать все программы с поддержкой этого всего. Иначе возвращаемся к тому, с чего начали. В итоге, каждый фреймворк имеет свою объектную модель, свою интерфейсную библиотеку, свой десктоп и свой набор ПО.

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

Таких проектов не так много, это KDE, Gnome, GNUSTEP. Среди этих трёх интересен наиболее последний, он написан действительно абстрактно от графической подложки, авторы вдохновились nextstep'ом. Проект живой, у них есть релизы, в последнем году выиграли двух студентов в google soc. Написан он на objective c (?), хороший язык, только его никто не знает.

Кроме этого, существуют пакеты программ --- KOffice, gnome office, они развиваются абсолютно независимо.

Кроме этого, существует ещё некое количество десктопов, у которых нет, например, интерфейсной библиотеки, например, xfce, которая имеет маленькая ядро и использует несколько другой способ формирования десктопа.. Ещё пример --- написали объектную модель, написали интерфейсную библиотеку и немножко софта. Таких примеров очень много. Например, windowmaker. У него два недостатка --- очень старый код и нет активного мэнтейнера. Есть ещё разные *box'ы и особняком enlightenment.

Скорее всего, то, что вы увидите, будет либо гном, либо kde, реже xfce. Ещё есть rox, на который лектор в своё время возлагал большие надежды.

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

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

Всё это вплоть до настройки цветовых схем. Вот поменял фон программы. потом выясняется, что пользуешься не одной программой, а тридцатью, и как поменять у них всех? Существует xresources --- способ настройки всех иксовых программ одновременно. Организован он в виде единого дерева. Если есть окно класса window и с заголовком terminal, то к нему можно обратиться как через класс, так и через название. .window.menu:«qq» Если хочется специфицировать для всех окон сразу, то можно использовать звёздочку: *.background:gray Если бы это всё писала одна команда, то можно было договориться о едином именовании и было бы хорошо.

Проблема в том, что, во-первых, это всё лежит в корневом окне --- большая свалка, и возможны разночтения.

Решение --- общая настройка. У кде есть специальный каталог, в котором другие специальные каталоги и там хранятся настройки, у гтк свой сервис gconf, всё это несовместимо.

Сейчас народ понял, то дальше так нельзя. По двум причинам:

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

freedesktop

В момент, совпавший с разделением xfree86 и ... зародилась организация freedesktop, freedesktop.org, которая занимается двумя вещами:

Что есть в этом драфте:

Какие проблемы ещё есть:

dbus

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


CategoryLectures CategoryCmc CategoryUneex

LecturesCMC/LinuxSoft2007/05 (последним исправлял пользователь eSyr 2009-09-23 09:17:56)