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

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

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

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

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

• Х-сервер (+окно + фокус) --- определяет фреймворк
• Window Manager --- отвечает за всевозможное управление окнами. Сам Х-серер умеет управлять окнами, но ему это надо сказать. Существует некоторые функциональности, которые интегрируются или нет, сегодня поговорим про то, что надо делать, чтобы не интегрировались: + VWM
  • Меню
  • Панели --- трей, панель задач, быстрый запуск
  • Иконки
  • Клавиатурные сокращения
  • Копирование

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

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

• Копировать можно только текст
• Специфицирование кодировки
• Копирование совпадает с выделением

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

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

• Десктоп --- у icewm есть idesk (?), который делает рабочий стол и отделён от wm
• Кучи программ для разных панелей
• xbindkeys --- поддержка горячих клавиш
• Klipboard --- собирает то, что копирует пользователь...

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

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

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

Ни одна из этих задач не является неразрешимой, отличие в том, что если предыдущие задачи решаются в соответствии со стандартом х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, которая занимается двумя вещами:

• Разработка некоторых проектов
• Занимаются стандартизацией всего того, что лектор стёр. Есть список ПО, прошедшего стандартизацию. Есть draft, и если ему следовать, то завтра будет всё работать.

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

• DnD --- проблема почти решённая
  • Ещё не поддержано, но предлагается
    • передача файлов --- direct save. Вопрос, что нужно с этим файлом нести
    • uri
    • Trash
• Desktop file --- более расширенная версия того, что в виндовсе называется шоткатом. Это некий описатель программы или документа.
  • Меню файла --- универсальный каталогизатор
• Каталоги и правила их обхода. Где лежат пользовательские настройки, где лежит то, где лежит сё...
• Клипборд --- если не выполнять команду копирования, то в primary, иначе клипборд, аналогично при вставке.
• Строчки передаются в utf-8
• WM Specification --- целую кучу расширений стандартизовали, появилась такая программа, которая может послать по стандартному протоколу стандартные команды приложению. Очень важное достижение
• Встраиваемые приложения
• Пока не договорились, но на пути --- трей.
• Как делать иконки
• Как хранить букмарки ---XML Bookmarx Exchange Languahe

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

• Общая спецификация mime --- в планах
  • Обработка mime
• Startup/shutdown notification
• Курсоры

dbus

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

CategoryLectures CategoryCmc CategoryUneex