система для обеспечения хостинга объектов графической компоновки/представления

Формула изобретения

1. Система управления компоновкой графических выходных данных для упорядочивания и поддержания графически отображаемых выходных данных программ, выполняющихся на компьютерной системе, причем система управления компоновкой графических выходных данных содержит

графические элементы, содержащие данные, которые представляют отображаемый контент программы;

презентаторы, определяющие состояния отображения для графических элементов, где презентатор конкретного типа поддерживает описание компоновки для соответствующего графического элемента; и систему презентаторов, включающую в себя ведущий интерфейс презентаторов, содержащий метод для подготовки компоновки для видимого изображения в соответствии с набором презентаторов, связанных с графическими элементами, содержащимися в видимом изображении.

2. Система управления компоновкой графических выходных данных по п.1, в которой система презентаторов дополнительно содержит базовый класс презентаторов и в которой набор презентаторов создается из классов презентаторов, полученных из базового класса презентаторов.

3. Система управления компоновкой графических выходных данных по п.2, в которой презентаторы включают в себя метод обновления для вычисления свойств компоновки для презентатора.

4. Система управления компоновкой графических выходных данных по п.3, в которой презентаторы включают в себя метод визуализации для формирования команд, выдаваемых в подсистему графических выходных данных компьютерной системы.

5. Система управления компоновкой графических выходных данных по п.2, в которой классы презентаторов включают в себя заранее определенные классы презентаторов и классы внешних презентаторов.

6. Система управления компоновкой графических выходных данных по п.1, в которой каждый из презентаторов вычисляет состояние компоновки для соответствующего графического элемента на основе значений параметров компоновки, заданных на презентаторе.

7. Система управления компоновкой графических выходных данных по п.1, дополнительно содержащая набор обработчиков уведомлений, причем каждый обработчик уведомлений связан с одним конкретным презентатором из набора презентаторов в видимом изображении, и где обработчик уведомлений обрабатывает изменение графического элемента для определения того, следует ли обновлять соответствующий презентатор.

8. Система управления компоновкой графических выходных данных по п.7, в которой каждый презентатор задает тип обработчика уведомления, который предоставляет уведомления об изменениях конкретному презентатору, имеющему отношение к связанному с ним графическому элементу.

9. Система управления компоновкой графических выходных данных по п.8, в которой обработчик уведомления определяет часть соответствующего презентатора, которая требует обновления ввиду изменений в связанном с ним графическом элементе.

10. Система управления компоновкой графических выходных данных по п.7, в которой система презентаторов регистрирует посредством обработчиков уведомлений те презентаторы, которые требуют обновления на основе изменений соответствующих графических элементов.

11. Система управления компоновкой графических выходных данных по п.1, в которой один экземпляр графического элемента из числа упомянутых графических элементов связан с множеством презентаторов.

12. Система управления компоновкой графических выходных данных по п.11, в которой множество презентаторов, с которыми связан экземпляр графического элемента, является презентаторами одинакового типа.

13. Система управления компоновкой графических выходных данных по п.12, в которой множество презентаторов соответствует отдельным колонкам в одном и том же видимом изображении.

14. Система управления компоновкой графических выходных данных по п.12, в которой множество презентаторов соответствует отдельным страницам в документном видимом изображении одного графического элемента.

15. Система управления компоновкой графических выходных данных по п.11, в которой первый презентатор и второй презентатор из множества презентаторов, связанных с экземпляром графического элемента, связаны с соответствующими первым и вторым отдельными видимыми изображениями.

16. Система управления компоновкой графических выходных данных по п.15, в которой «хостинг» первого и второго отдельных видимых изображений выполняется соответствующими первой и второй системами презентаторов.

17. Система управления компоновкой графических выходных данных по п.1, в которой видимое изображение соответствует прямоугольной области в пространстве графического отображения.

18. Система управления компоновкой графических выходных данных по п.11, в которой множество презентаторов, связанных с экземпляром графического элемента, является множеством презентаторов различных типов.

19. Система управления компоновкой графических выходных данных по п.18, в которой один из множества презентаторов содержит презентатор элементов «отделки» для главного презентатора.

20. Система управления компоновкой графических выходных данных по п.1, в которой презентаторы в видимом изображении иерархически упорядочены, так что дочерние презентаторы содержатся в области, заданной соответствующим родительским презентатором.

21. Система презентаторов для включения в состав системы управления компоновкой графических выходных данных для обработки компоновки от имени программы, предоставляющей графические элементы, которые содержат данные, представляющие отображаемый контент программы, посредством презентаторов, определяющих состояния отображения для графических элементов, и при этом презентатор поддерживает описание компоновки для соответствующего графического элемента, и где система презентаторов управляет и упорядочивает презентаторы, связанные с графическими элементами в видимом изображении, причем система презентаторов содержит базовый класс презентаторов, из которого получают классы презентаторов, и где презентаторы создают из классов презентаторов; и ведущий интерфейс презентаторов, содержащий набор методов, включающий в себя по меньшей мере метод для подготовки компоновки, воплощенной в наборе презентаторов, связанных с графическими элементами в видимом изображении.

22. Система презентаторов по п.21, в которой базовый класс презентаторов задает настраиваемый пользователем метод обновления, подменяемый полученными классами презентаторов, для вычисления свойств компоновки для презентатора.

23. Система презентаторов по п.22, в которой базовый класс презентаторов задает настраиваемый пользователем метод визуализации, подменяемый полученными классами презентаторов, для формирования команд, выдаваемых в подсистему графического вывода компьютерной системы.

24. Система презентаторов по п.21, в которой система презентаторов поддерживает набор классов презентаторов, который включает в себя заранее определенные классы презентаторов и внешние классы презентаторов.

25. Система презентаторов по п.21, в которой базовый класс презентаторов задает метод для вычисления состояния компоновки для графического элемента на основе значений параметров компоновки, заданных на связанном с ним презентаторе.

26. Система презентаторов по п.21, дополнительно включающая базовый класс обработчиков уведомлений, из которого получают классы обработчиков уведомлений, и в которой каждый обработчик уведомлений, созданный из класса обработчиков уведомлений, связан с конкретным презентатором в видимом изображении, и где обработчик уведомлений обрабатывает изменение графического элемента, чтобы определить, следует ли обновлять соответствующий презентатор.

27. Система презентаторов по п.26, в которой класс базовых презентаторов включает в себя «заполнитель» для презентатора для задания типа обработчика уведомлений, который предоставляет уведомления об изменениях конкретному презентатору, относящемуся к связанному с ним графическому элементу.

28. Система презентаторов по п.26, в которой система презентаторов регистрирует посредством обработчиков уведомлений те презентаторы, которым необходимо обновление, на основе изменений в соответствующих графических элементах.

29. Система презентаторов по п.21, в которой система презентаторов связана с видимым изображением, характеризующимся корневым графическим элементом и назначенной зоной, в которой отображают корневой графический элемент и его дочерние графические элементы.

30. Система презентаторов по п.29, в которой видимое изображение соответствует прямоугольной области в пространстве графического отображения.

31. Система презентаторов по п.21, в которой ведущий интерфейс презентаторов включает в себя конструктор для создания системы презентаторов для компоновки отображения для видимого изображения, содержащего набор графических элементов.

32. Система презентаторов по п.31, в которой видимое изображение задается по меньшей мере частично корневым графическим элементом, пересылаемым конструктору.

33. Система презентаторов по п.21, в которой система презентаторов поддерживает сцепление множества презентаторов, так что первый презентатор обеспечивает «отделку» для второго презентатора, связанного с графическим элементом.

34. Система презентаторов по п.21, в которой базовый класс презентаторов включает в себя «заполнитель» для задания дочерних презентаторов, поддерживая тем самым создание иерархической древовидной структуры презентаторов в видимом изображении, так что дочерние презентаторы находятся в области, заданной соответствующим родительским презентатором.

35. Способ для обработки компоновки от имени программы, предоставляющей графические элементы, которые содержат данные, представляющие отображаемый контент программы, посредством презентаторов, определяющих состояния отображения для графических элементов, и причем презентатор поддерживает описание компоновки для соответствующего графического элемента, и при этом система презентаторов обеспечивает хостинг и упорядочивание презентаторов, связанных с графическими элементами в видимом изображении, причем метод содержит этапы:

обеспечивают систему презентаторов, содержащую базовый класс презентаторов и ведущий интерфейс презентаторов, содержащий метод для создания компоновки, воплощенной в наборе презентаторов, связанных с графическими элементами в видимом изображении;

принимают ведущим интерфейсом презентаторов запрос на формирование компоновки для набора графических элементов в видимом изображении; и создают для набора графических элементов соответствующие презентаторы из набора классов презентаторов, полученных из базового класса презентаторов, и вызывают метод на каждом созданном презентаторе для вычисления состояния компоновки для графического элемента, соответствующего презентатору.

36. Способ по п.35, дополнительно содержащий этап:

обеспечивают базовый класс обработчиков уведомлений, задающий интерфейс для набора обработчиков уведомлений, которые облегчают пошаговое обновление компоновки на основе изменений в соответствующих графических элементах.

37. Способ по п.35, дополнительно содержащий организацию презентаторов для видимого изображения в форме иерархического дерева.

38. Способ по п.35, в котором в ответ на вызов создания компоновки для видимого изображения создают систему презентаторов, создавая тем самым отдельную систему презентаторов и соответствующие презентаторы для каждого видимого изображения.

39. Способ по п.35, в котором базовый класс презентаторов задает метод обновления для вычисления свойств компоновки для экземпляра презентатора, связанного с конкретным графическим элементом.

40. Способ по п.35, в котором базовый класс презентаторов задает метод визуализации для формирования команд, выдаваемых в подсистему графического вывода.

41. Способ по п.35, в котором система презентаторов поддерживает образование заранее определенных классов презентаторов и внешних классов презентаторов.

42. Способ по п.35, в котором классы презентаторов соответствуют отличающимся типам презентаторов, которые компонуют различные типы контента графического элемента.

43. Способ по п.35, в котором презентаторы в видимом изображении иерархически упорядочены так, что дочерние презентаторы содержатся в области, заданной соответствующим родительским презентатором.

44. Считываемая компьютером среда, включающая в себя выполняемые компьютером команды для облегчения обработки изображения от имени программы, предоставляющей графические элементы, которые содержат данные, представляющие отображаемый контент программы, посредством презентаторов, определяющих состояния отображения для графических элементов, и где презентатор поддерживает описание компоновки для соответствующего графического элемента и где система презентаторов обеспечивает хостинг и упорядочивание презентаторов, связанных с графическими элементами в видимом изображении, причем считываемые компьютером команды, облегчающие выполнение способа, содержат этапы:

предоставление системы презентаторов, содержащей базовый класс презентаторов и ведущий интерфейс презентаторов, содержащий метод для создания компоновки, воплощенной в наборе презентаторов, связанных с графическими элементами в видимом изображении;

прием ведущим интерфейсом презентаторов запроса на формирование компоновки для набора графических элементов в видимом изображении; и

создание для набора графических элементов соответствующих презентаторов из набора классов презентаторов, полученных из базового класса презентаторов, и вызов метода на каждом созданном презентаторе для вычисления состояния компоновки для графического элемента, соответствующего презентатору.

45. Считываемая компьютером среда по п.44, дополнительно содержащая считываемые компьютером команды для упорядочения презентаторов для видимого изображения в форме иерархического дерева.

46. Считываемая компьютером среда по п.44, в которой выполняемые компьютером команды облегчают создание экземпляра системы презентаторов в ответ на вызов создания компоновки для видимого изображения, создавая тем самым отдельную систему презентаторов и соответствующие презентаторы для каждого видимого изображения.

47. Считываемая компьютером среда по п.44, в которой базовый класс презентаторов задает метод обновления для вычисления свойств компоновки для экземпляра презентатора, связанного с конкретным графическим элементом.

48. Считываемая компьютером среда по п.44, в которой базовый класс презентаторов задает метод визуализации для формирования команд, выдаваемых в подсистему графического вывода.

49. Считываемая компьютером среда по п.44, в которой система презентаторов поддерживает образование заранее определенных классов презентаторов и внешних классов презентаторов.

50. Считываемая компьютером среда по п.44, в которой классы презентаторов соответствуют отличающимся типам презентаторов, которые компонуют различные типы контента графического элемента.

51. Считываемая компьютером среда по п.44, в которой базовый класс презентаторов задает заполнитель для дочерних презентаторов, облегчая тем самым иерархическую компоновку презентаторов в видимом изображении, так что дочерние презентаторы содержатся в области, заданной соответствующим родительским презентатором.

Описание изобретения к патенту

Область техники, к которой относится изобретение

Настоящее изобретение относится в целом к вычислительным устройствам. В частности, настоящее изобретение относится к вычислительным компонентам для упорядочивания графических элементов, отображаемых через графический документный/пользовательский интерфейс.

Уровень техники

Отображение и/или визуализация графических выходных данных для приложения, которое выполняется в вычислительной системе, включает в себя множество задач. Одной из таких задач является управление компоновкой/представлением. Управление компоновкой/представлением касается упорядочивания и «отделки» (украшения) набора элементов изображения в выделенных для них местах (например, прямоугольниках). Хотя термин «компоновка» и термин «представление» могут в других контекстах по смыслу различаться, в данном описании эти термины следует трактовать как взаимозаменяемые и эквивалентные. Элементы отображения, обработанные системой компоновки/представления, предоставляют графические выходные данные на компоненты визуализации системы графического вывода и драйверов графического отображения. Указанные компоненты визуализации приводят в действие аппаратные средства графического отображения, такие как мониторы и принтеры.

Операции компоновки/представления, выполняемые вычислительными системами, охватывают множество разнообразных функций, выполняемых над графическими элементами отображения. Примером такой операции является упорядочивание текста в рамках заданных размеров графического пользовательского интерфейса редакторского приложения. Операция компоновки определяет содержание (контент) и размещение строк текста в обозначенном прямоугольном пространстве. Другим примером является кадрирование элемента (например, диалогового окна, панели инструментальных средств, панели управляющих элементов и т.д.) с унифицированной границей. Эти операции здесь также называют «возможностями» (опциями). Компоненты визуализации компьютерной системы создают графические выходные данные на основе состояния элементов отображения, которые, возможно, были модифицированы выполненными ранее операциями/возможностями компоновки/представления.

Известны различные механизмы представления. Например, «пользовательский модуль» Microsoft Windows выполняет операции компоновки применительно к окнам высокого уровня на пользовательском графическом интерфейсе. Администратор диалогового окна Microsoft Windows размещает объекты на заранее определенных позициях и позволяет группировать объекты. Позиционирование объектов осуществляется в логическом порядке и не зависит от физического устройства. Система JAVA SWING выполняет базовые операции размещения применительно к объектам в видимом изображении на основе свойств, заданных на объектах.

Операции компоновки/представления выполняются в настоящее время несколькими способами. Операцию компоновки элементов отображения может полностью выполнять само приложение. Операция компоновки (или «представления») инкапсулирована в приложение. Приложение выполняет «отделку»/компонует элементы для одного видимого изображения (или изображений), связанного(ых) с текущим состоянием приложения. Приложение упорядочивает элементы в области отображения, выделенной данному приложению. После этого приложение визуализирует отображаемые выходные данные, соответствующие упорядоченным элементам отображения, передавая их в графическую систему/драйверы.

Другой вариант конфигурации обработки компоновки, включенный в операционную систему Microsoft Windows XP, обеспечивает поддержку заранее определенного набора возможностей компоновки, которые могут быть востребованы приложениями. Набор возможностей компоновки содержит специализированные операции компоновки/представления для элементов отображения графического пользовательского интерфейса для приложений. Набор заранее определенных возможностей компоновки/представления, такой как, например, генератор границ для предоставляемых прямоугольников, уменьшает объем работ по программированию для разработчиков приложения, касающихся конкретных аспектов организации и представления элементов графического отображения. Этот набор заранее определенных возможностей также облегчает совместимость с некоторыми выполняющимися базовыми возможностями/функциями отображения, к примеру с вышеупомянутыми границами. Приложения дополняют заранее определенные функциональные возможности компоновки дополнительными операциями компоновки, встроенными в сами приложения.

Известная архитектура обработки компоновки, включающая в себя заранее определенные возможности компоновки, которые могут быть востребованы приложением, упрощает программирование задач компоновки, с которыми сталкиваются приложения в ходе упорядочивания видимого изображения, перед предоставлением графических данных и команд компонентам визуализации компьютерной системы. Однако известная архитектура обработки компоновки с трудом поддерживает расширение или модификации, касающиеся набора заранее определенных возможностей компоновки, которые могут быть востребованы приложениями. Таким образом, новые возможности компоновки размещают, например, непосредственно в программе приложения, вместо того чтобы включить эти возможности в набор заранее определенных возможностей компоновки, предлагаемых архитектурой представления/компоновки. Далее в ходе выполнения приложение производит вычисления для компоновки используя комбинацию заранее определенных функциональных возможностей компоновки и выполняемых внутри приложения операций компоновки/представления.

Сущность изобретения

Настоящее изобретение содержит систему презентаторов (модулей представления) для их включения в состав системы управления компоновкой графических выходных данных. Указанное управление компоновкой направлено на способ, которым объекты упорядочивают, задают размеры и размещают в пространстве отображения. Указанные системы обрабатывают компоновку от имени программы, предоставляющей графические элементы, которые содержат данные, представляющие отображаемый контент программы (например, блок текста, который необходимо упорядочить на отображаемой или распечатываемой странице). Презентаторы выполняют дополнительную роль по отношению к графическим элементам (которые определяют данные) путем задания состояний отображения для представления контента графических элементов. Как таковые, презентаторы поддерживают описание компоновки для соответствующего графического элемента.

Согласно изобретению система презентаторов выполняет роль ведущего узла и упорядочивает презентаторы, связанные с графическими элементами в видимом изображении. Система презентаторов, выполняя роль поддержки процесса получения (вывода) презентаторов множества типов, включает в себя базовый класс презентаторов (модулей представления), из которого получают классы презентаторов. После этого презентаторы конкретизируются исходя из выведенных классов презентаторов.

Система презентаторов также включает в себя ведущий интерфейс презентаторов. Ведущий интерфейс содержит способ для компоновки графических элементов в видимом изображении в соответствии с презентаторами, связанными с графическими элементами. Как таковая, компоновка графических элементов в видимом изображении задается соответствующими презентаторами.

Краткое описание чертежей

Хотя признаки настоящего изобретения детально изложены в прилагаемой формуле изобретения, изобретение и его преимущества лучше всего можно понять из нижеследующего подробного описания вместе с сопроводительными чертежами, на которых:

фиг. 1 - блок-схема, изображающая приведенную в качестве примера вычислительную систему для выполнения одного варианта изобретения;

фиг. 2 - схема высокого уровня, изображающая основные компоненты архитектуры управления компоновкой, включающей систему презентаторов для выполнения поддержки графической компоновки в вычислительной системе, где воплощено настоящее изобретение;

фиг. 3 - схема, изображающая взаимосвязи между графическими элементами и презентаторами, определяющими графический документный/пользовательский интерфейс в системе, где воплощено настоящее изобретение;

фигуры 4а и 4b - итоговая структура базового класса презентаторов, из которой выводят классы объектов-презентаторов согласно требованиям пользователя, для выполнения конкретных задач компоновки/визуализации в системе, где воплощено настоящее изобретение;

фиг. 5 - итоговая структура дочернего посреднического класса;

фиг. 6 - итоговая структура интерфейса класса обработчиков уведомлений;

фиг. 7 - итоговая структура класса узла обработчиков уведомлений;

фиг. 8 - итоговая структура класса видимого изображения;

фиг. 9 - итоговое представление частей структуры BoxSizeInfo (информация о размерах прямоугольника);

фиг. 10 - итоговое представление частей структуры дескриптора страницы;

фиг. 11 - итоговая структура класса механизма представления;

фиг. 12 - блок-схема, дающая итоговое представление о примерных шагах для обработки изменения в графическом элементе на основе обработчика уведомлений;

фиг. 13 - блок-схема, дающая итоговое представление о примерных шагах для выполнения повторных вычислений и визуализации видимого изображения, содержащего набор презентаторов, согласно варианту настоящего изобретения; и

фиг. 14 - блок-схема, дающая итоговое представление о примерных шагах для выполнения обновления в презентаторе (и связанных с ним затронутых дочерних презентаторах) в ответ на изменение в относящемся к нему графическом элементе.

Подробное описание чертежей

Ниже раскрыта архитектура пользовательского интерфейса и компоновки/преставления документа.

Раскрытая архитектура компоновки/представления включает в себя компоненты (презентаторы, модули представления) графической обработки/визуализации компоновки, которые реализуют аспекты видимого изображения соответствующих базовых данных (графических элементов) для документного/пользовательского интерфейса. Система презентаторов хостирует (размещает в себе) презентаторы. Выполняя свою ведущую роль, система презентаторов организует и координирует обновление видимого изображения, содержащего набор презентаторов, в ответ на изменения соответствующих графических элементов. Таким образом, система презентаторов обеспечивает механизм, который связывает состояние (например, состояние данных) графических элементов с состояниями видимого изображения, обновляемыми, кэшируемыми и визуализируемыми с помощью соответствующих объектов-презентаторов.

Одним из аспектов архитектуры компоновки/представления на основе системы презентаторов, в которой воплощено настоящее изобретение, является высокая степень расширяемости применительно к типам презентаторов, которыми она управляет. Базовый класс презентаторов, предоставляемый системой презентаторов, облегчает расширение набора типов презентаторов (классов объектов), доступных для компоновки и визуализации информации, обеспечиваемой соответствующим графическим элементом. Различные типы презентаторов, получаемые из базового класса презентаторов, включают в себя конкретные способы компоновки/визуализации в качестве переопределений для способов по умолчанию, задаваемых базовым классом презентаторов. Объекты презентаторов, созданные исходя из набора классов объектов презентаторов, реализуют возможности компоновки/представления согласно состоянию данных соответствующего графического элемента.

Система презентаторов управляет презентаторскими объектами, созданными (заданными) исходя из набора классов объектов презентаторов. Система презентаторов реализует управление (то есть создание, удаление и т.д.) на протяжении всего времени существования объектов презентаторов. Система презентаторов обеспечивает обработку, связанную с отслеживанием «загрязненности» презентаторов, для избирательного обновления только измененных презентаторов. Система презентаторов поддерживает сцепление презентаторов для предоставления элементов «отделки» (украшения) главным презентаторам. Система презентаторов также координирует обновление и визуализацию презентаторов.

В одном варианте изобретения благодаря наличию обработчиков уведомлений облегчается уведомление об изменениях графических элементов, потенциально влияющих на состояния видимого изображения. Обработчики уведомлений предоставляют возможность обработки уведомлений об изменениях, выделяемых из процесса обработки изменений, выполняемого презентаторами. Каждый тип элемента презентатора связан с типом обработчика уведомлений. Каждый обработчик уведомлений обрабатывает изменения соответствующего графического элемента. Если обновление необходимо, то тогда обработчик уведомлений инициирует установку свойства «загрязненности» в соответствующем объекте презентатора. Установленное свойство «загрязненности» вызывает повторные вычисления для объекта презентатора в ответ на изменения соответствующего графического элемента.

Архитектура компоновки/представления интерфейса пользователя, описанная здесь в качестве примера, включена в состав операционной системы, которая обеспечивает хостинг приложений, имеющих графические пользовательские/документные интерфейсы. Приложения, презентаторы и компоненты операционной системы для визуализации, зависящие от конкретного устройства, а также драйверы, зависящие от конкретного устройства, визуализируют команды/данные управления устройствами вывода графических данных интерфейса/документа для отображения на аппаратных средствах устройств отображения (например, мониторы, принтеры и т.д.). Возможности (опции) компоновки визуализированных выходных данных базируются, по меньшей мере частично, на обработке компоновки/представления и визуализации, выполняемых презентаторами, хостируемыми системой презентаторов.

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

Использование объектов презентатора устраняет связь между состоянием данных отображаемого элемента и его отображения в видимом изображении. Вследствие этого каждый графический элемент (источник данных отображения) потенциально способен иметь множество презентаторов, обеспечивающих отдельные видимые изображения графического элемента (например, полномасштабное и свернутое изображение фотографического элемента). Возможность связывания множества презентаторов с одним графическим элементом позволяет также связать один элемент с множеством мест внутри поля (например, расщепление одного графического элемента на множество колонок). Кроме того, система презентаторов поддерживает сцепление множества отдельных презентаторов различных типов с одним элементом, в результате чего поддерживается закрепление множества различных элементов «отделки», настроенных пользователем, за базовым видимым изображением для элемента. Далее со ссылками на чертежи описываются эти и другие аспекты примерной архитектуры компоновки/визуализации изображений.

На фиг. 1 в качестве примера показана подходящая операционная среда 100 для реализации архитектуры компоновки/представления отображений на основе системы презентаторов. Операционная среда 100 является лишь одним примером подходящей операционной среды, и ее не следует рассматривать как какое-либо ограничение сферы использования или функциональных возможностей изобретения. Другие хорошо известные вычислительные системы, среды и/или конфигурации, которые могут подойти для использования с данным изобретением, включают в себя, но не ограничиваются ими: персональные компьютеры, компьютеры-серверы, портативные/настольные вычислительные устройства, переносные вычислительные устройства, многопроцессорные системы, системы на базе микропроцессоров, сетевые персональные компьютеры, миникомпьютеры, универсальные компьютеры, распределенные вычислительные среды, которые включают в себя любые из вышеупомянутых систем или устройств и т.п. Раскрытая здесь архитектура управления компоновкой, к примеру архитектура, показанная на фиг.1, включающая в себя систему презентаторов, отвечает ряду различных требований, в том числе расширяемости, интеграции и единообразия в отношении функциональных возможностей отображения для вычислительной системы.

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

Обратимся к фиг.1, где приведенная в качестве примера система для реализации изобретения включает в себя вычислительное устройство общего назначения в виде компьютера 110. Компоненты компьютера 110 могут включать в себя, но не только, блок 120 обработки, системную память 130 и системную шину 121, которая связывает различные системные компоненты, в том числе системную память, с блоком 120 обработки. Системная шина может представлять собой шинные структуры любого из нескольких типов, в том числе: шину памяти или контроллер памяти, периферийную шину и локальную шину, с использованием любой из множества различных шинных архитектур. В качестве примера, но не как ограничение, такие архитектуры включают в себя: шину с архитектурой промышленного стандарта (ISA), шину с микроканальной архитектурой (MCA), шину с расширенной архитектурой ISA (EISA), локальную шину, разработанную Ассоциацией по стандартам видеооборудования (VESA), и шину межсоединений периферийных компонентов (PCI), известную также как шина Mezzanine.

Компьютер 110 обычно включает в себя множество различных считываемых компьютером сред. Считываемая компьютером среда может представлять собой любую имеющуюся среду, которая может быть доступна компьютеру 110, и включает в себя как энергозависимую, так и энергонезависимую среду, съемную и несъемную среду (носители). Как пример, но не ограничение, считываемая компьютером среда может содержать компьютерную запоминающую среду и среду связи. Компьютерная запоминающая среда включает в себя как энергозависимую, так и энергонезависимую, как съемную, так и несъемную среды, реализованные любым способом или по любой технологии для хранения информации, такой как считываемые компьютером команды, структуры данных, программные модули или другие данные. Компьютерная запоминающая среда включает в себя, но не только: ОЗУ (RAM), ПЗУ (ROM), электрически стираемое ППЗУ (EEPROM), флэш-память или другую технологию памяти, ПЗУ на компакт-диске (CD-ROM), цифровые универсальные диски (DVD) или другое запоминающее устройство на оптических дисках, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитном диске либо другие магнитные запоминающие устройства, или любую другую среду, которую можно использовать для запоминания требуемой информации и которая может быть доступна компьютеру 110. Среда связи обычно воплощает считываемые компьютером команды, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как сигнал несущей, либо другой механизм транспортировки данных, и включает в себя любую среду для доставки информации. Термин «модулированный сигнал данных» означает сигнал, который имеет одну или несколько характеристик, устанавливаемых или изменяемых таким образом, чтобы обеспечить кодирование информации в этом сигнале. В качестве примера, но не как ограничение, среда связи включает в себя проводную среду, такую как проводная сеть или прямое проводное соединение, и беспроводную среду, такую как акустическая, радиочастотная (RF), инфракрасная или иная беспроводная среда. В сферу считываемой компьютером среды могут быть также включены комбинации из любых вышеупомянутых сред.

Системная память 130 включает в себя компьютерную запоминающую среду в виде энергозависимой и/или энергонезависимой памяти, такой как память 131 только для считывания (ROM) и память 132 с произвольным доступом (RAM). Базовая система 133 ввода/вывода (BIOS), содержащая базовые подпрограммы, которые помогают пересылать информацию между элементами в компьютере 110, к примеру во время запуска, иногда хранится в ROM 131. RAM 132 обычно содержит данные и/или программные модули, которые непосредственно доступны и/или в данный момент обрабатываются блоком 120 обработки. В качестве примера, но не как ограничение, на фиг. 1 показаны операционная система 134, прикладные программы 135, другие программные модули 136 и программные данные 137.

Компьютер 110 может также включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные запоминающие среды. В качестве примера на фиг. 1 показан только накопитель 140 на жестких дисках, который выполняет считывание с или запись на несъемную, энергонезависимую магнитную среду (носитель), накопитель 151 на магнитном диске, который осуществляет считывание с или запись на съемный энергонезависимый магнитный диск 152, и накопитель 155 на оптическом диске, который осуществляет считывание с и запись на съемный энергонезависимый оптический диск 156, такой как CD ROM, либо другой оптический носитель. К другим съемным/несъемным энергозависимым/энергонезависимым запоминающим средам, которые можно использовать в приведенной в качестве примера операционной среде, относятся, но не только: кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, цифровая видеолента, твердотельное ОЗУ (RAM), твердотельное ПЗУ (ROM) и т.п. Накопитель 141 на жестких дисках обычно подсоединен к системной шине 121 через несъемный интерфейс памяти, такой как интерфейс 140, а дисковод 151 на магнитном диске и дисковод 155 на оптическом диске обычно подсоединены к системной шине 121 через съемный интерфейс памяти, такой как интерфейс 150.

Накопители и связанные с ними компьютерные запоминающие среды, описанные выше и показанные на фиг. 1, обеспечивают сохранение считываемых компьютером команд, структур данных, программных модулей и других данных для компьютера 110. На фиг. 1 в качестве примера показано, что накопитель 141 на жестких дисках хранит операционную систему 144, прикладные программы 145, другие программные модули 146 и программные данные 147. Заметим, что эти компоненты могут совпадать либо отличаться от операционной системы 134, прикладных программ 135, других программных модулей 136 и программных данных 137. Операционная система 144, прикладные программы 145, другие программные модули 146 и программные данные 147 представлены здесь разными ссылочными позициями, чтобы показать, что они являются, как минимум, разными копиями. Пользователь может ввести команды и информацию в компьютер 20 через устройства ввода, такие как клавиатура 162 и указательное устройство 161, под которым обычно подразумевается мышь, шаровой манипулятор или сенсорная клавиатура. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровую клавиатуру, спутниковую тарелку, сканер или т.п. Эти и другие устройства ввода часто подсоединяют к блоку 120 обработки через пользовательский интерфейс 180 ввода, который соединен с системной шиной, хотя эти устройства могут быть подсоединены через другие интерфейсные и шинные структуры, такие как параллельный порт, игровой порт или универсальная последовательная шина (USB). Через интерфейс, такой как видеоинтерфейс 190, к системной шине 121 также может быть подсоединен монитор 191 либо устройство отображения другого типа. Вдобавок к монитору компьютеры могут также включать в себя другие периферийные устройства вывода, такие как динамики 197 и принтер 196, которые могут быть подсоединены через выходной периферийный интерфейс 195.

Компьютер 110 потенциально действует в сетевом окружении, используя логические соединения с одним или несколькими удаленными компьютерами, такими как удаленный компьютер 180. Удаленный компьютер 180 может представлять собой персональный компьютер, сервер, маршрутизатор, сетевой персональный компьютер, равноправное устройство или другой общий сетевой узел и обычно включает в себя многие либо все элементы, описанные выше в связи с компьютером 110, хотя на фиг. 1 показано только запоминающее устройство 181. Логические соединения, изображенные на фиг. 1, включают в себя локальную сеть (LAN) 171 и глобальную сеть (WAN) 173, но могут также включать в себя другие сети. Такие сетевые среды широко распространены в офисах, корпоративных компьютерных сетях, интрасетях и Интернет.

При использовании в сетевой среде LAN компьютер 110 подсоединен к LAN 171 через сетевой интерфейс или адаптер 170. При использовании в сетевой среде WAN компьютер 110 обычно включает в себя модем 172 либо другое средство для установления связи по сети WAN 173, такой как Интернет. Модем 172, который может быть встроенным либо внешним, может быть подсоединен к системной шине 121 через входной интерфейс 160 пользователя либо другой подходящий механизм. В сетевой среде программные модули, изображенные применительно к компьютеру 110 или его частям, могут храниться в удаленном запоминающем устройстве. В качестве примера, но не как ограничение, на фиг. 1 показаны удаленные прикладные программы 185, находящиеся в запоминающем устройстве 181. Очевидно, что показанные сетевые соединения приведены в качестве примера, и что можно использовать другие средства для установления линии связи между компьютерами.

На фиг. 2 представлена схема высокого уровня, идентифицирующая программные модули и программы, а также конкретизированные объекты и компоненты данных архитектуры системы управления компоновкой/представлением, в которой воплощено настоящее изобретение. Приведенная в качестве примера архитектура системы управления компоновкой/представлением, показанная на фиг. 2, включает в себя систему 200 презентаторов, которая поддерживает компоновку/представление отображаемых объектов на основе набора иерархически упорядоченных объектов презентаторов, связанных с создаваемым видимым изображением 202, исходя из класса объекта видимого изображения (смотри фиг.8, описанную ниже) при запросе приложения 204, выполняющегося в операционной системе 205.

В одном варианте изобретения каждое видимое изображение (например, видимое изображение 202) имеет соответствующую систему презентаторов (например, систему 200 презентаторов), которая отвечает за поддержание отображаемых объектов в видимом изображении. В одном варианте изобретения изображение 202 представляет собой визуальный корневой объект для всех визуальных объектов, которые создаются системой 200 презентаторов. Отображаемый контент в видимом изображении 202 базируется на графических элементах 206 во вспомогательном запоминающем устройстве 208. Приложение 204 является источником графических элементов 206 во вспомогательном запоминающем устройстве 208. На фиг. 3, описанной ниже, показан пример, где представлены взаимосвязи между видимыми изображениями, системами презентаторов, деревьями презентаторов для видимых изображений и деревьями графических элементов, связанными с приложением.

Архитектура системы управления компоновкой/представлением, изображенная на фиг. 2, разделена на множество функциональных компонентов. Линии между изображенными компонентами представляют пути взаимодействия между компонентами. Настоящее изобретение не сводится к конкретной компоновке компонентов и показанным в качестве примера взаимодействиям между компонентами в иллюстративном варианте, изображенном на фиг.2. Наоборот, описанные ниже функциональные возможности компонентов сгруппированы в различных сочетаниях согласно альтернативным вариантам изобретения.

В одном варианте изобретения приложение 204 вызывает метод-конструктор на прикладном программном интерфейсе классов объектов - видимых изображений (смотри структуру классов видимых изображений на фиг. 8, описанной ниже) для создания корневого объекта для экземпляра объекта - видимого изображения 202. Вызов метода для создания видимого изображения 202 проходит через ссылку к корневому графическому элементу графических элементов 206, находящихся во вспомогательном запоминающем устройстве 208. После создания видимого изображения 202 вызов метода DoLayout (выполнить компоновку) на видимом изображении 202 создает дерево презентаторов для видимого изображения 202 с корневым объектом-презентатором, соответствующим корневому графическому элементу, изначально переданному методу-конструктору, который создал видимое изображение 202. Дерево презентаторов (на фиг. 2 не показано) для видимого изображения 202 содержит набор презентаторов, которые ответственны за организацию и визуализацию выходных данных для видимого изображения 202.

В одном варианте изобретения каждое видимое изображение (например, видимое изображение 202) обладает системой презентаторов (например, система 200 презентаторов). Таким образом, в ответ на вызов метода DoLayout видимое изображение 202 инициирует создание нового дерева презентаторов и возвращает его вызывающей стороне (например, приложение 204). В исходном состоянии видимое изображение 202 вызывает метод-конструктор из класса объектов-механизмов представления для создания экземпляра механизма 212 представления, включающего в себя ведущий прикладной программный интерфейс презентаторов (ведущий API презентаторов). Механизм 212 представления включает в себя выполняемую программу для координации и организации выполнения операций компоновки/представления в вычислительной системе, поддерживающей графические выходные данные. Функции, выполняемые/координируемые механизмом 212 представления, включают в себя: создание объектов презентаторов (как корневой, так и дочерней версии), координацию повторных вычислений состояний отображения презентаторов, визуализацию, управление презентаторами на протяжении всего времени их существования, отслеживание «загрязненности», сцепление множества презентаторов с одним элементом и выполнение пошаговой компоновки. Примеры вызываемых методов на ведущем API презентаторов механизма 212 представления описаны ниже со ссылками на фиг. 12. Эти методы представляют собой запросы высокого уровня, которые создают и поддерживают дерево объектов презентаторов для видимого изображения 202. Идентифицированные задачи, выполняемые механизмом 212 представления, приведены в качестве примеров, и специалистам в данной области техники должно быть понятно, что в альтернативных вариантах изобретения механизм 212 представления может решать дополнительные/альтернативные задачи.

Механизм 212 представления строит систему 200 презентаторов для обработки объектов презентаторов, связанных с видимым изображением 202. В одном варианте изобретения система 200 презентаторов включает в себя базовый класс 216 презентаторов. Базовый класс 216 презентаторов является базовым классом с полным набором возможностей для создания подклассов презентаторов и объектов презентаторов, способных использовать функциональные возможности управления компоновкой для системы, описанной ниже. Базовый класс 216 презентаторов содержит шаблон, включающий в себя виртуальный (переопределяемый) программный код и структуры данных, из которых получают набор классов 214 презентаторов. Классы 214 презентаторов содержат набор специализированных типов презентаторов, соответствующих видимым изображениям графических элементов, имеющим конкретные свойства/режимы отображения. Созданные с учетом требований пользователя классы 214 презентаторов, полученные из базового класса 216 презентаторов, например, компонуют контент, упорядочивают дочерние презентаторы, создают визуалы для закрепленных за ними элементов, разбивают по страницам контент для типографских документов и в пошаговом режиме обновляют визуалы, включающие в себя графические элементы 206. Специализированные функциональные возможности каждого класса презентаторов в наборе классов 214 презентаторов устанавливаются путем переопределения и добавления виртуальных способов, определенных базовым классом 216 презентаторов. Объекты презентаторов, конкретизированные, исходя из набора классов 214 презентаторов, представляют и обрабатывают аспекты отображения графических элементов 206.

В одном варианте изобретения набор классов 214 объектов презентаторов, включающий в себя как заранее определенные классы 218 презентаторов, так и внешние классы 220 презентаторов, является расширяемым. Для набора заранее определенных классов 218 презентаторов предусмотрена система 200 презентаторов. Внешние классы 220 объектов презентаторов обычно устанавливаются независимо от системы 200 презентаторов. Однако выполненное должным образом объединение внешних классов 210 объектов презентаторов с системой 200 презентаторов облегчается опубликованной спецификацией на интерфейс для базового класса 216 презентаторов (описанного ниже со ссылками на фигуры 4а и 4b). Разработчик внешних классов 220 презентаторов переопределяет/модифицирует машинный программный код и структуры данных, связанные с настроенными в соответствии с требованиями пользователя методами компоновки/визуализации базового класса 216 презентаторов для обеспечения функций задания размеров, позиционирования дочерних презентаторов и визуализации с учетом требований пользователя. После этого в наборе внешних классов 220 объектов презентаторов устанавливают новый класс презентаторов, например, путем инсталляции файла, содержащего новый класс объектов в обозначенном каталоге в файловой системе компьютера.

В одном варианте изобретения класс 214 презентаторов включает в себя классы презентаторов для реализации возможностей (опций) компоновки, в том числе, например: компоновку контента, упорядочивание дочерних объектов, создание визуалов, страничное разбиение контента документа и пошаговое обновление визуалов (например, страницы HTML, которые покрывают множество дисплейных экранов). Примеры специальных типов презентаторов включают в себя: текстовый презентатор, который обеспечивает измерения и отображение текста, отформатированного различными способами (например, полужирный, италик и т.д.); презентатор изображения, который обеспечивает измерения и отображение заданного изображения; и стыковочный презентатор, который разделяет на части пространство между множеством дочерних презентаторов.

После создания системы 200 презентаторов и классов 214 презентаторов для данного видимого изображения конкретизируют набор объектов презентаторов, связанных с видимым изображением 202, и систему 200 презентаторов, начиная с объекта корневого презентатора. Заметим, что вызов метода-конструктора для класса объекта-механизма представления с целью создания механизма 212 представления идентифицирует корневой графический элемент для видимого изображения 202. После инсталляции механизм 212 представления вызывает графические элементы 206 для определения типа объекта презентатора, связанного с корневым графическим элементом для видимого изображения 202. После определения типа презентатора графического элемента механизм 212 представления вызывает в одном из классов 214 объектов презентаторов метод, соответствующий типу объекта презентатора, идентифицированному графическими элементами 206, с целью задания значений объекта корневого презентатора для видимого изображения 202.

Как показано с помощью пути между классами 214 презентаторов и вспомогательным запоминающим устройством, объекты презентаторов, в том числе корневой презентатор, обращаются к графическим элементам 206 во вспомогательном запоминающем устройстве 208 для определения свойств конкретных графических элементов. Например, объект презентатора для конкретного графического элемента способен идентифицировать любые дочерние графические элементы конкретного графического элемента и тип презентатора для каждого дочернего графического элемента. Далее объект презентатора вызывает для каждого идентифицированного дочернего графического элемента собственный метод 486 (например, GetChildProxyForElement (получить дочерний посредник для элемента)) для реализации дочернего посреднического (прокси-) объекта-посредника из класса 222 дочерних посредников системы 200 презентаторов. Дочерние посреднические (прокси-) объекты являются объектами-упаковщиками (оболочкой) для объектов презентаторов, реализованных (созданных) исходя из классов 214 объектов презентаторов, которые вложены в пространство отображения, выделенное для объекта родительского презентатора. Класс 222 дочерних посредников удовлетворяет требованиям инкапсулирования и безопасности (например, объект дочернего презентатора с помощью объекта родительского презентатора или приложения 204 ограничивает доступ к контенту презентатора, содержащемуся в дочернем презентаторе). В альтернативном варианте уровень инкапсулирования, предоставляемый дочерними посредническими объектами, пропускается, и родительские презентаторы имеют непосредственный доступ к своим дочерним презентаторам.

Метод для объекта презентатора для создания объекта дочернего посредника для одного элемента в одном варианте изобретения вызывает метод-конструктор из класса 222 дочерних посредников и передает идентификационные данные дочернего графического элемента для создания нового дочернего посреднического (прокси-) объекта и объекта презентатора для дочернего графического элемента. Сразу после создания (реализации) новый дочерний посреднический объект создает объект презентатора для дочернего графического элемента через конструктор презентатора, соответствующий типу презентатора, заданному на идентифицированном дочернем графическом элементе. В свою очередь, дочерний посреднический объект возвращает собственную ссылку родительскому объекту презентатора. Родительский объект презентатора поддерживает возвращенную ссылку дочернего посреднического объекта в массиве ссылок на дочерние посреднические объекты. Как таковые, записи в массиве дочерних посреднических объектов для презентаторского объекта соответствуют дочерним графическим элементам для родительского графического элемента, с которым связан родительский презентатор.

Другим аспектом архитектуры упорядочивания/представления графических элементов, показанной на фиг.2, является уведомление об изменении. В одном варианте настоящего изобретения для объектов презентаторов, созданных из классов 214 презентаторов, предусмотрен набор классов 224 обработчиков уведомлений. Классы 224 обработчиков уведомлений определяются в соответствии с базовым классом 225 обработчиков уведомлений. Базовый класс 225 обработчиков уведомлений является абстрактным классом, который определяет интерфейс для классов 224 обработчиков уведомлений. Базовый класс 225 обработчиков уведомлений предлагает определение интерфейса из двух виртуальных методов (смотри фиг.6), реализация которого предусмотрена в классах 224 обработчиков уведомлений согласно соответствующим классам 214 презентаторов. Классы 224 обработчиков уведомлений помогают выполнять пошаговое обновление компоновки, причем повторно вычисляются только объекты презентатора, подвергнутые изменениям в наборе соответствующих графических элементов. В одном варианте изобретения обработчик уведомлений задается для комбинаций графического элемента и видимого изображения. В случаях создания множества презентаторов для одной комбинации «графический элемент/видимое изображение» в качестве единственного источника для отслеживания изменений в элементе в целях обновления множества презентаторов для данного элемента в видимом изображении действует единственный обработчик уведомлений. Каждый тип презентаторов задает соответствующий конкретный тип обработчика уведомлений. Когда объект презентатора для элемента создан, для чего потребуется обработчик уведомлений, система презентаторов создает соответствующий обработчик уведомлений заданного типа и связывает обработчик уведомлений с объектом презентатора.

Экземпляры классов 224 обработчиков уведомлений определяют, какие части объектов презентаторов являются «загрязненными» и, следовательно, требуют обновления. Вначале устанавливают отношения уведомления между графическим элементом и обработчиком уведомлений, созданным для презентатора в видимом изображении (например, в видимом изображении 202 для приложения 204). Обработчик уведомлений принимает уведомления об изменениях, связанные с графическим элементом во вспомогательном запоминающем устройстве 208, через механизм 212 представления в системе 200 презентаторов. Обработчик уведомлений определяет часть, если она имеется, презентатора, на которую повлияло изменение в элементе. Обработчик уведомлений возвращает информацию о части, претерпевшей изменение, в систему 200 презентаторов. Презентатор помечают как «загрязненный» с помощью механизма 212 представления. Система 200 презентаторов накапливает информацию о «загрязненных» презентаторах для всех презентаторов в структуре данных, поддерживаемой для видимого изображения (например, видимое изображение 202). Затем, в ответ на вызов для повторного расчета компоновки для видимого изображения, механизм 212 представления в системе 200 презентаторов активирует метод/операцию обновления только на «загрязненных» презентаторах. Таким образом, классы 224 обработчиков уведомлений позволяют ограничить обновления компоновки объектами презентаторов, претерпевшими изменения, которые были созданы исходя из классов 214 презентаторов.

Архитектура системы управления компоновкой, в которой воплощено настоящее изобретение, функционирует независимо от каких-либо конкретных аппаратных средств вывода, на которых в конечном счете отображаются выложенные (отображаемые) элементы в соответствии с их определенными видимыми изображениями. Архитектура системы управления компоновкой/представлением, показанная на фиг. 2, выполняет шаг предобработки применительно к графическим выходным данным отображения. В одном варианте изобретения упорядоченные выходные данные, связанные с архитектурой системы управления компоновкой/представлением, не зависят от конкретного устройства. Впоследствии на стадии визуализации объекты презентаторов визуализируют повторно вычисленное видимое изображение на компонентах графического вывода вычислительной системы. Однако в других вариантах изобретения выходные данные системы компоновки/представления возвращают в вызывающее приложение либо с помощью объектов 214 презентаторов, либо с помощью системы 200 презентаторов, и приложение 204 выполняет задачу визуализации. В одном варианте изобретения команды визуализации, если они выданы объектами презентаторами, полученными из классов 214 презентаторов, видимого изображения 202 или приложения 204, поступают в подсистему графики и в драйверы 234 графических устройств на компьютере пользователя. Подсистема графики и драйверы 234 графических устройств подают команды визуализации и данные на конкретное выбранное устройство вывода, такое как монитор 236 или принтер 238.

Суммируя вышесказанное об архитектуре системы управления компоновкой/представлением, описанной выше, можно утверждать, что система 200 презентаторов предоставляет платформу обработки компоновки, не зависящую от конкретного устройства, для приложений, таких как приложение 204. Обработка компоновки выполняется объектами презентаторами, созданными из набора классов 214 презентаторов, ведомых системой 200 презентаторов. Система 200 презентаторов принадлежит видимому изображению 200. Объекты презентаторов соответствуют конкретным состояниям видимого изображения/визуализациям для графических элементов 206. Выделение состояний видимого изображения (объектов презентаторов) из состояний элементов (графических элементов 206) позволяет выполнить независимое обозначение множества состояний видимого изображения/презентаторов для одного состояния элемента. Компоновка разделяется на видимые изображения, такие как видимое изображение 202, где каждое видимое изображение соответствует области отображения, такой как конкретный прямоугольник на выходном экране, выделенном для приложения 204, или странице документа в выходных данных графического принтера. Выделение данных и состояний видимого изображения позволяет одному элементу порождать множество видимых изображений этого графического элемента и, следовательно, позволяет выполнить отображение одного графического элемента во множестве видов/множеством способов.

Другим аспектом раскрытой здесь архитектуры системы управления компоновкой является ее высокая степень расширяемости. Расширение набора классов 214 презентаторов облегчается базовым классом 216 презентаторов, предоставляемым системой 200 презентаторов и ведущим API презентаторов механизма 212 представления.

Вышеописанная архитектура системы управления компоновкой поддерживает множество различных расширенных возможностей обработки компоновки для приложений, визуализирующих графические выходные данные на графических пользовательских интерфейсах и принтерах. Способность разделения одного элемента (графического элемента) на множество состояний видимого изображения (презентаторы, модули представления) облегчает разбиение на страницы и разделение элементов на множество колонок (форма разбиения на страницы) в приложениях при визуализации выходных данных принтера или выходного видимого изображения документа на экране дисплея. Такие приложения включают в себя Web-броузеры и программы пословной обработки.

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

Еще одним преимуществом, вытекающим из использования вышеописанной архитектуры управления компоновкой, является возможность выполнения пошаговых изменений видимого изображения, содержащего набор презентаторов для набора соответствующих элементов. Изменение реализуется на поэлементной основе во вспомогательном запоминающем устройстве (смотри, например, вспомогательное запоминающее устройство 308 на фиг. 3). Обработчики уведомлений и система 200 презентаторов обеспечивает инфраструктуру для ограничения обновления соответствующего видимого изображения презентаторами, которые были подвергнуты изменениям в соответствующих элементах во вспомогательном запоминающем устройстве.

Следующим преимуществом приведенной в качестве примера архитектуры управления компоновкой является возможность «отделки» (украшения) состояний видимого изображения элементов, воплощенных в ранее созданных презентаторах. Это выполняется путем сцепления дополнительных презентаторов с презентатором того типа, который был задан для конкретного типа элементов. Сцепление позволяет разработчикам расширить возможности пользовательских интерфейсов и вывода документов путем добавления границ, фонов и так далее к состоянию видимого изображения, заданного конкретным типом презентатора для элемента.

Учитывая приведенное выше описание общей архитектуры системы управления компоновкой, в которой воплощено настоящее изобретение, обратим внимание на фиг. 3, где показаны взаимосвязи между видимыми изображениями, механизмами представления, объектами презентатора в видимых изображениях, графическими элементами и обработчиками уведомлений для конкретного, приведенного в качестве примера, видимого изображения.

Концептуально видимое изображение задает конкретный способ компоновки набора графических элементов, представленных во вспомогательном запоминающем устройстве 208, согласно заданным (указанным) презентаторам. В одном варианте изобретения видимое изображение ограничено прямоугольником в поле вывода (например, экран дисплея). Вдобавок к прямоугольнику и его координатам видимое изображение также задает графические элементы и связанные с ними презентаторы, содержащиеся в видимом изображении. Кроме того, отметим, что в одном варианте изобретения каждое видимое изображение связано со своим собственным экземпляром системы презентаторов (например, система 200а презентаторов для видимого изображения 202а и система 200b презентаторов для видимого изображения 202b).

Как показано на фиг.3, страничная память 308 содержит организованный набор графических элементов (Ex), связанных с видимыми изображениями 202а и 202b. Графические элементы (Ex) являются объектами контента, организованного пользователем. Примеры элементов включают в себя кнопочную или текстовую панель графического пользовательского интерфейса (GUI), окно текстового редактора, отображение битовой карты и т.д. В одном варианте изобретения графические элементы (Ex) во вспомогательном запоминающем устройстве 208 упорядочены в виде дерева. Каждый элемент (Ex) в наборе графических элементов 206, поддерживаемых во вспомогательном запоминающем устройстве 208, связан с набором свойств/заполнителей (которые могут быть определены в явном виде либо заданы неявно через другие явные свойства/заполнители). Одно или более таких свойств/заполнителей на графических элементах задают тип презентатора, который используется для компоновки и визуализации контента графического элемента в сочетании с другими компонентами компьютерной системы. В вариантах изобретения сцепленные презентаторы определены в явном виде или - в альтернативных вариантах - определены неявно через другие свойства, заданные на элементе (например, свойство «граница» двух пикселей предполагает наличие презентатора, привязанного к границе). Типы свойств, заданные для графических элементов, зависят от конкретного графического элемента и включают в себя цвет, шрифт, имя, высоту, ширину и т.д.

Вспомогательное запоминающее устройство 200 потенциально связано с множеством видимых изображений (например, видимые изображения 202а и 202b). Каждое из потенциального множества видимых изображений обладает эксклюзивным набором экземпляров объектов презентаторов, соответствующих набору графических элементов во вспомогательном запоминающем устройстве 208. Таким образом, в случае, когда графический элемент представлен множеством видимых изображений, объект презентатора создается для элемента в каждом видимом изображении (например, презентатор P2 и презентатор P2' для элемента E2). Графический элемент, с которым связан презентатор, задается в поле владельца элемента, и соответствует пунктирным линиям, идущим от презентаторов к соответствующим графическим элементам. Это является просто одним примером архитектуры представления, показанной на фигурах 2 и 3, где поддерживается множество презентаторов, действующих на основе информации, предоставляемой одним графическим элементом.

Как следствие особенностей архитектуры представления, воплощающей вышеописанную способность присоединять множество видимых изображений (и презентаторов) к одной и той же совокупности графических элементов во вспомогательном запоминающем устройстве 208, графический пользовательский интерфейс способен отображать множество видимых изображений одного и того же информационного набора, предоставляемого графическими элементами. Например, в приложении, таком как MICROSOFT's POWERPOINT, поддерживаются одновременно два видимых изображения слайда, главное видимое изображение и видимое изображение для предварительного просмотра (или «набросок») для одного и того же графического элемента слайда.

Способность создавать множество экземпляров объектов презентатора для одного графического элемента также облегчает разбиение одного графического элемента на множество страниц/колонок (например, текста документа) (то есть, если один графический элемент разбит на две страницы, то создают два объекта-презентатора для элемента - по одному для каждой страницы). Обратимся к фиг.3, где объект родительского презентатора (например, Р5) получает переданное свойство от графического элемента (например, Е5), указывающего, что контент в элементе (например, текстовый элемент Е8) может быть представлен двумя колонками. Под презентатором Р5 создаются два объекта Р8а и Р8b дочерних презентаторов, соответствующие двум отдельным прямоугольникам для колонки/страницы в документе, для отображения текста, представленного графическим элементом Е8.

Еще один случай создания множества презентаторов для одного графического элемента возникает тогда, когда для графического элемента выделяются элементы «отделки» (например, границы, фоны, рамки и т.д.). Сцепленный презентатор Q4 для элемента Е4, который обеспечивает границу вокруг прямоугольника, заданного презентатором Р4 для сохранения текста, предоставляемого полем данных в элементе Е4, представляет пример сцепленного презентатора. Презентатор Q4 и презентатор Р4 соединены/связаны с графическим элементом Е4 путем задания графического элемента Е4 в их полях для владельца элемента. В одном варианте изобретения родительский презентатор на основе анализа элемента, соответствующего одному из его дочерних элементов, обнаруживает, что необходим сцепленный презентатор (например, на элементе задана граница двух пикселей). В случае наличия сцепленного презентатора Q4 при вызове самим презентатором Р1 метода для создания дочернего (посреднического) презентатора для дочернего элемента Е4 презентатор Р1, исходя из свойств Е4, определяет, что необходим сцепленный презентатор (Q4). Сначала создается дочерний посредник/презентатор Q4, и идентифицируется как дочерний презентатор презентатора Р1. Презентатор Q4, в свою очередь, создает дочерний посредник/презентатор Р4. Таким образом, Р4 является дочерним презентатором для презентатора Q4. Информация хранится в дочернем посреднике для сцепленного презентатора Q4, идентифицирующего следующий презентатор (Р4) в цепи.

Далее, после того как были описаны приведенные в качестве примера конкретные случаи, где используется множество презентаторов, связанных с одним и тем же графическим элементом, и где создается множество видимых изображений (и систем презентаторов) для набора графических элементов во вспомогательном запоминающем устройстве 208, описываются взаимосвязи между отображаемыми объектами на фиг.3. Как упоминалось выше, видимые изображения 202а и 202b имеют соответственно собственные системы 200а и 200b презентаторов. Система 200а презентаторов создала и поддерживает набор презентаторов 302 для видимого изображения 202а посредством кода и базового класса, включая API, в который записаны классы презентаторов. Система презентаторов 200b создала и поддерживает набор презентаторов 303 для видимого изображения 202b.

Как показано с помощью линий между презентаторами (Px) и графическими элементами (Ех) во вспомогательном запоминающем устройстве 208, презентаторы (Рх) связаны с соответствующими графическими элементами (Ех). Презентаторы (Рх) представляют состояния видимых изображений для соответствующих графических элементов (Ех). Графические элементы (Ех) во вспомогательном запоминающем устройстве 304 поддерживаются, например, в древовидной структуре, построенной приложением с использованием одного из множества возможных способов. Примеры таких способов включают в себя прогон файла с текстовой разметкой через синтаксический анализатор, использование кода (программы) для создания графических элементов и т.д. Древовидная структура набора презентаторов 302 строится системой 200а презентаторов в ответ на вызов конкретного метода на интерфейсе (например, DoLayout), предоставляемого его механизмом представления. Как было описано ранее со ссылками на фиг.2, узлы дерева объектов презентаторов определяются узлами дерева графических элементов, связанными с конкретным видимым изображением. Графические элементы в видимом изображении определяются корневым графическим элементом, заданным для данного видимого изображения, его дочерними элементами, «внучатыми» элементами и так далее.

Набор презентаторов в видимом изображении 1 имеет иерархическую структуру. Корневой презентатор Р1 имеет два дочерних презентатора Р2 и Р4 (Q4 является презентатором элементов «отделки» на презентаторе Р4). Презентатор Р2 не имеет дочерних презентаторов. Однако презентатор Р4 имеет два дочерних презентатора Р5 и Р7. Презентатор Р5, в свою очередь, имеет дочерние презентаторы Р8а и Р8b, которые связаны с одним графическим элементом Е8. Такое совместное использование/разделение одного графического презентатора между двумя объектами презентаторов возникает, например, когда текстовый графический элемент Е8 делится между двумя колонками родительского текстового графического элемента Е5, который имеет презентатор (Р5) типа TextPresenter (текстовый презентатор). Презентатор Р5 инициирует процесс разделения на колонки, когда он замечает свойства на Е5, запрашивающее разделение контента (Е8) элемента Е5 на две колонки. Презентаторы Р8а и Р8b соответствуют графическому существованию частей графического элемента Е8 в двух колонках.

Как было отмечено ранее, один графический элемент может иметь множество связанных с ним объектов презентаторов. В качестве примера были приведены три случая. В первом сценарии, показанном с помощью множества видимых изображений 202а и 202b и соответствующих систем 200а и 200b презентаторов на фиг.3, один графический элемент (например, Е2) имеет соответствующие презентаторы Р2 и Р2', связанные с видимыми изображениями 202а и 202b соответственно. Такие видимые изображения соответствуют, например, изображению-наброску и полноразмерному представлению фотографического изображения (Е2), отображаемого в разных областях пользовательского интерфейса, который формируется приложением для обработки фотографических изображений. В этом случае презентаторы Р2 и Р2' создаются для элемента Е2 в каждом видимом изображении 202а и 202b, содержащем этот элемент. Во втором сценарии, включающем в себя множество презентаторов для одного элемента (например, текстовый элемент Е8), элементы-презентаторы Р8а и Р8b соответствуют двум колонкам в прямоугольнике, определенном одним элементом-презентатором Р5. В альтернативном варианте указанные случаи использования множества презентаторов в видимом изображении со ссылками на один и тот же графический элемент возникают, например, когда родительский элемент выполняет множество попыток при компоновке видимого изображения и сохраняет эти попытки. В третьем сценарии презентатор (например, Q4), который зависит от другого презентатора (например, Р4), с противоположным состоянием данных графического элемента (например, Е4) подсоединен сцеплением к другому презентатору, в результате чего расширяются возможности отображения, обеспечиваемые исходным презентатором. Примером сцепления презентаторов является презентатор границы, обеспечивающий «отделку» границы для основного презентатора.

Ранее, со ссылками на фиг. 2, было отмечено, что дочерние посреднические объекты, созданные из класса 222 дочерних посредников, являются «оболочкой» для каждого дочернего объекта-презентатора родительского объекта-презентатора. В графическом представлении древовидной структуры презентаторов для видимого изображения 202а дочерние посреднические объекты представлены стрелками на линиях, соединяющих родительский презентатор с его дочерними объектами презентаторов. Дочерние посреднические объекты ограничивают доступ со стороны родительского объекта презентатора к его дочерним объектам презентаторов.

Обработчики (Nx) уведомлений отвечают за уведомление соответствующих презентаторов (Рх) об изменениях состояния данных в их графических элементах (Ех). Обработчики Nx уведомлений не оказывают существенного влияния на работу системы управления представлением/компоновкой. Они только облегчают пошаговые обновления презентаторов, выполняя их только при появлении изменения элемента в видимом изображении.

На фигурах 4а и 4b изображено, что базовый класс презентаторов включает в себя набор методов, свойств и полей. В одном варианте изобретения свойства доступны на конкретном объекте-презентаторе, к которому идет обращение, путем инициирования операций получения/установки на объекте. Свойство 400 фона задает значение окраски для фона презентатора. Свойство 402 непрозрачности фона хранит значение, задающее непрозрачность фона. Свойство 404 границы хранит значение, задающее толщину границы, очерчивающей пространство компоновки презентатора по краям. Свойство 404 границы хранит, например, четыре значения, указывающие ширину границы для верхней, нижней, правой и левой сторон прямоугольника, выделенного презентатором. Свойство 406 цвета границы определяет значение, обозначающее цвет границы вокруг презентатора. Свойство 408 стиля границы хранит значение, указывающее один из набора стилей отображения границы. Пример стилей границы включает в себя: сплошной, углубленный, ребристый, вложенный и с возвышением.

Свойство 410 ограничивающего прямоугольника задает зону (например, прямоугольник), в которой изображаются графические элементы презентатора (или дочерние элементы). Размер по умолчанию свойства 410 ограничивающего прямоугольника совпадает с размером, заданным в поле 460 размера компоновки. Однако размер ограничивающего прямоугольника может превышать размер компоновки, что позволяет презентатору создавать изображение вне размера компоновки.

С другой стороны, если свойство 414 усечения установлено равным значению «истина», то тогда презентатор (и его дочерние презентаторы) не может быть изображен вне прямоугольника, заданного полем 460 размера компоновки. Если значение свойства 414 усечения установлено равным «истина», то тогда свойство 410 ограничивающего прямоугольника не превышает размер компоновки. Это гарантирует, что изображенный презентатор не воспроизводит графические элементы вне выделенного для него пространства компоновки.

Свойство 412 дочерних элементов представляет собой массив или, в альтернативном варианте, любую другую подходящую многоэлементную структуру данных, где хранятся ссылки (например, метки, указатели, прямые/косвенные и т.д.) на дочерние презентаторы, вложенные в родительский презентатор, и их преобразованные местоположения в пространстве компоновки родительского презентатора. Свойство 412 дочерних элементов находится на презентаторе при первом использовании в контексте вызова метода OnUpdate (обновление), который описан ниже. Термин «при первом использовании» относится к случаю, когда родительский презентатор последовательно запрашивает набор дочерних элементов, а набор дочерних элементов располагается вместе с презентаторами, соответствующими дочерним графическим элементам графического элемента, который соответствует родительскому презентатору, из дерева графических элементов, во вспомогательном запоминающем устройстве (например, во вспомогательном запоминающем устройстве 208). Свойство 412 дочерних элементов облегчает установление/поддержание иерархии, отражающей вложенные взаимосвязи с презентаторами в видимом изображении. В одном варианте изобретения записи массива имеют ссылки на дочерние посреднические объекты. Дочерние посреднические объекты являются объектами-«оболочками» для дочерних объектов презентаторов, которые вложены в пространство отображения, выделенное для родительского объекта презентатора. «Оболочка» дочернего посреднического объекта удовлетворяет требованиям инкапсулирования и безопасности (например, дочерний презентатор ограничивает доступ к своему контенту со стороны родительского презентатора).

Свойство 414 усечения, как описано выше, устанавливает, будет ли ограничен контент презентатора путем усечения до размера компоновки презентатора, заданного полем 460 размера презентатора.

Набор свойств обозначает пространство, выделенное контенту в пространстве презентатора. Вдобавок к свойству 404 границы свойство 416 заполнения задает объем пространства внутри границы, который остается незанятым контентом. Свойство 418 высоты контента задает значение, указывающее высоту контента в презентаторе - высота части презентатора, которая остается после учета значений, заданных в свойстве 404 границы и свойстве 416 заполнения. Свойство 420 ширины контента задает значение, указывающее ширину, выделенную контенту в презентаторе с учетом параметров свойства 404 границы и свойства 416 заполнения. Комбинация свойства 418 высоты контента и свойства 420 ширины контента задает зону презентатора, которую потенциально занимает контент в презентаторе.

Свойство 422 высоты и свойство 424 ширины задают действительную высоту и ширину презентатора, причем эти два значения включают в себя параметры контента, заполнения и границы. Свойство 422 высоты по умолчанию и свойство 424 ширины по умолчанию задают значения по умолчанию, присваиваемые презентатору, когда свойство 422 высоты и свойство 424 ширины не предоставлены для конкретного объекта презентатора. Свойство 430 максимальной ширины и свойство 432 минимальной ширины задают границы для значения, присваиваемого свойству 424 ширины.

Еще одним размерным свойством для презентаторов является свойство 434 полей (страницы). Свойство 434 полей задает буферное пространство вне границы презентатора. Свойство 434 полей задается дочерним презентатором и доступно его родительскому презентатору при упорядочивании компоновки с иерархической структурой из вложенных презентаторов.

Свойство 436 видимости задает состояние видимости презентатора. Свойство 436 видимости связано с определением того, каким образом визуализируется графическое изображение, соответствующее презентатору и его дочерним презентаторам (или с определением того, визуализируется ли в принципе это графическое изображение). В одном варианте изобретения потенциальные состояния видимости включают в себя: видимое, сжатое и скрытое.

Ряд свойств презентаторов используют для связывания презентаторов с другими объектами в системе управления компоновкой/представлением. Свойство 438 презентатора задает тип презентатора, который используют для компоновки и визуализации графического элемента. Тип презентатора изначально установлен на графическом элементе, а система 200 презентаторов считывает свойство 438 презентатора из графического элемента и создает объект презентатора, соответствующий типу презентатора, идентифицированному свойством 438 презентатора. Свойство 408 презентатора передается в блок создания, который, в свою очередь, создает экземпляр презентатора идентифицированного типа. Свойство 440 IsMainPresenter определяет, является ли презентатор единственным презентатором либо основным (например, последним) в наборе сцепленных презентаторов, связанных с объектом-графическим элементом. Обратимся к фиг.3, где презентатор Р4 является главным презентатором для цепочки, включающей в себя B4 и Р4. В одном варианте изобретения свойство 440 IsMainPresenter является свойством булева (логического) типа.

Свойство 442 владельца элемента идентифицирует графический элемент, для которого был задан (создан) презентатор. Вновь обратимся к фиг. 3, где пунктирные линии, соединяющие презентаторы (Px) с соответствующими графическими элементами (Ех), представляют связи, обозначенные контентом свойства 442 владельца элемента. Свойство 444 контекста компоновки задает глобальный контекст, который облегчает обмен сообщениями между презентаторами в процессе компоновки. Значения, хранящиеся в свойстве 444 контекста компоновки, позволяют презентаторам передавать сообщения независимо от системы 200 презентаторов. Свойство 446 обработчика уведомлений задает ссылку на обработчик уведомлений для данного презентатора. Свойство 448 типа обработчика уведомлений задает тип обработчика уведомлений, на который ссылается свойство 446 обработчика уведомлений.

Свойство 450 «загрязненности» определяет, был ли изменен конкретный презентатор и, следовательно, требуется ли операция обновления. Система 200 презентаторов и соответствующие компоненты архитектуры управления компоновкой поддерживают пошаговую обработку компоновки. Свойство 450 «загрязненности», поддерживаемое каждым презентатором, указывает отдельно по каждому презентатору, требуется ли его обновление.

На фиг. 4а в качестве примера представлен итоговый набор полей базового класса презентаторов. В одном варианте изобретения эти поля являются полями Общей системы поддержки времени выполнения (Common Language Runtime (CLR)) (по аналогии с известными принадлежащими переменными в классах С++). В одном варианте изобретения вышеописанные свойства аналогичны полям. Однако свойства на графических элементах (например, на графических элементах 206) принадлежат и управляются вспомогательным запоминающим устройством (например, вспомогательное запоминающее устройство 208). При изменении свойства это вспомогательное запоминающее устройство уведомляет механизм представления об изменении. Механизм представления (например, механизм 212 представления для системы 200 презентаторов), в свою очередь, уведомляет соответствующие обработчики 224 уведомлений. Таким образом, в случае со свойством уведомление об изменении принимается через один из вышеупомянутых обработчиков уведомлений. С другой стороны, вспомогательное запоминающее устройство 208 не управляет полями (вместо этого полями управляет, например, CLR). Поэтому при изменении поля никакие уведомления об изменениях в механизм представления не передаются.

Поле 460 размера компоновки поддерживает размеры пространства компоновки, выделенного презентатору. Поле 460 размера компоновки используют для упорядочивания соседних презентаторов в компоновке страничного/пользовательского интерфейса. Поле 462 воздействия на компоновку представляет собой набор свойств (например, граница, заполнение и т.д.) презентатора, которые при их изменении влияют на компоновку презентатора. Поле 464 воздействия на компоновку для родительского презентатора представляет набор свойств (например, поля, видимость и т.д.) презентатора, который при изменении элемента (например, элемент А), «загрязняет» (то есть потенциально воздействует на) компоновку первого родительского презентатора для элемента (элемент А), имеющего заданный презентатор. Поле 466 визуализации эффектов является механизмом уведомления, который инициирует аннулирование и повторную визуализацию презентатора.

Обратимся теперь к методам базового класса 206 презентаторов, перечисленных на фиг. 4b, где способ 470 OnUpdate выполняет измерение и позиционирование задач на презентаторе для одного элемента. Авторы презентаторов переписывают версию базового класса метода 470 OnUpdate для создания/обеспечения режима задания размеров/позиционирования компоновки согласно требованиям пользователя для соответствующего видимого изображения элемента.

Первым действием по умолчанию при использовании метода 470 OnUpdate является задание размеров презентатора. Метод 470 OnUpdate получает размеры презентатора в поступившем параметре BoxSizeInfo (информация о размерах прямоугольника). Метод 470 OnUpdate устанавливает размеры, заданные в поле 460 размера компоновки в соответствии с заданными значениями BoxSizeInfo, свойства 428 ширины по умолчанию и свойства 426 высоты по умолчанию. Дополнительные источники информации о размерах/позиционировании для презентатора являются составной частью раскрытой архитектуры обработки компоновки/представления на основе презентаторов, причем указанные источники используют в альтернативных вариантах изобретения.

Второй задачей по умолчанию при использовании метода 470 OnUpdate является позиционирование дочерних презентаторов в локальном размерном пространстве презентатора. Версия базового класса метода 470 OnUpdate итеративно вызывает метод 470 OnUpdate для дочерних презентаторов, идентифицированных в свойстве 412 дочерних презентаторов для раскрытия их размеров и дочерних презентаторов. После установления и измерения дочерних презентаторов, эти презентаторы позиционируются в родительском презентаторе путем вызова метода преобразования (обсуждаемого ниже) для отдельных дочерних презентаторов. Итеративные вызовы метода 470 OnUpdate для дочерних презентаторов заканчиваются, когда в презентаторе не заданы дополнительные дочерние презентаторы. Вдобавок к регистрации размера в поле 460 размера компоновки и итеративному вызову/позиционированию дочерних презентаторов метод 470 OnUpdate возвращает вызывающей стороне значение, указывающее на то, требуется ли визуализация, принимая во внимание вызов метода 470 OnUpdate.

Метод 471 регистрации «атомов» регистрирует имя строки для презентатора для контекста 444 компоновки, а также любые другие подходящие списки презентаторов, включая те, которые поддерживаются расширениями к презентаторам. Метод 471 регистрации «атомов» вызывается, например, для установления связи с другим презентаторским объектом нестандартным образом (например, методом, не поддерживаемым в данный момент прикладным программным интерфейсом презентаторов). Презентаторы регистрируют «атом», а затем устанавливают объект, с которым они хотят установить связь, используя этот «атом». Например, дочерний презентатор хочет передать источник текста родительскому презентатору. Дочерний презентатор регистрирует «атом» с меткой/ярлыком «Descent» (происхождение) и принимает идентификационные данные для этого «атома». Дочерний презентатор вычисляет «источник» и устанавливает значение в атоме с использованием идентификационных данных. Затем родительский презентатор использует идентификационные данные (которые также получены путем регистрации «Descent») для извлечения хранящейся информации.

Метод 472 OnUpdateBoundingBox (обновление ограничивающего прямоугольника) создает свойство 410 обновленного ограничивающего прямоугольника для презентатора. Метод 472 OnUpdateBoundingBox вызывается тогда, когда метод 470 OnUpdate возвращает значение (например, «истина», указывающее на то, что необходима повторная визуализация). Реализация по умолчанию метода 472 OnUpdateBoundingBox, предусмотренного в базовом классе презентаторов, сканирует дочерние презентаторы, идентифицированные в свойстве 412 дочерних презентаторов для данного презентатора, и объединяет (то есть выполняет математическое объединение прямоугольников) преобразованные свойства дочернего ограничивающего прямоугольника с размерами презентатора, хранящимися в поле 460 размера компоновки. Реализация базового класса для метода 472 OnUpdateBoundingBox также обращается к свойству 414 усечения, и если его значение равно «истина», то ограничивающие прямоугольники дочерних презентаторов игнорируются. Вместо этого дочерние презентаторы будут усечены до размеров, указанных в поле 460 размера компоновки для их родительского презентатора. Презентаторы, изображение которых выходит за рамки поля 460 размера компоновки, вызывают перезапись упомянутого метода. Такие классы презентаторов, настроенные в соответствии с требованиями пользователя, вызывают базовый презентаторский класс и добавляют дополнительную «красочную зону» в их программу перезаписи. В одном варианте изобретения презентаторам предоставлена возможность оценки «красочной зоны» на предмет того, больше ли она, чем это требуется в действительности. Если зона 410 свойства ограничивающего прямоугольника меньше, чем зона, необходимая для начертания презентатора, то тогда рисунок усекается на основе размеров свойства 410 ограничивающего прямоугольника, заданных для презентатора.

Метод 474 OnRender вызывается для презентаторов, которые запрашивают/требуют повторную визуализацию. Метод 474 OnRender является первоочередным вызовом для презентатора для повторной визуализации презентатора и любого из его дочерних презентаторов. Метод 474 OnRender предпочтительно вызывается после того, как вызван метод 470 OnUpdate на всех «загрязненных» презентаторах в компоновке (например, сцена). В одном варианте изобретения метод 474 OnRender вызывают из презентаторских объектов на основе анализа того, обеспечил ли вызов метода 470 OnUpdate для объекта/презентатора возвратную индикацию о том, что презентатор запрашивает повторную визуализацию. В одном варианте изобретения метод 474 OnRender базового класса выполняет для презентатора операции упорядочивания представления/компоновки независимо от конкретного устройства. Другие компоненты, в том числе подсистема графики и драйверы 234 графических устройств, визуализируют видимое изображение презентатора в формате, привязанном к конкретному устройству. Производные варианты метода 474 OnRender, учитывающие требования пользователя, включают в себя обращения к компонентам компьютерной системы, формирующим графические элементы, для визуализации выходных данных документного/пользовательского интерфейса.

В одном варианте изобретения версия базового класса для метода 474 OnRender визуализирует контент презентатора, включая любые дочерние элементы, на трех этапах обработки компоновки. На этапе OnRenderBeforeChildren (визуализация до дочерних презентаторов) объект презентатора вызывает операции, предназначенные для обработки, до обработки какого-либо из его дочерних презентаторов. В одном варианте изобретения реализация базового класса для метода 474 OnRender предоставляет подключение (ловушку) для настройки и не задает какие-либо операции предобработки на этапе OnRenderBeforeChildren. Однако приведенная в качестве примера настраиваемая замена этого режима по умолчанию, учитывающая конкретные требования пользователя, устанавливает/изображает пользовательский фон для зоны отображения презентатора.

Версия базового класса метода 474 OnRender на этапе визуализации дочерних презентаторов обращается к дочерним презентаторам, идентифицированным в свойстве 412 дочерних презентаторов. Метод 474 OnRender вызывается, в свою очередь, для каждого из дочерних презентаторов (для расширения запрашиваемого дочернего презентатора, когда реализован метод 470 OnUpdate). Таким образом, вызов высокого уровня метода 474 OnRender распространяется последовательно на дочерние презентаторы и на их потомки, пока не будет достигнут низ дерева (то есть презентатор, не имеющий дочерних презентаторов). После завершения вызова высокого уровня все дочерние презентаторы в дереве, которые запрашивали повторную визуализацию, окажутся вновь визуализированными.

На этапе OnRenderAfterChildren (визуализация после дочерних презентаторов) презентатор объекта вызывает операции, которые должны выполняться после вызова метода 474 OnRender для дочерних презентаторов, идентифицированных в свойстве 412 дочерних презентаторов. Версия базового класса метода 474 OnRender предоставляет ловушку (подключение) для настройки в соответствии с требованиями конкретного пользователя и не задает какие-либо операции постобработки на этапе OnRenderAfterChildren. Тем не менее, примеры такой настройки включают в себя аннотации, элементы «отделки» и т.д.

Если презентатор не визуализирует повторно какие-либо объекты, отличные от дочерних презентаторов, то тогда нет необходимости переписывать версию базового класса метода 474 OnRender. Однако, если самому презентатору необходимо что-то «нарисовать», то тогда базовый класс для метода 474 OnRender переписывается для визуализации графических данных в пространстве, выделенном этому презентатору. Программа замены включает в себя, например, вызовы приложений 230 и/или подсистемы графики и драйверов графических устройств. Сцепленный презентатор находится в дереве презентаторов для конкретного видимого изображения. Если для сцепленного презентатора требуется повторная визуализация, то тогда системой презентаторов будет вызван его метод OnRender таким же образом, как метод OnRender для основного презентатора.

В контексте этого приложения термин «проверка совпадения» относится к процессу идентификации того, какой презентатор попал в конкретную точку сеточного координатного пространства графического пользовательского интерфейса. Проверку совпадения используют, например, для определения местоположения указателя мыши (например, над каким презентатором он находится), когда пользователь щелкает по одной из кнопок мыши. Метод 476 OnHitTestDetail (детали проверки совпадения) возвращает данные, хранящиеся в структуре HitTestDetail для презентатора. Настроенный в соответствии с требованиями пользователя класс презентатора переписывает реализацию базового класса для метода 476 OnHitTestDetail для помещения в структуру HitTestDetail, чтобы дать возможность презентатору вернуть данные, иные чем совпавший элемент и презентатор, тем самым обеспечивая, например, более подробную информацию, относящуюся к презентатору, такую как часть презентатора, которая действительно попала в указанную точку (например, положение символа относительно текста).

Метод 478 OnCreateViewResult (создание результирующего видимого изображения) имеет параметры, описывающие вычисленное состояние презентатора в результирующем объекте видимого изображения. Пользователи запрашивают результирующий объект - видимое изображение для какого-либо элемента в контексте обозначенного видимого изображения. Версия базового класса для метода 478 OnHitTestDetail предоставляет, через результирующий объект-видимое изображение, высоту, ширину и положение верхнего левого угла презентатора. Если требуется дополнительная/альтернативная информация, касающаяся состояния презентатора, такая как количество строк текста, содержащихся в презентаторе, то тогда версия базового класса для метода 478 OnHitTestDetail переопределяется для предоставления требуемой информации через результирующий объект-видимое изображение.

Метод 480 проверки попадания инициирует проверку попадания на поддереве, корнем которого является заданный презентатор. В метод 480 проверки попадания передают координаты точки (в локальных координатах презентатора), где должна быть выполнена проверка попадания. Метод 480 проверки попадания возвращает данные проверки попадания, содержащие результаты проверки попадания для обозначенной точки и презентатора. Результат содержит все визуалы, в которые попадает указанная точка. Визуал является базовым объектом (например, линией), на основе которого презентатор создает отображаемое изображение. Визуал - это графический объект, обладающий способностью реального вычерчивания изображения на выходе графического дисплея. При вызове метода OnRender презентатора для API визуала выдаются несколько вызовов, например, для визуализации текста, изображений, видео и т.д.

Метод 482 OnGetBypassList (получение списка обходов) предоставляет список дочерних презентаторов, вычисленных ранее для идентифицированного презентатора. Этот список дочерних презентаторов облегчает обход дочерних презентаторов в ходе вычисления компоновки (например, путем сравнения нового дочернего презентатора компоновки с ранее вычисленными дочерними презентаторами компоновки и повторного использования ранее вычисленного презентатора, если имеется совпадение с одним из презентаторов в списке). Если презентатор раскрывает свои дочерние презентаторы путем обращения к набору свойства 412 дочерних презентаторов, он не должен подменять данный метод. Однако, если презентатор использует описанный ниже метод 486 GetChildProxyForElement (получение дочернего посреднического презентатора для элемента), то метод 482 OnGetBypassList обычно подменяют.

При использовании системы компоновки, воплощающей настоящее изобретение, в случае вызова метода 486 GetChildProxyForElement перед методом 470 OnUpdate вызывается метод 482 OnGetBypassList, и объект презентатора создает и заполняет список-массив дочерними посредническими объектами (описанными ниже со ссылками на фиг.5), которые он кэшировал из предыдущего вычисления компоновки. Если объект презентатора не имеет кэш для хранения повторно вычисленных дочерних посреднических объектов, то все дочерние презентаторы объекта презентатора вычисляют повторно для каждого вызова метода 470 OnUpdate для презентатора.

Метод 484 вычисления границ вычисляет и возвращает границы подграфа, имеющего в качестве корня идентифицированный визуал.

Как было объяснено выше, дочерний посреднический объект является объектом-«оболочкой», который действует в качестве посредника между родительским презентатором и дочерним презентатором для конкретного графического элемента. К дочерним посредническим объектам для дочерних презентаторов конкретного объекта презентатора обращаются как к набору в свойстве 412 дочерних презентаторов для объекта презентатора. Метод 486 GetChildProxyForElement является методом для родительского объекта презентатора, который создает дочерний посреднический объект и объект презентатора для заданного элемента. Метод возвращает значение «null», если у заданного элемента нет презентатора.

Метод 488 OnBeforeBypass вызывается, когда система 200 презентаторов хочет «обойти» конкретный презентатор (то есть пропустить вызов метода 470 OnUpdate презентатора). Такой обход имеет место, например, тогда, когда презентатор не «загрязнен», и размерные параметры (BoxSizeInfo) (информация о размерах прямоугольника) презентатора, введенные по вызову метода 470 OnUpdate, не изменились с момента последнего вызова метода 470 OnUpdate для данного презентатора. Метод 488 OnBeforeBypass является механизмом, который повышает эффективность функционирования, позволяя презентаторам, которые имеют свой собственный пользовательский набор дочерних посреднических объектов (которые используют метод 486 GetChildProxyForElement), повторно использовать дочерние посреднические объекты своих дочерних презентаторов при выполнении обновления компоновки (например, когда изменению подвергнута только малая часть компоновки).

Метод 490 OnDisconnectChildren (отсоединение дочерних презентаторов) удаляет все дочерние объекты презентаторов из набора дочерних презентаторов, определенных в свойстве 412 дочерних презентаторов для заданного презентатора. Если свойство 412 по умолчанию для дочерних презентаторов подменено для класса презентаторов, полученного из базового класса 216 презентаторов, то тогда метод 490 OnDisconnectChildren также подменяется, чтобы обеспечить правильное расположение дочерних презентаторов.

Проход Min/Max представляет собой специальный проход (просмотр) для задания размеров, который используют презентаторы, участвующие в данной операции (например, DockPresenter), при задании размеров дочерних презентаторов для контента. Знание минимального и максимального значений ширины для дочерних презентаторов позволяет родительскому презентатору рационально распределять пространство между множеством дочерних презентаторов, совместно использующих конкретное значение ширины. Без информации о минимальном/максимальном значении, предоставляемой функцией MinMaxPass, участвующему презентатору потребовалось бы множество проходов для рационального задания размера для контента. Метод 492 OnMinWidth (состояние минимальной ширины) вызывается после прохода (просмотра) Min/Max. Метод 492 OnMinWidth вызывает значение MinWidth, которое является побочным результатом вычисления MaxWidth. Версия базового класса для метода 492 OnMinWidth выдает сообщение «I don't care» («Мне безразлично»), которое инициирует прогон вычислений с ProposedSize (предложенный размер) = (0, бесконечность) и оба направления «NotFixed» (не фиксированы).

Метод 494 презентатора является методом конструирования для экземпляра презентатора. Метод 494 презентатора не имеет параметров. Метод 494 презентатора инициируется тогда, когда система 200 презентаторов конкретизирует данный презентатор. Метод 494 презентатора устанавливает экземпляр презентатора, позволяя инициировать другие методы (например, OnUpdate) на презентаторе.

Метод 496 QueueLayoutTask (организация очереди задач компоновки) добавляет определенную задачу компоновки, подлежащую выполнению применительно к данному объекту презентатора, в очередь задач компоновки, выполняемых системой 200 презентаторов. Когда эта заданная задача компоновки окажется в начале очереди, система 200 презентаторов вызывает метод 604 OnLayoutTask (запуск задачи компоновки), который описан ниже, в обработчике уведомлений для данного презентатора.

Метод 498 OnQueryValue (состояние значения запроса) возвращает значение, соответствующее заданному вычисленному значению для презентатора.

Опираясь на описание базового класса 216 презентаторов, обратимся к фиг. 5, которая дает итоговое представление о свойствах и методах приведенного в качестве примера варианта дочернего посреднического класса 222. Как было объяснено ранее, в одном варианте изобретения дочерние посреднические объекты являются оболочками для объектов презентаторов, являющихся дочерними объектами родительского объекта презентатора, причем эти дочерние посреднические объекты поддерживают ограниченный доступ со стороны родительского объекта к ресурсам дочерних объектов презентаторов. Все передачи данных (запросы/ответы) между родительским объектом презентатора и дочерним объектом презентатора направляют через дочерний посредник для данного дочернего презентатора. Дочерний посреднический объект поддерживает ссылку на дочерний презентатор и направляет вызовы/запросы от родительского презентатора на дочерний презентатор.

В одном варианте системы 200 презентаторов класс 222 дочерних посредников включает в себя свойство 500 владельца элемента, которое указывает элемент в графических элементах 206, с которым связан презентатор дочернего посредника, с которым связана ссылка.

Свойство 502 преобразования позиционирует дочерний объект презентатора (и связанные с ним визуалы) внутри его родительского объекта презентатора. Преобразование реализуется через стандартную графическую матрицу преобразования 3х3 в базовом классе визуальных объектов. Когда матрица преобразования установлена, объект визуала, связанный с графическим элементом презентатора, помещает свой дочерний презентатор со смещением, заданным матрицей преобразования.

Свойство 504 ограничивающего прямоугольника задает границы визуализации дочернего презентатора. Таким образом, границы визуализации дочернего презентатора могут отличаться от размера компоновки для дочернего презентатора.

Свойство 506 «загрязненности» задает состояние «загрязненности» презентатора дочернего посредника. В одном варианте системы 200 презентаторов состояние «загрязненности» бывает одним из: чистое, «свидетель загрязнения» (dirty bystander) либо «загрязненное». «Чистое» состояние указывает, что в дочернем презентаторе с момента последнего обновления видимого изображения изменений дочернего презентатора не было. «Загрязненное» состояние указывает на то, что с момента последнего обновления видимого изображения появилось изменение дочернего презентатора. Состояние «свидетель загрязнения» указывает на то, что по меньшей мере один из потомков дочернего презентатора «загрязнен», но сам дочерний презентатор не загрязнен. Указанные состояния позволяют родительским презентаторам оптимизировать операции обновления.

Метод 510 QueryDefaultSizeInfo (запрос информации о размерах по умолчанию) инициализирует размеры дочернего презентатора на основе значений по умолчанию, предоставляемых родительским презентатором данного дочернего презентатора.

Метод 520 Update (обновление) запрашивает дочерний посредник, чтобы инициировать метод 470 OnUpdate на дочернем презентаторском объекте. Родительский презентатор вызывает метод 520 Update на дочернем посреднике, когда родительский презентатор выполняет поиск для вычисления компоновки дочернего презентатора. Вызов метода 520 Update включает в себя два пересылаемых параметра. Информация о размере прямоугольника задает размеры прямоугольника, в котором дочерним презентатором должна вычисляться компоновка, и если активизировано разбиение на страницы, то родительский презентатор передает страничную информацию в параметре дескриптора страницы (смотри фиг. 10, которая описана ниже). Таким образом, метод 520 Update предоставляет уровень между вызывающей стороной и дочерним объектом-презентатором, который позволяет экранировать/фильтровать указанные запросы к дочернему объекту-презентатору. Метод 520 Update предоставляет механизм обхода вызовов, обычно направляемых к методу OnUpdate на дочернем презентаторе. Например, вызов метода 520 Update инициируют в тех случаях, когда дочерний презентатор не был изменен и не были изменены входные параметры (информация о размерах прямоугольника и описание страницы).

Метод 530 присоединения, выдаваемый родительским презентатором дочернему посреднику, вызывает команду OnRender для дочернего презентатора, связанного с дочерним посредником.

Метод 540 значения запроса предоставляет значение презентатора, соответствующее вычисленному типу (свойству) значения, идентифицированному в вызове метода. Вызов метода 540 значения запроса делегируется соответствующему методу 498 OnQueryValue на дочернем объекте презентатора.

Метод 550 запроса размера компоновки предоставляет вычисленные размерные параметры компоновки. Вызов метода 550 запроса размера компоновки делегируется соответствующему методу 496 OnQueryValue на дочернем объекте презентатора. Метод 560 вычисления MinMax предоставляет минимальное и максимальное значения ширины дочернего презентатора.

Обратимся к фиг. 6, где набор базовых классов, связанных с системой 200 презентаторов, включает в себя базовый класс обработчиков уведомлений. Как было объяснено выше, объекты-обработчики уведомлений принимают все уведомления, касающиеся изменений, потенциально влияющих на презентатор, связанный с конкретным видимым изображением (видом), накапливают информацию о «загрязненности» и облегчают определение того, требуется ли обновление соответствующего объекта презентатора. Оба метода из базового класса обработчиков уведомлений принимают в качестве параметра объект, включающий в себя метод, который предоставляет необходимую информацию из элемента в числе графических элементов (например, графические элементы 206), с которыми связан обработчик уведомлений.

Базовый класс обработчиков уведомлений включает в себя метод 600 OnNotify (уведомление), который обеспечивает уведомление о «загрязненности» конкретного связанного с ним объекта презентатора. Метод 600 OnNotify потенциально включает в себя дополнительные, сформулированные с учетом требований пользователя производные задачи уведомления (путем подмены действия по умолчанию, состоящего в предоставлении значения свойства «загрязненности»), которые выполняют в ответ на прием уведомления. Метод 600 OnNotify в качестве входного параметра принимает информацию об изменении, в результате которого было послано уведомление. Метод OnNotify возвращает булево значение, указывающее на то, может ли обработчик уведомлений обработать изменение сам (либо указывающее на то, требуется ли уведомить обработчик уведомлений для презентатора-предка в дереве презентаторов для видимого изображения). Метод возвращает также значение «загрязненности», указывающее на то, является ли презентатор «чистым», «загрязненным» или относится к состоянию, названному как «свидетель загрязненности».

Метод 602 OnLayoutTask (запуск задачи компоновки) выполняет задачи, поставленные ранее в очередь соответствующим презентатором посредством QueueLayoutTask.

Обратимся к фиг. 7, где набор базовых классов, связанных с системой 200 презентаторов, дополнительно включает в себя класс узла обработчика уведомлений. Класс узла обработчика уведомлений является узловым объектом, передаваемым объекту-обработчику уведомлений, который позволяет обработчику уведомлений вызывать услуги уведомления, поддерживаемые системой 200 презентаторов.

Класс узла обработчика уведомлений включает в себя свойство 700 владельца элемента, задающее объект-графический элемент, с которым связан объект-узел обработчиков уведомлений.

Метод 702 регистрации «атома» регистрирует предоставленное имя строки в контексте 444 компоновки для обработчика уведомлений. Функциональные возможности метода 702 регистрации «атома» аналогичны методу 471 регистрации «атома», описанному выше со ссылками на базовый класс презентаторов. Таким образом, метод 702 регистрации «атома» является средством для передачи запросов от обработчика уведомлений к другим объектам (например, объекты презентаторов).

Метод 704 создания уведомлений создает новый объект-уведомление презентатора и использует эти поля на основе переданных параметров. Переданные параметры включают в себя идентификационные данные о типе «атома» (указывающие тип объекта-уведомления презентатора) и данные уведомления.

Метод 706 уведомления «потомков» вызывает метод 600 OnNotify для обработчиков уведомлений, связанных с потомками презентатора, к которым привязан узел обработчика уведомлений, для пересылки заданного уведомления презентатора. Метод 706 уведомления «потомков» выполняет функцию уведомления презентаторов-потомков о любых изменениях в родительском презентаторе (например, повторное задание размеров). Аналогичным образом метод 708 уведомления «предков» вызывает метод 600 OnNotify для обработчиков уведомлений, связанных с «предками» презентатора, к которым привязан узел обработчиков уведомлений, для пересылки заданного уведомления для презентатора. «Предки» определяются путем обхода дерева графических элементов (смотри фиг. 3) во вспомогательном запоминающем устройстве 208. Графические элементы, представленные во вспомогательном запоминающем устройстве, включают в себя свойство, которое задает «родителя» (промежуточный предок) графического элемента. Метод 710 «уведомления всех» вызывает метод 600 OnNotify в объектах-обработчиках уведомлений для всех презентаторов в дереве презентаторов, принадлежащем видимому изображению, для пересылки заданного уведомления. Наконец, метод 712 «самоуведомления» обеспечивает для презентатора средство вызова метода 600 OnNotify для того, чтобы отметить собственную «загрязненность».

Обратимся к фиг. 8, где на примере показан класс объектов-видимых изображений, из которого создается видимое изображение 202. Объекты видимого изображения имеют экземпляр системы презентаторов (например, систему 200 презентаторов) и являются визуальным «корнем» всех визуалов, созданных в созданном экземпляре системы презентаторов. Объект видимого изображения инициирует все вычисления на презентаторах в видимом изображении. Метод 800 для видимого изображения является методом-конструктором, который используют для создания нового объекта видимого изображения. Видимое изображение принимает в качестве переданного параметра ссылку на элемент, который является корневым графическим элементом видимого изображения. Свойство 802 RootElement (корневой элемент) возвращает ссылку на корневой графический элемент для видимого изображения (которое было установлено с помощью вышеописанного метода 800 для видимого изображения).

Метод 804 DoLayout создает новое дерево презентаторов для видимого изображения и возвращает ссылку на новое дерево. Метод 804 DoLayout принимает в качестве входных параметров предложенные высоту и ширину для прямоугольника видимого изображения, а также два булевых значения (фиксированная ширина и фиксированная высота), которые устанавливают, могут ли предложенные размеры измениться во время выполнения метода 804 DoLayout.

Свойство 806 ViewSize (размер видимого изображения) устанавливает размеры видимого изображения. Свойство 806 ViewSize (только для записи) используется тогда, когда объект видимого изображения располагается (хостируется) в окне, причем свойство 806 ViewSize представляет начальный размер, исходя из которого выполняется операция компоновки.

Метод 808 GetViewResult (получение результирующего видимого изображения) принимает в качестве входных данных ссылку на графический элемент, а затем метод 808 GetViewResult возвращает результирующее видимое изображение для графического элемента. Значение «null» возвращается в том случае, когда этот графический элемент отсутствует в наборе графических элементов для видимого изображения.

Метод 810 HitTest (проверка попадания) выполняет проверку попадания для переданной точки в системе координат видимого изображения. Метод 810 HitTest возвращает первый непрозрачный объект, полученный в результате проверки попадания. Если графический элемент не найден, то тогда метод возвращает значение «ложно».

Метод 812 CreatePage (создание страницы) принимает в качестве входных параметров BoxSizeInfo (смотри фиг. 9, описанную ниже) и PageDescriptor (смотри фиг. 10, описанную ниже). Метод 812 CreatePage создает новую страницу на основе введенных параметров и возвращает дочерний посреднический объект, соответствующий корневому графическому элементу для данной страницы.

Обратимся к фиг. 9, где в качестве примера показана структура BoxSizeInfo. Структура BoxSizeInfo задает набор размеров для презентаторов и их дочерних презентаторов в видимом изображении, а также определяет, каким образом эти размеры должны обрабатываться принимающей стороной. Свойство 900 предложенного размера устанавливает предложенный размер для дочернего презентатора в видимом изображении. Вначале значение свойства 900 предложенного размера поступает от свойств для дочернего графического элемента во вспомогательном запоминающем устройстве. Перед пересылкой дочернему презентатору оно может быть модифицировано родительским презентатором. Свойство 902 родительского размера является предложенным размером для родительского презентатора. Свойство 902 родительского размера используют, например, для вычисления размеров, исходя из значений в форме процентов от родительского презентатора, для дочерних презентаторов. Структура BoxSizeInfo также включает в себя два свойства с булевыми значениями, FixedWidth (фиксированная ширина) 904 и FixedHeight (фиксированная высота) 906, которые инструктируют принимающий презентатор, сообщая, является ли представленный размер предписанным (фиксированным значением), либо это значение размера просто предлагается в качестве высоты или ширины.

Обратимся к фиг. 10, где показаны части приведенной в качестве примера структуры дескриптора страницы. Дескриптор страницы включает в себя свойство 1000 PageSize (размер страницы). Свойство 1000 PageSize является свойством только для считывания, которое задает размер страницы. Оно инициализируется при создании структуры дескриптора страницы. Свойство 1002 обрыва записи является структурой, которая включает в себя: начальное положение символа, идентифицирующее первый символ текущего презентатора, который находится на следующей странице (относительно графического элемента, который является корнем видимого изображения, разбиваемого на страницы); количество символов (отсчитываемое назад от начала расположения символов), которое может аннулировать предыдущую страницу; и булево значение IsDirty (загрязнено), которое указывает, оказалась ли недействительной оборванная запись (охватывающая конкретный диапазон символов в разбитом на страницы графическом элементе) в результате изменения во вспомогательном запоминающем устройстве.

Структура дескриптора страницы также включает в себя свойство 1004 AvailableSize (имеющийся размер). Полная страница не может быть доступна презентатору после начала выполнения метода OnUpdate на презентаторе. Свойство 1004 AvailableSize указывает пространство, остающееся на странице для презентатора. Свойство 1004 AvailableSize инициализируется значением размера страницы.

Обратимся к фиг. 11, где определен набор методов, которые выполняются механизмом 212 представления системы 200 презентаторов, созданной видимым изображением 202 (смотри фиг. 2). Метод 1100 конструира в механизме 212 представления обращается к видимому изображению 202, которое содержит ссылку на корневой графический элемент для этого видимого изображения, предоставляемого деревом графических элементов 206. Метод 1102 DoLayout принимает ширину и высоту в виде переданных параметров, представляющих размеры видимого изображения 202, и в ответ приступает к выполнению процесса компоновки применительно к контенту графических элементов 206. Метод 1104 UpdateLayout (обновление компоновки), выполняемый по меньшей мере однократно после выполнения DoLayout, начинает пошаговое изменение ранее вычисленной компоновки для видимого изображения 202. Метод 1106 CreatePage получает в качестве входного параметра информацию о размере прямоугольника (BoxSizeInfo), которая содержит размеры отображаемой страницы и дескриптор страницы, содержащий информацию о том, каким образом начинать конкретную страницу. Вместо того чтобы отображать весь контент под корнем графических элементов 206 для видимого изображения 202, метод 1106 CreatePage отображает только одну интересующую страницу.

Приведенная в качестве примера архитектура для обработки компоновки была описана со ссылками на фиг. 1-11. Приведенная в качестве примера архитектура включает в себя выделенные состояния видимого изображения (объекты - презентаторы), связанные с состояниями данных для элементов (объекты - графические элементы). Показанная архитектура включает в себя систему 200 презентаторов, которая помогает расширить возможности компоновки/представления видимого изображения посредством базового класса 216 презентаторов, из которого получают новые классы объектов презентаторов, воплощающих новые функциональные возможности компоновки/представления. Раскрытые здесь система и архитектура также включают в себя механизм уведомления, связывающий элементы с соответствующими объектами презентаторов, для избирательного инициирования повторного вычисления частей видимого изображения в ответ на изменения. Показанные базовые классы объектов иллюстрируют множество потенциальных альтернативных вариантов реализации расширяемой архитектуры, воплощающей настоящее изобретение, причем их не следует рассматривать как ограничение объема изобретения.

Учитывая описанный здесь набор компонентов, образующих приведенную в качестве примера архитектуру обработки представления/компоновки, воплощающей настоящее изобретение, обратимся теперь к фиг. 12, где показан общий процесс обработки изменений в графически отображаемых элементах. Сначала на этапе 1200 происходят изменения во вспомогательном запоминающем устройстве 208. Например, приложение 204 выполняет операцию, которая приводит к изменению состояния и/или контента одного или нескольких отображаемых компонентов графического пользовательского интерфейса для этого приложения. В ответ на эти изменения на этапе 1202 механизм 212 представления в системе 200 презентаторов принимает уведомление об изменениях, появляющееся в результате изменения графического элемента во вспомогательном запоминающем устройстве.

В качестве основы на этапе 1204 система 200 презентаторов поддерживает связи между элементами и презентаторами в информационной связке «элемент - презентатор» (EPI). Всякий раз при создании презентатора для графического элемента создается ссылка на этот презентатор на элементе, которая запоминается в EPI, поддерживаемой системой презентаторов. Если графический элемент имеет больше одного презентатора, то тогда в EPI графического элемента будет множество ссылок (по одной на каждый презентатор). Когда свойство на графическом элементе изменяется, то выполняются следующие этапы:

(а) Вспомогательное запоминающее устройство отмечает изменение на графическом элементе;

(b) Вспомогательное запоминающее устройство 208 уведомляет механизм 212 представления об изменении со ссылкой на графический элемент, который изменил одно из своих свойств;

(с) Механизм 212 представления просматривает EPI графического элемента, который изменился, и определяет презентаторы, которые были созданы для этого графического элемента; и

(d) После определения презентатора механизм 212 представления получает ссылку на соответствующий обработчик уведомлений для презентатора (через свойство 446 обработчика уведомлений на презентаторе).

Таким образом, в свете вышесказанного, на этапе 1204 механизм 212 представления системы 200 презентаторов определяет идентичность (идентификационную информацию) презентатора, для которого используется уведомление об изменении. Как было объяснено выше, система презентаторов поддерживает список презентаторов, которые были конкретизированы для данного элемента в его EPI. После определения презентатора, для которого используется уведомление об изменении (в этом примере предполагается, что для данного элемента существует только один презентатор), механизм 212 представления в системе презентаторов получает ссылку на обработчик уведомления для презентатора через свойство 446 обработчика уведомлений на идентифицированном презентаторе.

Затем при выполнении этапа 1206 механизм 212 представления системы 200 презентаторов направляет уведомление об изменении обработчику уведомлений, используя ссылку, которая была получена на этапе 1204. В одном варианте изобретения этап 1206 выполняют путем инициирования метода 602 OnNotify на конкретном объекте-обработчике уведомлений.

После приема уведомления об изменении от системы презентаторов на этапе 1208 (например, во время выполнения метода 602 OnNotify) обработчик уведомлений определяет действия, если они имеются, которые необходимо предпринять презентатору для реагирования на указанные изменения в графическом элементе во время этапа 1200 во вспомогательном запоминающем устройстве 208. В одном варианте изобретения обработчик уведомлений определяет, для какой части, если она существует, соответствующего презентатора необходимо обновление в свете принятого уведомления об изменении. Указанные части включают в себя, например, дочерние элементы презентатора и сам презентатор.

Далее на этапе 1210 обработчик уведомлений (например, метод 602 OnNotify) возвращает результат, который позволяет соответствующему презентатору определить и выполнять действия в свете уведомления об изменениях, полученного системой 200 презентаторов в ходе выполнения этапа 1202. В одном варианте изобретения возвращаемый результат представлен в виде обработчика уведомлений/конкретного презентатора. В некоторых случаях в возвращаемом результате презентатор просто помечается как «загрязненный», в результате чего вызывается полное повторное вычисление соответствующего презентатора. В других случаях предоставляется информация для избирательного вызова лишь некоторых из возможностей повторного вычисления видимого изображения для презентатора.

В одном варианте изобретения механизм 212 представления системы 200 презентаторов принимает на этапе 1210 возвращенный результат от обработчика уведомлений для презентатора. После этого на этапе 1212, если изменения во вспомогательном запоминающем устройстве не вызывают необходимость повторного вычисления презентатора, управление переходит к этапу 1216 принятия решения. Однако, если на этапе 1212 возвращенный результат указывает на то, что необходимо повторное вычисление презентатора, то управление переходит к этапу 1214, на котором система 200 презентаторов добавляет презентатор к набору «загрязненных» презентаторов, требующих повторного вычисления. В приведенном в качестве примера варианте изобретения система презентаторов устанавливает свойство 450 «загрязненности» на соответствующем презентаторе (с указанием необходимости повторного вычисления презентатора) и добавляет этот презентатор в набор презентаторов, которые нуждаются в повторном вычислении. Презентаторы также задают информацию, описывающую содержание изменений, которые ведут к установке свойства 450 «загрязненности». Затем управление переходит к этапу 1216.

На этапе 1216, если для презентатора, связанного с интересующим в данный момент обработчиком уведомлений, родительский презентатор не существует, то управление переходит к этапу 1218 «конец». Если родительский презентатор действительно существует, то тогда управление переходит от этапа 1216 к этапу 1220, на котором создается (пересылается) уведомление для обработчика уведомлений родительского презентатора (что приводит к обработчику уведомлений для родительского презентатора, обрабатывающего уведомление), как показано пунктирной линией возврата к этапу 1208.

Таким образом, набор этапов, показанный на фиг. 12, позволяет системе 200 презентаторов аккумулировать список презентаторов, которые были «загрязнены» в результате изменений во вспомогательном запоминающем устройстве 220 с момента последнего вычисления компоновки для документного/пользовательского интерфейса.

Обратимся теперь к фиг. 13, где блок-схема алгоритма описывает примерный процесс повторного вычисления/повторной визуализации документного/пользовательского интерфейса в соответствии с изменениями в презентаторах в конкретном видимом изображении (смотри фиг. 12, описанную выше). В одном варианте изобретения приложение 204 управляет обновлениями видимого изображения 202 и вызывает процедуры обновления видимого изображения, такие как процедура, раскрытая на фиг. 13, в ответ на такие события, как окончание временного интервала, запрос на распечатку документа или изменение состояния графического пользовательского интерфейса.

Сначала на этапе 1300 система 200 презентаторов и конкретный механизм 212 представления принимает вызов метода 1102 DoLayout (описанный выше со ссылкой на описание API механизма 212 представления). В ответ на прием вызова метода 1102 DoLayout приложением 204 система 200 презентаторов повторно вычисляет объекты презентаторов, содержащиеся в видимом изображении 204, для размещения изменений в элементах во вспомогательном запоминающем устройстве с момента последнего вызова метода 1102 DoLayout.

В одном варианте настоящего изобретения, где презентаторы для видимого изображения иерархически упорядочены (смотри фиг.3), система 200 презентаторов сначала определяет на этапе 1302 корневой презентатор для видимого изображения. В одном варианте изобретения корневой презентатор идентифицируется свойством презентатора на корневом элементе, который приписан к видимому изображению (например, видимое изображение 204а) и, следовательно, к системе презентаторов (например, система 200а презентаторов). После определения корневого презентатора управление переходит к этапу 1304, где система 200 презентаторов начинает обход дерева презентаторов для видимого изображения и повторное вычисление каждого «загрязненного» презентатора.

На этапе 1304 система 200 презентаторов вызывает метод 470 OnUpdate на каждом «загрязненном» презентаторе в видимом изображении. Вызванный метод 470 OnUpdate передает высоту и ширину прямоугольника, в котором должна быть повторно вычислена компоновка презентатора. После повторного вычисления компоновки презентатор кэширует полученный результат. Таким образом, после завершения этапа 1304 ранее «загрязненные» презентаторы оказываются вычисленными повторно, а результаты повторных вычислений оказываются занесенными в кэш-память для легкого доступа во время последующей повторной визуализации. «Загрязненный» бит очищается в каждом из вызванных презентаторов. Далее, со ссылками на фиг. 14, более подробно описан набор этапов, выполняемых при вызове метода 470 OnUpdate.

Имеется несколько путей очистки «загрязненных» презентаторов на этапе 1304. Однако в варианте настоящего изобретения система 200 презентаторов и, в частности, метод 1104 OnUpdateLayout механизма 212 представления использует иерархические взаимосвязи между презентаторами в видимом изображении для упрощения выполнения своей функции на этапе 1304 завершения. В частности, во время выполнения метода 470 OnUpdate каждый вызванный презентатор итеративно вызывает (или, в альтернативном варианте, запрашивает систему 200 презентаторов для вызова) метод 470 OnUpdate на всех дочерних презентаторах вызванного презентатора. Таким образом, система 200 презентаторов начинает обход дерева презентаторов с метода 470 OnUpdate корневого презентатора (например, презентатор Р1 по фиг.3) и поддерживает последовательные вызовы дочерних презентаторов, когда вызов 470 метода OnUpdate обходит ветви иерархического дерева презентаторов для повторного вычисления «загрязненных» презентаторов. Итеративные вызовы метода 470 OnUpdate на дочерних презентаторах обеспечивают обход всех презентаторов в видимом изображении, и, если презентаторы «загрязнены», выполняется их повторное вычисление.

По окончании каждый метод 470 OnUpdate, вызванный на этапе 1304, устанавливает в исходное состояние свойство 450 «загрязненности», указывая, что было выполнено повторное вычисление или «очистка». Каждый метод 470 OnUpdate также возвращает вызывающей стороне значение, указывающее на то, требуется ли повторно визуализировать (то есть повторно «нарисовать») данный презентатор. В одном варианте изобретения возвращаемым значением является булево значение. Если оно равно «истина», то тогда требуется повторная визуализация. Если оно равно «ложь», то тогда повторная визуализация не требуется. После обработки на этапе 1304 каждого из «загрязненных» презентаторов для видимого изображения управление переходит к этапу 1306 визуализации, где обрабатываются презентаторы, идентифицированные в списке презентаторов, требующих повторной визуализации.

На этапе 1306 система 200 презентаторов вызывает метод 474 OnRender на каждом презентаторе, идентифицированном в списке презентаторов, запрашивающих повторную визуализацию. Функционирование примерного варианта метода 474 OnRender описано со ссылками на фиг. 14. При реализации базового класса метода 474 OnRender презентатор ничего не «рисует», а вместо этого итеративно вызывает метод 474 OnRender на своих дочерних и/или сцепленных презентаторах для заполнения выделенного пространства (например, прямоугольник). Настроенные с учетом требований пользователя версии метода 474 OnRender визуализируют побитовые отображения через вызовы приложения 204 и/или интерфейсов API графической подсистемы и драйверов 234 графических устройств. После обработки всех презентаторов, запрашивающих повторную визуализацию на этапе 1306, управление переходит к этапу 1308 «конец» и возвращается к вызывающей стороне, инициировавшей вызов 1102 метода DoLayout, на механизме представления для конкретного видимого изображения.

Обратимся к фиг. 14, где показана блок-схема этапов метода 470 OnUpdate, выполняемого для повторного вычисления презентатора видимого изображения. Метод 470 OnUpdate вычисляет новую компоновку для презентатора, в том числе для любых дочерних презентаторов, и кэширует результаты для обращения к ним на этапе повторной визуализации. В приведенном ниже примере с вызовом 470 метода OnUpdate для каждого презентатора пересылается набор размеров, задающих границы пространства для видимого изображения (например, прямоугольник), которое может быть занято компоновкой презентатора. Набор размеров задает, например, высоту и ширину, причем также устанавливается, можно ли модифицировать эти величины во время выполнения вызова метода 470 OnUpdate. Однако изобретение предполагает выполнение повторного вычисления презентаторов на основе любого одного или нескольких из множества различных полученных параметров, включая размеры пространства для видимого изображения, которые влияют на компоновку.

На этапе 1400 презентатор выполняет требуемые операции задания размеров на основе переданных параметров перед вызовом каких-либо дочерних презентаторов (через дочерние посреднические объекты) для выполнения их обновлений. Содержание указанной операции зависит от особенностей конкретного типа презентатора. Затем презентатор вызывает систему 200 презентаторов для определения местонахождения и обновления дочерних презентаторов текущего презентатора. На этапе предварительной обработки презентатор определяет потенциальную необходимость создания новой страницы/колонки и создает новый дочерний посредник/презентатор для обработки новой страницы/колонки для видимого изображения.

Далее на этапе 1402 метод 470 OnUpdate определяет на текущем родительском презентаторе следующий дочерний презентатор для вызова обновления его компоновки. Заметим, что на этом этапе, по меньшей мере в первом случае, требуется, чтобы родительский презентатор определил наличие дочернего элемента и создал соответствующий дочерний посреднический объект/презентатор. На последующих итерациях родительский презентатор может использовать кэшированные дочерние посреднические объекты, идентифицированные в его поле 412 дочерних презентаторов, для идентификации следующего оставшегося (не обработанного) дочернего посреднического объекта/презентатора, то есть дочернего презентатора, который еще не был вызван во время текущей итерации метода OnUpdate на текущем родительском презентаторе.

Родительский презентатор принимает ответ от поддерживающего запоминающего устройства либо сам определяет, исходя из своего свойства 412 дочерних презентаторов, остался ли дочерний презентатор, подлежащий обработке; при этом на этапе 1404, если не осталось дочерних презентаторов, подлежащих обновлению, управление переходит к этапу 1420 (описанному ниже). В противном случае, если презентатор действительно имеет в своем свойстве 412 дочерних презентаторов необработанный дочерний презентатор, который еще не был обновлен, то управление переходит к этапу 1406.

На этапе 1406 презентатор вызывает метод 520 OnUpdate на возвращенном дочернем посреднике, который находится между родительским презентатором и рассматриваемым текущим дочерним презентатором, для получения высоты и ширины дочернего презентатора, с которым связан дочерний посредник. Дочерний презентатор связан с конкретным графическим элементом (заданным в его поле 442 владельца элемента).

На этапе 1410 дочерний посредник вызывает метод 470 OnUpdate на дочернем презентаторе, с которым связан этот дочерний посредник. Метод 470 OnUpdate вычисляет обновленную высоту и ширину дочернего презентатора (и определяет, требуется ли повторная визуализация). Заметим, что на этапе 1410 метод 470 OnUpdate вызывается рекурсивно дочерними презентаторами, пока вызванный дочерний презентатор не определит на этапе 1402, что он не имеет дочерних презентаторов, и пока он не возвратится к вызывающему родительскому презентатору (через свой дочерний посредник). После вызова метода 470 OnUpdate на дочернем презентаторе управление переходит к этапу 1414.

Таким образом, на этапе 1414 вызывающий родительский презентатор (из этапа 1406) принимает ответ на вызов 520 метода OnUpdate для идентифицированного посредника. Ответ включает в себя высоту и ширину дочернего презентатора в виде возвращенных параметров. Ответ также указывает, требуется ли повторная визуализация вызванного дочернего презентатора. Далее на этапе 1416 родительский презентатор позиционирует вызванный дочерний презентатор в выделенном пространстве компоновки родительского презентатора на основе алгоритма/стратегии размещения. В одном варианте изобретения на этапе 1416 родительский презентатор помещает дочерний презентатор в свою компоновку на основе параметров высоты и ширины дочернего презентатора, полученных презентатором на этапе 1414.

Затем управление возвращается к этапу 1402, где продолжается выполнение метода 470 OnUpdate родительского презентатора для обновления остальных дочерних презентаторов (через их дочерние посреднические объекты-«оболочки»).

Если на этапе 1404 не осталось дочерних презентаторов (презентаторы элемента или посредника), подлежащих обработке/обновлению, то управление переходит к этапу 1420. На этапе 1420 метод 470 OnUpdate вызванного презентатора реализует настроенные согласно требованиям пользователя функции компоновки, включая возможные дополнительные вызовы метода 470 OnUpdate на дочерних презентаторах, для настройки компоновки для презентатора.

На этапе 1422 либо, что возможно, в любой момент, когда методом 470 OnUpdate получена новая информация, результаты обработки компоновки кэшируются для последующего использования на этапе повторной визуализации в процессе обработки графического изображения.

После завершения обработки обновления для данного презентатора, в том числе для всех дочерних презентаторов вызванного презентатора, на этапе 1424 презентатор возвращает свои размеры вызывающей стороне (система 200 презентаторов), а также значение, указывающее на то, необходима ли повторная визуализация этого презентатора.

Специалистам в данной области техники очевидно, что здесь на примерах были описаны новая платформа и методы для управления обработкой компоновки/представления выходных данных графического документного/пользовательского интерфейса в вычислительной среде, включающей в себя устройства графического вывода, такие как дисплей графического пользовательского интерфейса или принтер. С точки зрения множества возможных сред, в которых могут быть реализованы принципы этого изобретения, и гибкости проектирования и реализации программных утилит и инструментов следует отметить, что описанные здесь варианты являются лишь иллюстрацией, и их нельзя рассматривать как ограничение объема изобретения. Специалистам в данной области техники, которые используют настоящее изобретение, очевидно, что показанные здесь варианты могут быть модифицированы по структуре и в деталях, не выходя за рамки существа изобретения. Таким образом, описанное здесь изобретение рассматривает все указанные варианты как входящие в объем нижеизложенной формулы изобретения и ее эквивалентов.