По роду деятельности мне достаточно часто приходится заниматься созданием или доработкой библиотечных элементов под Archicad^®. Не могу сказать, что мне это доставляет удовольствие — несмотря на то, что сам процесс является хоть и достаточно простым, но, в тоже время, и неудобным. Сама простота концепции библиотечных объектов, подразумевающая низкий порог вхождения, является обратной стороной медали, когда приходиться сталкиваться с реализацией действительно сложных задач, написанием сложных объектов с непростыми внутренними алгоритмами или вычислениями.

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

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

Платформа

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

В качестве платформы я выбрал Sublime Text 3 — небольшой, удобный и шустрый редактор, для которого написана масса плагинов и расширений. Первым делом, ставим Package Control, позволяющий нам устанавливать и оперировать самими плагинами. Из расширений:

• SFTP
• Theme Soda (Dark)

Не буду подробно описывать шаги по их установке и настройке — все можно найти по ссылкам. Отмечу, что не лишним будет засинхронизировать ST, например, через Google Drive или Dropbox.

Далее начинается самое интересное.
Понятное дело, что залезть внутрь самих .gsm файлов из редактора мы не сможем. Поэтому, будем использовать Graphisoft^® LP_XMLConverter, преобразующий объект в обычный xml-файл, который уже отлично можно будет использовать в Sublim’e.

Сам процесс конвертации достаточно прост. Установив конвертер, запускаем стандартную консоль (cmd) и перемещаемся в его директорию.

cd “C:\Program Files (x86)\Graphisoft\Converter”

Можно сконвертировать все дерево библиотечных элементов:

LP_XMLConverter l2x [+l lang] [+img folder] source dest

• -l — опционально, кодировка объекта, с допустимыми значениями UTF8, INT, CEU, BAL, CYR… Я обычно использую UTF8
• img — опционально, изображение библиотечного объекта
• source — директория-источник, где находятся библиотечные raw-скрипты
• dest — директория, где будут размещены сконвертированные xml файлы

Либо же использовать следующую команду:

LP_XMLConverter libpart2xml [+l lang] source dest

Где source будет конкретным путем к файлу (включая его имя), а dest — его сконвертированным результатом.

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

Синтаксис и цветовые схемы

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

Правка синтаксиса

Я решил создать свою цветовую схему на базе дефолтной Monokai, чтобы максимально упростить ее. Это обычный xml-файл, хоть и носит другое расширение — .tmTheme. Его структура предельно проста, возьмем из прикрепленного исходника небольшой участок:

<dict>
  <key>name</key>
  <string>Comment</string>
  <key>scope</key>
  <string>comment</string>
  <key>settings</key>
  <dict>
    <key>foreground</key>
    <string>#75715E</string>
  </dict>
</dict>

Эта нода описывает подсветку комментариев в окне редактора. foreground — параметр, который нужно изменить, #75715E — непосредственно сам цвет.

Теперь, непосредственно сам синтаксис. Структура практически та же, расширение — .tmLanguage. Например, нода, описывающая некоторые 2д команды:

<!-- 2D commands -->
<dict>
  <key>name</key>
  <string>entry.command.2d.gdl</string>
  <key>match</key>
  <string>\b(add2|mul2|rot2|line2|circle2|text2|hotspot2|poly2_b|project2)\b</string>
</dict>

Где entry.command.2d.gdl — к какой цветовой ноде необходимо обращаться, причем, сопоставление будет происходить по родительской entry. command, поскольку ее подэлементы в цветовой схеме не определены. add2|mul2|rot2|line2|circle2|text2|hotspot2|poly2_b|project2 — сами gdl-команды, подсвечивающиеся болдом (b) и перечисленные через |.

Подробное руководство по составлению синтаксиса — sublimetext.info/docs/en/extensibility/syntaxdefs.html.

Параметры объекта

Параметры объекта

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

Остается небольшая проблема — после отладки скрипта его необходимо будет сконвертировать обратно в gdl-файл. Ручной режим немного утомляет, но в Sublime предусмотрена такая гибкая штуковина, как Build System, с помощью которой можно будет автоматизировать рутину. Подробнее о ней — в следующей части.

Цветовая схема: drive.google.com
Синтаксис: drive.google.com