Crystal Programming. Введение на основе проекта в создание эффективных, безопасных и читаемых веб-приложений и приложений CLI

• notify_uninit — используется для деинициализации libnotify.

• notify_notification_new — используется для создания нового уведомления.

• notify_notification_show – используется для отображения объекта уведомления.

В дополнение к этим методам нам также необходимо определить одну структуру NotifyNotification, которая представляет собой отображаемое уведомление.

Я определил это, просмотрев файлы *.h libnotify на GitHub: https://github.com/GNOME/libnotify/blob/master/libnotify. HTML-документация Libnotify также включена в папку этой главы на GitHub, и ее можно использовать в качестве дополнительной справки.

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

@[Link("libnotify")]

lib LibNotify

  alias GInt = LibC::Int

  alias GBool = GInt

  alias GChar = LibC::Char

  type NotifyNotification = Void*

  fun notify_init(app_name : LibC::Char*) : GBool

  fun notify_uninit : Void

  fun notify_notification_new(summary : GChar*, body :

    GChar*, icon : GChar*) : NotifyNotification*

  fun notify_notification_show(notification :

    NotifyNotification*, error : Void**) : GBool

  fun notify_notification_update(notification :

    NotifyNotification*, summary : GChar*, body : Gchar*, icon : GChar*) : GBool

end

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

Под капотом Crystal использует https://www.freedesktop.org/wiki/Software/pkg-config, если таковой имеется, чтобы определить, что следует передать компоновщику для правильного связывания библиотеки. Например, если бы мы проверили команду полной ссылки, которую Crystal выполняет при сборке нашего двоичного файла, мы бы смогли увидеть, какие флаги используются. Чтобы увидеть эту команду, добавьте флаг --verbose к команде сборки, которая будет выглядеть как Crystal build --verbose src/transform_cli.cr. Это выведет достаточное количество информации, но мы хотим посмотреть в самом конце, после опции -o, указывающей, каким будет имя выходного двоичного файла. Если бы мы запустили pkg-config --libs libnotify, мы бы получили -lnotify -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0, что мы также можем увидеть в команде необработанной ссылки.

Если pkg-config не установлен или недоступен, Crystal попытается передать флаг -llibnotify, который может работать или не работать в зависимости от связываемой библиотеки. В нашем случае это не так. Также можно явно указать, какие флаги следует передавать компоновщику, используя поле аннотации ldflags, которое будет иметь вид @[Link(ldflags: "...")].

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

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

Причина создания NotifyNotification непрозрачного типа заключается в том, что libnotify обрабатывает создание/обновление структуры внутри себя. Ключевое слово type позволяет нам создавать что-то, на что мы можем ссылаться в нашем коде Crystal, не заботясь о том, как это было создано.