Хэл Фултон - Программирование на языке Ruby

Рис. 12.10. Виджет TimerClock

Поскольку библиотека Qt написана на C++, неизбежны некоторые идиомы, отражающие ограничения этого языка. Иногда перевод на Ruby не выглядит на 100% естественным, поскольку в Ruby аналогичные вещи делаются несколько иначе. Поэтому в ряде случаев вводится избыточность, позволяющая выражать свои намерения «по-рубистски».

Например, имена методов, в которых сохранена «верблюжьяНотация», свойственная C++, можно записывать и с подчерками (_). Так, следующие два вызова эквивалентны:

Qt::Widget::minimumSizeHint

Qt::Widget::minimum_size_hint

Все методы установки свойств в Qt начинаются со слова set, например, Qt::Widget::setMinimumSize. В Ruby можно это слово опускать и пользоваться присваиванием, например:

widget.setMinimumSize(50)

widget.minimumSize = 50 # To же самое.

widget.minimum_size = 50 # To же самое.

Аналогично в Qt имена методов, возвращающих булевское значение, часто начинаются с isили has, например, Qt::Widget::isVisible. QtRuby позволяет именовать их в духе Ruby:

а.isVisible

a.visible? # То же самое.

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

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

Систему X Window System в разговорной речи называют (не совсем корректно) просто X Windows. Вероятно, она является прародителем если не всех, то абсолютного большинства графических интерфейсов пользователя.

Пользователи всех вариантов UNIX давно уже знакомы с X (как пользователи, а то и как разработчики). Часто поверх X запускается оконный менеджер Motif.

К достоинствам X следует отнести широкую известность, переносимость и богатый набор возможностей. К недостаткам — сложность работы.

Неудивительно, что существуют библиотеки для работы с X из Ruby. Из-за их сложности мы не приводим документацию, а отсылаем вас к архиву приложений Ruby RAA, где вы найдете библиотеку Xlib, написанную Кадзухиро Иосида (Kazuhiro Yoshida, известный также как moriq), и Ruby/X11 Мэтью Бушара (Mathieu Bouchard, он же matju). Обе годятся для создания X-клиентов.

Система wxWidgets (прежнее название wxWindows) функционально богата и стабильна. Они широко применяется в мире Python и по существу является «родным» графическим интерфейсом для этого языка. Философия библиотеки - пользоваться платформенными виджетами, когда это возможно. Версия для UNIX более зрелая, чем для Windows, но это положение, конечно, меняется.

В данный момент существует достаточно зрелая библиотека wxRuby. Если вам нравится именно эта система, то можете найти ее вместе с документацией на сайте http://wxruby.rubyforge.org/.

Настоящий хакер знает, что для серьезного программирования чистый Pascal бесполезен. Но на протяжении многих лет предпринималось немало попыток сделать этот язык пригодным для практического применения. Одна из самых успешных — Object Pascal компании Borland, ставший основой среды быстрой разработки Delphi.

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

Библиотека Apollo — попытка «поженить» Ruby и Delphi. Это детище Кадзухиро Иосида, хотя свой вклад внесли и многие другие. Основное достоинство Apollo — гигантский набор стабильных, удобных виджетов, а основной недостаток заключается в том, что на сегодняшний день она требует слегка «подправленной» версии Ruby. Она должна работать и с «классическим» продуктом Borland Kylix, который, по существу, является версией Delphi для Linux. Дополнительную информацию ищите в архиве RAA.

В главе 8 мы рассматривали вариант «графического интерфейса для бедных», когда для доступа к возможностям браузера Internet Explorer и другим подобным вещам используется библиотека WIN32OLE. С деталями можно ознакомиться по приведенным там примерам. Если вам нужно что-то сделать быстро, не заботясь об элегантности, то такое решение может оказаться приемлемым.

Если у вас есть склонность к мазохизму, то можете работать с Windows API напрямую. В этом вам поможет библиотека WIN32API(она обсуждается также в главе 14). Лично я не рекомендую такой подход, но о его существовании вы должны знать.

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

Мы рассмотрели реализацию общих концепций на примере библиотек Tk, GTK, FOX и Qt. Выяснили, что в каждом случае применяется своя терминология и слегка отличающиеся варианты основной парадигмы. Отметили также специфические средства и достоинства, присущие каждой библиотеке.

А теперь перейдем к совсем другой теме. В главе 13 будет рассмотрена работа с потоками в Ruby.

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

В Ruby потоки определены на пользовательском уровне и не зависят от операционной системы. Они работают в DOS так же, как и в UNIX. Но, конечно, это снижает производительность, а на сколько именно, зависит от операционной системы.

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

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