Московский Государственный Университет им М.В.Ломоносова

Факультет Вычислительной Математики и Кибернетики

Кафедра Автоматизации Систем Вычислительных Комплексов

Лаборатория Вычислительных Комплексов

Курсовая работа

Студента 322 группы

Ручкина Ивана

«Исследование текстуальноконтекстного подхода к средам

разработки программ»

Научный руководитель Владимир Прус Москва 2009 Аннотация В данной работе исследуется текстуально-контекстный подход к созданию графического интерфейса пользователя для интегрированных сред разработки программ, основанный на максимизации занимаемой окном текстового редактора площади. Данный подход предполагает перенесение доступа функциональности инструментальных окон в окно текстового редактора. Исследование подхода включает обзор существующих интегрированных сред разработки программ, построения прототипа текстуально-контекстного интерфейса и частичной реализации постороженного прототипа.

Обзор сред разработки производится с точки зрения исследуемого подхода:

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

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

Далее в работе описана реализация навигации и показа ошибок сборки внутри окна текстового редактора на базе интегрированной среды разработки KDevelop 4.

Содержание Аннотация

Содержание

Введение

1.

Цель работы и постановка задачи

2.

2.1. Цель работы

2.2. Постановка задачи

Обзор существующих интегрированных сред разработки программ.............. 3.

3.1. Цели обзора

3.2. Предмет обзора

3.3. Среды разработки программ

3.3.1. Visual Studio 2008

3.3.2. Eclipse CDT 4.0

3.3.3. KDevelop 4

3.3.4. Code::Blocks 8

3.3.5. MonoDevelop 1.0

3.3.6. Anjuta 2.4.1

3.3.7. NetBeans 6.5.1

3.4. Выводы из обзора

Прототип интерфейса

4.

4.1. Окно древовидной навигации

4.1.1. Навигационный механизм breadcrumbs

4.1.2. Механизм переключения между документами

4.2. Окно результатов сборки

4.3. Окно заданий

4.4. Окно точек останова

4.5. Окна событий

4.6. Прототип интерфейса

Реализация

5.

5.1. Архитектура KDevelop

5.1.1. Уровень Sublime

5.1.2. Уровень Shell

5.2. Механизм навигации

5.2.1. Архитектура Model/View

5.2.2. Механизм навигации: уровень shell

5.2.3. Механизм навигации: уровень sublime

5.3. Показ ошибок сборки в тексте программы

5.3.1. Архитектура Kate

5.3.2. Механизм показа произвольных объектов в тексте

5.3.3. Показ ошибок в тексте

Заключение

6.

Список литературы

1. Введение Среды разработки программ (IDE – Integrated Development Environment) являются интеграцией текстового редактора, компилятора/интерпретатора, средств автоматической сборки и отладчика. При разработке IDE предполагается, что объединение перечисленных инструментов способствует повышению производительности работы программиста. Помимо того, интеграция делает возможным предоставление возможностей, недоступных без нее (например, автоматическое дополнение кода, установка точек останова отладчика в окне текстового редактора, отметка ошибок в тексте программы, проверка синтаксиса и пр.) Эмпирические данные1 показывают, что квалифицированные программисты (в особенности, Linux-программисты) предпочитают интегрированным средам разработки программ не интегрированные инструменты: текстовый редактор (наиболее популярны Vim, Kate, Notepad+, Emacs), компилятор (gcc), средства сборки (make) и отладчик (gdb). Основной причиной этого является перегруженность графического интерфейса сред разработки, неудобство его использования, сравнительная простота интерфейса отдельных текстовых редакторов.

Для получения более удобного для этих пользователей интерфейса, следует максимально приблизить интерфейс IDE к интерфейсу текстового редактора. Это означает максимизацию окна текстового редактора путм перенесения доступа к возможностям IDE в окно текстового редактора. Поскольку функциональность IDE на высоком уровне обеспечивается инструментальными окнами (дополнительными окнами, отличными от окна написания текста) [1], то инструментальные окна должны заменяться различными механизмами доступа к функциональности через окно текстового редактора. Например, такими механизмами являются контекстные меню, привязанные к объектам текста программы (например, переименование функции), внутритекстовые элементы (например, показ ошибок сборки внутри текста) и т.п. В дальнейшем будем называть такой подход к организации графического интерфейса и такой графический интерфейс текстуально-контекстным или просто текстуальным.

В частности, был проведен опрос среди сотрудников Лаборатории Вычислительных Комплексов. Данный опрос показал, что многие программисты для разработки программ используют не IDE, а наборы отдельных инструментов разработки.

2. Цель работы и постановка задачи Данный раздел описывает цель данной работы и решаемую в работе задачу.

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

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

Далее, требуется разработать прототип текстуально-контекстного интерфейса.

Требуется рассмотреть каждое инструментальное окно с целью представить его функциональность внутри окна текстового редактора.

Подзадачи:

Разработка «легкого» механизма навигации между документами, не требующего отдельного окна «менеджера проектов».

Разработка механизма показа произвольных объектов внутри текста программы, раздвигающего текст программы, организация показа ошибок компиляции с помощью этого механизма.

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

И, наконец, требуется практическая реализация:

Механизма навигации.

Механизма показа произвольных визуальных элементов в тексте программы.

Показа ошибок компиляции в тексте программы.

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

Поддерживают написание кода для компилируемых объектноориентированных языков (а именно C++, C#, Java).

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

3.1. Цели обзора Целью данного обзора является рассмотрение возможностей применения текстуально-контекстного подхода к существующим IDE. Как было сказано, суть подхода – перенесение доступа функциональности инструментальных окон в окно текстового редактора. Поэтому цель данного обзора – определение списка возможных инструментальных окон, исследование возможностей перенесения их функций в текст и неформальная оценка удобства такого перенесения.

3.2. Предмет обзора Нас будут интересовать следующие особенности пользовательского интерфейса представленных ниже интегрированных сред разработки программ:

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

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

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

Поскольку точные оценки удобства (usability) [2] графического интерфейса возможны только после usability-тестирования [3], проведение которого выходит за рамки данной работы, далее будем принимать некоторые гипотезы об основных сценариях использования инструментальных окон, основываясь на контексте их использования и предполагаемом назначении.

Опишем для нескольких IDE подробно представленные инструментальные окна и их организацию, а в дальнейшем ради уменьшения объема изложения будем ссылаться на рассмотренные ранее среды разработки.

3.3. Среды разработки программ 3.3.1. Visual Studio Visual Studio – коммерческая серия сред разработки компании Microsoft для семейства ОС Windows. Рассматриваемый релиз поддерживает разработку на платформе.NET на Visual Basic, Visual C++, Visual C#, Java. [4] Организация инструментальных окон.

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

Инструментальные окна могут находиться в одном из 3 режимов: «дрейфующий»

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

Окно текстового редактора может быть разделено (горизонтально или вертикально) на несколько окон с документами, выбираемыми по вкладкам.

Инструментальные окна и перенос их функциональности.

Solution explorer. Окно древовидной навигации по группам проектов и связанных с проектами файлов. Основная функция данного окна – выбор документа для редактирования, операции над файлами проектов (переименование, создание новых, перенос и др.). Например, в emacs навигация по документам осуществляется через строку состояния, в которой отображается имя текущего файла и через которую можно сменить текущий файл.

Server explorer. Окно отображения сведений об операционной системе:

история событий, информация о файловой системе, устройства, системные службы, счетчики производительности и т.п. Использование заключается в собственно просмотре информации. Перенос функциональности не представляется возможным.

Bookmarks. Окно списка закладок, размещенных в текстовых документах.

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

Class View. Окно, содержащее дерево вложения и наследования классов текущего проекта, глобальные функции и переменные, макросы и константы. Основная функция данного окна – отображение структуры классов, произведение навигации по классам. Отображение структуры классов и навигация по ним могут быть реализованы навигационной полоской.

Code Definition Window. Окно, отображающее часть кода, содержащую класса/переменной/функции). Функциональность данного окна (показ кода и возможность его модификации) может быть заменена всплывающей подсказкой при наведении курсора мыши на имя в коде.

Object Browser. Окно, древовидно отображающее доступные для использования в проекте имена (классы, функции и т.д.) и их описание.

Object Browser содержит довольно большой список системных компонент (при настройке на вывод имен только данного проекта информация совпадает с выводимой окном Class View), поэтому его функциональность не может быть перенесена в код.

Error list. Отображает список ошибок, предупреждений и сообщений сборки проекта или проектов. Возможен переход по каждому сообщению в строку кода, вызвавшую его. Основное использование окна – просмотр ошибок и их последовательное исправление, поэтому данное окно можно частично заменить механизмом показа ошибок в тексте программы (но в таком случае невозможно отображение полного списка ошибок в одном месте).

Task List. Отображение одного из двух списков заданий: заданий, добавленных пользователем, и заданий, отмеченных в коде (комментарий, начатый словом TODO). Использование заключается в добавлении новых заданий и навигации по существующим заданиям. Работа с заданиями из кода может быть перенесена в текстовое окно: добавление и навигация (следующий/предыдущий) могут выполняться через контекстное меню.

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

3.3.2. Eclipse CDT 4. Eclipse – кроссплатформенная интегрированная среда разработки с открытым исходным кодом, разрабатываемая Eclipse Foundation. Поддерживает разработку на С/С++ и Java. [5] Организация инструментальных окон.

Инструментальные окна организованы почти так же, как и в Visual Studio. Отличия:

Возможно развертывание инструментальных окон одной позиции на вc окно Eclipse (со скрытием окна текстового редактора).

Отсутствует режим вкладки инструментальных окон (невозможно открытие инструментального окна в одной из вкладок текстового редактора).

Окна, находящиеся в режиме ускоренного скрытия, открываются не наведением мышки, а кликом мыши.

Невозможно создание нескольких окон текстового редактора в рамках одного окна Eclipse.

Инструментальные окна и перенос их функциональности.

Navigator (C/C++ Projects). Древовидная навигация по всем проектам (только по С/С++). Имеет функции, аналогичные окну навигации по проектам Visual Studio (также для каждого файла показывает его структурные элементы: макросы, методы и т.п.), поэтому допускает замену, например, через строку состояния или другими способами (см. главу 4).

Include Browser. Отображает дерево включения заголовочных файлов.

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

Make Targets. Показывает дерево проектов, и для каждой цели make отображает элемент в соответствующем каталоге. Отображение целей make может быть осуществлено с помощью навигации по проектам (добавление целей-элементов в соответствующие каталоги).

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

Problems. Отображение списка ошибок и предупреждений сборки проекта.

Функционирует так же, как и соответствующее окно Visual Studio, поэтому допускает замену на показ сообщений внутри текста.

Properties. Функционирует аналогично одноименному окну Visual Studio.

Перенесение функциональности на текстовый механизм невозможно.

Tasks. Отличается от окна задач Visual Studio только тем, что оба типа задач (добавленные пользователем через это окно и взятые из кода) отображаются в едином списке. Возможно частичное перенесение функциональности в текст – последовательная навигация по задачам кода.

Breakpoints. Инструментальное окно, содержащее список точек останова и их условий. Основная функция – обзор точек останова и навигация по ним.

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

3.3.3. KDevelop KDevelop – платформо-независимая свободная IDE для unix-систем, написанная на С++ с помощью библиотеки Qt. Является частью графического окружения KDE, но может быть запущен для других графических окружений. Поддерживает программирование на многих языках, в том числе С/С++, Java, Ruby, Python. [6] Организация инструментальных окон.

Инструментальные окна реализованы в KDevelop менее гибко, чем в Visual Studio и Eclipse. Возможен только один режим окон, при котором они сгруппированы в одной из четырех позиций (сверху, снизу, слева, справа от окна текстового редактора). Для каждой позиции допускается отображение нуля (позиция скрыта, е место занято текстовым редактором) или одного инструментального окна.

Для позиций можно настроить, какая из них будет занимать углы окна KDevelop.

Окно текстового редактора может разбиваться пополам по горизонтали или вертикали. Полученные окна также могут разбиваться.

Инструментальные окна и перенос их функциональности.

Breakpoints. Функционирует аналогично одноименному окну в eclipse, функциональность так же переносится в текст.

Code Browser. Выполняет ту же функцию, что и Code Definition Window – показ свойств объекта кода, на котором находится курсор. Данная функция уже перенесена в текст программы в KDevelop – по наведению курсора мыши на имя в коде появляется всплывающая подсказка, содержащая свойства имени и его определение.

Filesystem, Projects, Documents. Окна, предоставляющие пользователю возможность навигации по файловой системе, проектам и документам.

Возможность замены таких окон уже установлена в обзоре Visual Studio и Messages. Отображение списка ошибок и предупреждений, полученных в результате сборки, с указанием файла, в котором возникла ошибка, линии ошибки и описания. Переместить данное отображение в код возможно при помощи показа ошибок в коде.

Problems. Окно, аналогичное Build, но показывает ошибки, полученные в результате фонового разбора кода. Заменяется аналогично.

3.3.4. Code::Blocks Code::Blocks – кроссплатформенная и свободная интегрированная среда разработки. Написана на С++ с использованием библиотеки wxWidgets.

Поддерживает разработку на С/С++. [7] Организация инструментальных окон.

Существует всего 4 основных инструментальных окна: Management, Logs & others, Open files list, To-Do list (первые два имеют несколько вкладок). Существует два режима инструментальных окон (совпадают с аналогичными из Visual Studio):

дрейфующий (окно находится «поверх» окна Code::Blocks) и стыкующийся. В стыкующемся режиме инструментальное окно может находиться в одной из позиций: сверху, снизу, справа и слева от текстового редактора. Для окон, размещенных в одной позиции, она делится на части настраиваемого размера.

Окно текстового редактора может быть разбито на два (горизонтально или вертикально), но в его частях отображается всегда текст одного и того же файла.

Наборы настроек расположений окон можно сохранять и загружать (аналогично перспективам Eclipse). Этим ограничиваются возможности организации инструментальных окон.

Инструментальные окна и перенос их функциональности.

Management – Projects, Management – Symbols. Эти вкладки окна Management служат для навигации по проектам и объектам кода (функции, типы, глобальные переменные, макрозамены). Функционируют и заменяются аналогично, например, окнам Navigator и Outline из IDE Eclipse.

Logs & others – Code::Blocks. Содержит лог событий среды (создание/открытие проектов/файлов, загрузка подгружаемых модулей и др.). Возможна замена данного инструментального окна с помощью, например, всплывающих сообщений или строки состояний.

Logs & others – Build messages. Отображение сообщений о процессе сборки.

Полностью аналогично соответствующим окнам из рассмотренных ранее IDE (например, Problems из KDevelop).

Open files list. Это инструментальное окно отображает список файлов, открытых в данный момент в Code::Blocks. Основной сценарий использования: переход к какому-либо открытому файлу или оперирование через контекстное меню. Упрощение доступа и навигации по открытым файлам может быть добавлено к уже упоминавшемуся механизму навигации breadcrumbs так: при вызове навигационного окна открытые файлы более видимы и доступны, нежели другие [8].

To-Do list. Окно, показывающее список задач, полученных из комментариев в файлах. Функциональность ограниченно переносится в текст, как и для аналогичных окон Visual Studio и Eclipse.

3.3.5. MonoDevelop 1. MonoDevelop – среда разработки с открытым исходным кодом, предназначенная для написания приложений на С/С++, С#, Java, Visual Basic.NET и других языках.

Является частью проекта Mono по созданию свободной реализации платформы.NET. [9] Организация инструментальных окон.

Инструментальные окна организованы в MonoDevelop почти так же, как и в Visual Studio. Отличия:

Невозможно разбиение окна текстового редактора на несколько.

Есть возможность работы с настройками расположения окон (аналогично перспективами Eclipse).

Инструментальные окна и перенос их функциональности.

Solution, Files, Classes. Окна, служащие для отображения структуры и навигации.

Функционируют и переносятся в текст аналогично соответствующим окнам рассмотренных ранее IDE.

Errors list. Аналогично окнам результатов сборки рассмотренных ранее IDE.

Task list. Функции данного окна полностью совпадают с функциями окна Task list изVisual Studio. Аналогичная частичная замена функциональности.

Properties. Окно содержит список свойств текущего редактируемого файла.

Работа с этим окном заключается в просмотре и, возможно, редактировании свойств файла. Перенос такой функциональности в текстовое окно невозможен.

3.3.6. Anjuta 2.4. Anjuta – свободная IDE для графической оболочки GNOME, написанная на С++ с помощью библиотеки GTK. Поддерживает разработку на С/С++. [10] Организация инструментальных окон.

Инструментальные окна в Anjuta организованы практически так же, как и в Visual Studio. Список отличий:

Отсутствует режим автоматического скрытия инструментальных окон:

скрытие и открытие происходят всегда по клику мыши.

Каждая из частей позиции (в смысле Visual Studio) может быть также разделена на несколько частей – и так до бесконечности.

Инструментальное окно может быть фиксировано на текущей позиции – отключены возможности его переноса или скрытия.

Инструментальные окна и перенос их функциональности.

Files. Окно навигации по файловой системе. Заменяется навигацией через строку состояния (см. выше).

Symbols. Навигация и поиск по объектам кода. Навигация может быть заменена с помощью breadcrumbs, поиск не может быть заменен.

Help, Help display. Первое окно отображает древовидную структуру доступных руководств, результаты поиска по данным руководствам. Второе окно содержит текст указанных руководств. Данная функциональность не может быть перенесена в текст.

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

Отображение структуры не может быть перенесено в текст.

Breakpoints. Показ точек останова отладчика. Функциональность частично переносится в текст (см. окно Breakpoints для Eclipse).

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

Messages. Окно сообщений сборки. Аналогично окнам сообщений сборки для IDE, описанных ранее.

Tasks. Окно заданий, аналогичное окну заданий из Eclipse.

Функциональность заменяется аналогично.

3.3.7. NetBeans 6.5. NetBeans – свободная IDE для разработки на Java, C++, Ruby и некоторых других языках, поддерживающая платформы J2EE и J2SE. Написана на Java.

Разрабатывается NetBeans Community. [11] Организация инструментальных окон.

Отличия от организации инструментальных окон в Visual Studio:

Возможность разворачивания на весь экран одного из инструментальных окон (как в Eclipse).

Возможность сделать автоматически скрываемые окна полупрозрачными (при клике мышкой в любой точке полупрозрачность исчезает).

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

Невозможно создание нескольких окон текстового редактора в рамках одного окна NetBeans.

Инструментальные окна и перенос их функциональности.

Projects, Files, Favorites, Navigator, Hierarchy, Classes. Окна навигации по различным сущностями. Возможна замена навигацией через строку состояния (см. Visual Studio).

Services. Древовидное отображение сервисов баз данных и веб-сервисов.

Не осуществимо перенесение в текст.

Tasks. Список задач из комментариев в коде. Замена аналогично рассмотренным ранее окнам управления задачами.

Properties. Отображение свойств редактируемого файла или объекта, выбранного в другом инструментальном окне. Не представляется возможным произвести замену.

Отладка: Local variables, threads, sessions, call graph. Окна, предназначенные для отображения информации об отладке, не имеющей конкретной привязки к тексту программы, или же отображающие общую структуру, и поэтому не подлежащие перенесению в окно текстового редактора.

Breakpoints. Аналогично одноименному окну из KDevelop.

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

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

Были рассмотрены инструментальные окна выбранных IDE и возможность перенесения функциональности этих окон в окно текстового редактора. Из тех окон, для которых существует какой-либо способ замены текстуальным механизмом и которые были встречены в большинстве сред разработки, могут быть выделены обобщенные по функциям типы окон. Так, например, Solution Explorer (Visual Studio), Navigator (Eclipse) и Projects (KDevelop) образуют тип окон древовидной навигации, поскольку служат отображению структуры существующих документов (файлов, проектов) в виде дерева.

Полученные типы окон:

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

Окно результатов сборки. Позволяет обозревать результаты сборки, переходить к строкам, вызвавшим ошибки/предупреждения.

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

Окно точек останова. Показывает список точек останова и их условий, позволяет переходить по точкам останова к местам установки в коде.

Было показано, что в рассмотренных средах разработки встречаются элементы исследуемого текстуально-контекстного подхода, но он не реализуется полностью в рамках какой-либо IDE.

4. Прототип интерфейса Данный раздел содержит построение независимого от IDE прототипа (теоретической модели) [3] текстуально-контекстного интерфейса. Построение прототипа основывается на полученных в результате обзора обобщенных типах окон, для которых возможно перенесение функциональности в текст программы.

Также в данном разделе обосновываются решения по построению прототипа интерфейса.

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

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

4.1. Окно древовидной навигации Будем для определенности рассматривать окно навигации по проектам, поскольку, во-первых, оно встречается во всех рассмотренных IDE, и, во-вторых, навигация по другим сущностям (файлы, документы, классы, части документа) не отличается в отношении использования и текстуальной замены.

Окно навигации по проектам отображает дерево проектов, содержащихся в них каталогов, файлов и, возможно, других сущностей (например, цели make).

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

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

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

Строка состояния, отображающая имя текущего редактируемого файла.

Через строку запускается диалог выбора нового файла.

Механизм навигации breadcrumbs, который мы далее рассмотрим подробнее.

Выбор из возможностей замены навигации с сохранением осуществимости основного сценария использования напрямую крайне узок. Как уже указывалось в обзоре, в данном случае применим механизм навигации breadcrumbs [12].

Рассмотрим его подробнее.

Навигационный механизм breadcrumbs 4.1.1.

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

Преимущества данного навигационного механизма по сравнению с древовидной навигацией:

Отображение текущего редактируемого документа.

Соответствие принципу локальности [3, 12]: пользователь чаще хочет переходить к объектам, менее удаленным от текущего местоположения.

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

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

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

Механизм переключения между документами 4.1.2.

Итак, для замены древовидной навигации выше было обосновано решение выбора навигации breadcrumbs. Построим подробный прототип механизма переключения.

Расположение: сверху текстового окна отображается навигационная горизонтальная полоска, документу, открытому в окне текстового редактора в данный момент.

Откуда отображать путь:

Из корневого каталога файловой системы.

Из папки проекта. Выберем данный вариант для файлов, принадлежащих проекту, поскольку это делает полоску короче и меньше отвлекает пользователя [8, 12, 13].

Последний уровень иерархии:

Текущий открытый документ.

Текущий открытый класс (если есть). Выберем данный вариант, поскольку это позволяет частично заменить функциональность окон отображения классов (Classes в Anjuta), окон навигации по структуре документа (Outline в Eclipse).

Навигационная полоска состоит из горизонтально выстроенных кнопок. Первая кнопка механизма навигации соответствует проекту открытого документа или корневому каталогу. Каждой промежуточной директории в пути также соответствует одна кнопка навигации. Последняя кнопка соответствует текущему просматриваемому классу или документу.

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

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

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

Всплывающий список файлов следует сортировать [3, 8, 12, 13]. Возможны следующие критерии сортировки:

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

2. Дата последнего действия через контекстное меню. Возможна сортировка по дате последнего действия через контекстное меню (удаление, переименование, в том числе и открытие). Но действия через контекстное меню осуществляются реже чем открытие файла, поскольку, как говорилось ранее, основная функциональность окна навигации (как и заменяющего механизма) – открытие и переключение между файлами.

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

4. Дата последнего активации файла. Здесь под активацией понимается открытие файла или переключение на уже открытый файл.

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

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

Рисунок 1. Пример прототипа навигации breadcrumbs На рисунке 1 показан пример элементов навигационной полоски и соответствующие элементам «проект» и «файл0» всплывающие окна.

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

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

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

Сначала исследуем возможности показа ошибок в тексте программы:

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

Вставка текста ошибки после строки, вызвавшей его.

Первый из этих вариантов уже был реализован в некоторых IDE (например, в Eclipse красным подчеркиваются строки с ошибкой, желтым – строки с предупреждением). Данный вариант, при использовании без окна результатов сборки, предлагает пользователю проделывать после каждой сборки очевидный шаг – наведение курсора мыши на текст, вызвавший ошибку, - и поэтому уступает второму варианту [8, 14].

Далее рассматривая показ ошибок в тексте, имеем две возможности:

Отображение текста всех ошибок.

Отображение текста первой ошибки.

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

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

Замена функций окна сборки при работе с предупреждениями осуществляется несколько иначе, поскольку исправление предупреждений носит необязательный характер, но и необходимо отображать их все сразу. Будем отмечать строки с предупреждениями маркером слева от строки. При наведении курсора на маркер во всплывающем окне будет текст предупреждения, а также будет возможность доступа к списку всех предупреждений. Так будет текстуально заменена работа с предупреждениями через окно результатов сборки.

Наконец, необходимо отображать информацию о числе ошибок и предупреждений. Данная информация должна быть постоянно видима для пользователя, как если бы использовалось окно результатов сборки. С другой стороны, информация имеет достаточно небольшой объем и относится к проекту или нескольким проектам. Для отображения такого типа информации будем использовать в дальнейшем строку состояния – горизонтальную полоску под окном текстового редактора, которая имеет несколько информационных полей. По мере формирования прототипа интерфейса будем уточнять содержимое строки состояния. На данном этапе поместим в нее надпись «Число ошибок: n. Число предупреждений: m.», обновляемую при каждой сборке.

4.3. Окно заданий Все IDE, рассмотренные в обзоре, имеют окно для управления задачами. В большинстве IDE это окно так или иначе предоставляет управление над двумя типами задач: добавленные пользователем через это окно (и отображаемые только в нем) и задачи, взятые из комментариев к коду, начинающиеся со слова TODO. Перенос работы с задачами первого типа в текст трудноосуществим (поскольку тогда надо полностью отображать их список, что равноценно отображению окна заданий), поэтому далее будем говорить только о задачахкомментариях.

Функции, предоставляемые этим окном, - это, во-первых, обзор всех задач в некоторой области и, во-вторых, переход к строке, содержащей некоторое задание.

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

Заменив таким образом окно задач, мы уменьшим необходимость отображения окна задач, потому что оно будет вызываться пользователем, когда ему необходимо постоянно видеть список задач.

4.4. Окно точек останова Большинство сред разработки из обзора имеют окно, отображающее список точек останова отладчика, их расположение и условия.

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

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

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

4.5. Окна событий Здесь приведем краткие соображения по применению текстуально-контекстного подхода к окнам, отображающим лог событий, которые не были полноценно представлены в обзоре (исследование этих окон выходит за рамки работы). Как правило, окна событий не имеют интерактивной структуры, содержат последовательность текстовых записей. Такие окна могут включать:

События среды. Содержит записи о подгружаемых модулях, сменах настройки интерфейса, открытии файлов и т.п. Пример – окно Code::Blocks из одноименной IDE.

Прогресс сборки. Данное окно присутствует во многих IDE, но в большинстве случаев является выводом средства make или подобного, поэтому не было затронуто в обзоре.

Окна контроля версий. Примеры: CVS, Git, SVN, Mercurial.

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

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

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

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

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

4.6. Прототип интерфейса Итак, в данной главе мы получили прототип интерфейса, в котором обобщенные окна, список которых был получен в обзоре IDE, были заменены текстуальными способами доступа к аналогичной функциональности. Данный интерфейс включает в себя:

Навигационный механизм breadcrumbs.

Отображение результатов сборки и точек останова в тексте.

Расширенная работа с точками останова.

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

Механизм показа сообщений вверху окна текстового редактора. Возможен переход к инструментальному окну, соответствующему сообщению.

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

5. Реализация Реализация производится на базе KDevelop 4. KDevelop 4 является частью среды KDE, которая реализована на языке программирования С++ с помощью библиотеки Qt [15].

5.1. Архитектура KDevelop Архитектура KDevelop состоит из 3 уровней [16]:

1. Sublime. Предоставляет минимальные средства построения интерфейса IDE, такие как инструментальные окна и окно редактирования.

2. Shell. Управляет подключаемыми модулями, документами, проектами, интерфейсом, отладкой.

3. KDevelop. Содержит подключаемые модули, поддерживающие средства сборки, управление версиями, отладку и т.д.

Опишем подробнее первые два уровня, т.к. их будет затрагивать реализация.

5.1.1.

На рисунке 2 показаны части графического интерфейса уровня Sublime и классы, реализующие эти части интерфейса. Далее следует текстовое описание основных классов.

Рисунок 2. Структура интерфейса Sublime Sublime::MainWindow – основное окно интерфейса Sublime.

Внутренняя логика реализуется классом Sublime::MainWindowPrivate.

Sublime::Area – область, содержащая инструментальные окна и окно текстового редактора. Допускается несколько областей и их переключение, но в каждый момент времени в главном окне отображается только одна. Область управляет расположением окон Sublime::View – класс, определяющий некоторое окно в Sublime::Area.

Инструментальные окна реализуются классом Sublime::ToolView, а текстовое – KateView. При отображении окна его View ставится в произвольный графический элемент в Qt) [15].

Sublime::Document – класс документа Sublime. Каждому документу может соответствовать несколько View, предназначенных для его Sublime::Container – графический элемент, отображающий KateView документов (текстовый редактор) с возможностью переключения Sublime::Controller – центральная часть модуля sublime. Содержит области, документы и управляет окнами.

5.1.2.

Структура модуля Shell проще структуры модуля Sublime: основой модуля Shell является класс Shell::Core, содержащий различные контроллеры и управляющий ими.

Shell::Core – ядро KDevelop. Служит для доступа и управления различными контроллерами, хранит информацию о них.

Shell:: DocumentController реализует контроллер документов, который управляет всеми документами, содержит информацию о них, испускает сигналы об открытии/закрытии.

Shell::UiController – контроллер интерфейса. Отвечает за создание интерфейса KDevelop и обработку его изменений.

Shell::RunController – контроллер задач. Управляет запуском отладки, запуском скомпилированных программ и т.д.

Shell::PluginController Управляет загрузкой и работой этих модулей.

Shell::SessionController – контроллер сессий, служащий для управления запущенными процессами.

Shell::LanguageController – управление языками кода пользователя.

Также осуществляет проверку кода в фоновом режиме.

Shell::MainWindow описывает главное окно интерфейса KDevelop.

Содержит Sublime::MainWindow в качестве члена класса.

Shell::OpenProjectDialog, Shell::SaveDialog – диалоги открытия 5.2. Механизм навигации В этой части описывает реализация механизма навигации, модель которого была описана в части 4 данной работы. Реализация данного механизма основана на архитектуре Model/View, поэтому детальному описанию этой реализации предшествует краткий обзор архитектуры Model/View 5.2.1.

Архитектура Model/View [17] – шаблон объектно-ориентированной архитектуры в разработке программного обеспечения, заключающийся в разделении данных приложения и его интерфейса с пользователем. Достоинства архитектуры Model/View:

Изоляция данных и их представления Независимость модификации данных и их представления.

Достоинства данной архитектуры применимы к решаемой задаче благодаря тому, что отображение средства навигации для каждого открытого документа должно производиться на уровне sublime, на котором ничего не известно о типе и структуре открытого документа. А информация о типе и структуре документа доступна лишь на уровне shell.

Использование Model/View архитектуры упрощается тем, что в Qt есть поддержка реализации приложений с такой архитектурой.[ссылка] В Qt модель – произвольное дерево элементов, где у каждого элемента есть несколько колонок, содержащих различную информацию. Корень модельного дерева не содержит информации. Потомки корня называются элементами верхнего уровня. Также есть ряд View-классов, отображающих модели (например в виде таблицы, списка, дерева). Далее под словом модель будем понимать Model-класс Qt.

Итак, реализуем view-часть средства навигации (показ навигационной полоски для некоторой заданной модели) на уровне sublime, а model-часть (построение модели навигации) – на уровне shell.

Механизм навигации: уровень shell 5.2.2.

Как сказано ранее, на уровне shell необходимо построить модель навигации для е передачи уровню sublime. Для каждого открытого документа строится модель навигации.

Структура модели. Опишем структуру модели на примере. Пусть мы имеем проект Project0, в нм файлы part0.h и part0.cpp находятся в подпапке src0, а part1.h, part1.cpp – в src1. Пусть во вкладках редактора открыты файлы part0.cpp и part1.cpp. На рисунке 3 показана описанная структура каталогов. На рисунке изображена навигационная модель для документа.

Рисунок 3. Структура каталогов Project Рисунок 4. Пример навигационной модели для part0.cpp Верхний уровень навигационной модели состоит из элементов, соответствующих частям пути (каталогам) до открытого документа. Рассмотрим некоторый элемент верхнего уровня, отличный от последнего (он соответствует документу). Его потомками являются два элемента: «Open files» и «Other files». Потомки первого – файлы из каталога, определяемого элементом верхнего уровня, открытые в KDevelop. Потомки второго – остальные файлы, каталоги.

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

Shell::HeaderModel. Принимает на вход одну модель и одну строку.

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

Схема работы HeaderModel показана на рисунке 5.

Рисунок 5. HeaderModel Shell::CombinedModel. Принимает на вход список моделей. Выходная модель состоит из соединения по верхнему уровню моделей-аргументов в одну. Схема работы CombinedModel показана на рисунке 6.

Рисунок 6. CombinedModel Shell::FileFilterModel, получая на вход модель, приводимую к модели файлов ФС (в Qt реализуется классом QDirModel), и некоторый путь, показывает на верхнем уровне лишь файлы, лежащие по полученному пути и находящиеся в списке открытых файлов KDevelop. Возможна параметризация класса для показа файлов, не находящихся в списке открытых файлов KDevelop. Схема работы FileFilterModel показана на Рисунок 7. Пример использования FileFilterModel Также как вспомогательная используется описанная в Qt модель ФС QDirModel.

Построение модели. Определяется путь до документа. Для каждого элемента пути строится его модель: модель файловой системы служит фундаментом для двух различно параметризованных FileFilterModel, каждая из которых подается на вход HeaderModel (со строками «Open files» и «Other files» соответственно), после чего две HeaderModel объединяются с помощью CombinedModel, к которой добавляется заголовок (с помощью HeaderModel). Так, после построения модели для каждого элемента пути эти модели объединяются в одну (FileFilterModel).

Полученная модель и является моделью навигации, которая передается на уровень sublime.

Механизм навигации: уровень sublime 5.2.3.

Навигационная полоска. Графическим отображением навигационного механизма является полоска, состоящая из кнопок со стрелками, находящаяся между окном текстового редактора и вкладками документов. Полоска создается классом Sublime::Container при создании новой вкладки для документа.

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

Классы навигации на уровне Sublime.

Sublime::GenericNavigatorButton – навигационная кнопка. Наследует QPushButton. Отличается от последней прорисовкой: рисуется не просто текст, а текст со стрелкой вправо.

Sublime::ExtendedDialogViewDelegate – класс, предназначенный для прорисовки элементов «открытые файлы» и «другие файлы».

Sublime::ExtendedDialog – диалог, появляющийся при нажатии на одну из навигационных кнопок. Использует ExtendedDialogViewDelegate.

Sublime::GenericNavigator – собственно класс навигатора. Наследует QWidget. Для использования навигатора достаточно вставить этот визуальный элемент в интерфейс и предоставить ему модель навигации.

Реализованный механизм навигации изображен на рисунке 8.

. Рисунок 8. KDevelop с реализованным навигационным механизмом 5.3. Показ ошибок сборки в тексте программы Ниже будет описана реализация механизма показа произвольных визуальных объектов между строк текстового редактора Kate и применение этого механизма для показа текста ошибок в тексте программы.

5.3.1.

Kate – текстовый редактор среды KDE [18]. Окно редактирования текста Kate может быть использовано в другом приложении при помощи технологии KParts [19], так что возможна модификация кода окна редактирования Kate для показа ошибок сборки.

Отображение окна текстового редактора осуществляется классом KateView, использующего для реализации внутренней логики KateViewInternal. Для представления отображаемого документа используются классы KateLineLayout, KateTextLayout, созданием, хранением и обновлением которых управляет класс KateLayoutCache. KateRenderer отвечает за отрисовку текста на низком уровне (может «нарисовать» строку текста в указанной позиции окна). Подробное описание классов:

KateView. Реализует окно текстового редактора (вместе с прокруткой скроллингом). Реализует интерфейс KTextEditor::View, необходимый для окон текстовых редакторов KDE. Одному KateView соответствует только один KTextEditor::Document (интерфейс документа), отображаемый в нем.

Обращается к KateViewInternal для реализации редактирования текста.

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

KateLineLayout. Класс одной строки текста в редактируемом документе, то есть при разделении текста на строки символами конца строки.

KateTextLayout. Класс одной строки текста, отображаемой на экране. Один KateLineLayout разбивается на 1 и более KateTextLayout.

KateLayoutCache. Управляет разделением редактируемого документа на KateLineLayout и KateTextLayout и хранением этих классов. Осуществляет обновление строк при изменении в отображении (по требованию KateViewInternal).

KateRenderer. Выполняет работу по отображению текста.

5.3.2. Механизм показа произвольных объектов в тексте Ниже описывается механизм, позволяющий показать один объект (визуальный элемент) между строками текста в окне текстового редактора kate. На более детальном уровне визуальный элемент реализуется классом-наследником QWidget.

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

Этот QWidget отображается после строки, номер которой был передан, и занимает место в окне текстового редактора до следующей строки текста. Также при отображении вносятся изменения в код, реализующий операции над текстом (передвижение курсора, скроллирование), вносятся изменения в обращения KateViewInternal к KateRenderer и KateLayoutCache. Обработка взаимодействия с пользователем осуществляется уже самим переданным визуальным элементом (предполагается, что это будет класс-наследник QWidget, в котором реализована соответствующая логика). Также TextMessageInterface описывает функцию прекращения отображения Через созданный интерфейс из уровня sublime, описанного выше, можно передавать произвольный визуальный элемент. Схема передачи произвольного визуального элемента показана на рисунке 9.

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

Рисунок 9. Схема передачи произвольного объекта для показа в тексте 5.3.3.

Для реализации показа ошибок необходимо передать список ошибок от модуля KDevelop MakeBuilder (расположен на третьем уровне KDevelop – см. Архитектура KDevelop) на уровень Sublime, а затем, создав визуальный элемент с текстом ошибки, передать его и номер строки, в которой возникла ошибка, классу KateView через описанный выше интерфейс TextMessageInterface. Дальнейшие решения по организации взаимодействия KDevelop и Kate во многом определены структурой этих приложений, не предназначенной для такой передачи информации:

предполагается, что текстовое окно Kate вложено в KDevelop и, по замыслу разработчиков, не должно принимать информацию о внутренних структурах KDevelop [20], которой и является список ошибок сборки проекта.

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

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

ProblemReporterPlugin, реализуя указанный интерфейс, при получении первой ошибки создает визуальный элемент с текстом ошибки и, получая информацию о строке ошибки, передает визуальный элемент и номер строки KateView через интерфейс TextMessageInterface. На рисунке 10 показана описанная схема работы механизма показа ошибок с помощью ProblemReporterPlugin.

Наконец, в данной работе был создан класс TextErrorWidget – наследник QWidget, реализующий визуальный элемент с текстом ошибки и кнопками навигации «Следующая ошибка»/«Предыдущая ошибка». Переключением отображаемой ошибки также управляет ProblemReporterPlugin: по запросу, например, следующей ошибки он создает объект класса TextErrorWidget и передает его KateView.

Рисунок 10. Поток данных при показе ошибок в тексте программы 6. Заключение В данной работе был проведен обзор существующих интегрированных средств разработки программ, сделаны выводы из этого обзора.

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

Итак, проделанная работа соответствует поставленной задаче и полностью решает ее.

Дальнейшее развитие данной работы заключается в следующем:

Доработка модели интерфейса.

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

Реализация оставшихся пунктов модели.

Разработка критериев оценки графических интерфейсов IDE.

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

7. Список литературы 1. Rex Bryan Kline, Ahmed Seffah Evaluation of integrated software development environments: challenges and results from three empirical studies // J.

International Journal of Human-Computer Studies. 2005. 63. P. 607-627.

2. Donald A. Norman The Design of Everyday Things. Doubleday, 1989, 261 p.

3. Jakob Nielsen Usability Engineering. Academic Press, 1993, 352 p.

4. Microsoft Visual Studio Website [HTML] (http://www.microsoft.com/visualstudio/en-us/default.mspx) 5. Eclipse Foundation Eclipse Website [HTML] (http://www.eclipse.org/) 6. KDevelop team веб-сайт KDevelop [HTML] (http://www.kdevelop.org/) 7. Code::Blocks Website [HTML] (http://www.codeblocks.org/) 8. Morgan Kauffman GUI Bloopers 2.0 Common User Interface Design Don’ts and Dos. Morgan Kauffman Publishers, 2007, 433 p.

9. Mono Project MonoDevelop Website [HTML] (http://monodevelop.com/) 10. Anjuta Website [HTML] (http://projects.gnome.org/anjuta/index.shtml) 11. NetBeans Community NetBeans Official Website [HTML] (http://www.netbeans.org/) 12. Steve Krug Don’t Make Me Think A Common Sense Approach to Web Usability.

Indianapolis: New Riders, 2000, 195 p.

13. Jensen Harris, An Office User Interface Blog [HTML] (http://blogs.msdn.com/jensenh/).

14. Alan Cooper Inmates Are Running the Asylum. Sams Publishing, 2004, 288 p.

15. Бланшет Ж, Саммерфилд М. QT 4: программирование GUI на C++. М.:

Кудиц-Пресс, 2007, 628 стр.

16. KDevelop team Sublime UI Description [HTML] (http://www.kdevelop.org/mediawiki/index.php/Sublime_UI) 17. John Deacon Model-View-Controller Architecture [PDF] // Software Development Training Courses in the UK and Europe 18. The Kate Team Kate Editor Official Website [HTML] (http://kate-editor.org/) 19. Philippe Fremy KDE Technology: KParts Components [HTML] (http://phil.freehackers.org/kde/kpart-techno/kpart-techno.html) 20. KDE Team API KDE Reference [HTML] (http://api.kde.org)