11.Розробка додатків для QNX Windows
Незважаючи на класичний прикладний інтерфейс із мовою “С”, QNX Windows зсередини являє собою обьєктно-орієнтовану систему, як і у випадку з X Window. Тут також використовується поняття ресурсу, але в іншому змісті. Ресурси - це картинки (pictures), елементи (picture elements), екрани (screens), вікна (windows), кватирки (panes) і діалоги (dialogs). Кожен ресурс має власника (процес) і ім'я (символьний рядок). Підтримка ресурсів здійснюється відповідними менеджерами. Деякі з ресурсів мають ієрархічні взаємини:
Додатки взаємодіють з QNX Windows створюючи ресурси і маніпулюючи ними. Наприклад, вікна можуть бути відкриті і закриті, картинки - створені, скопійовані і вилучені, елементи - намальовані, скопійовані, переміщені, вилучені і т.д. Любою ресурс може знаходитися на будь-якому вузлі мережі QNX, оскільки всі маніпуляції здійснюються через прозорий для мережі механізм передачі повідомлень.
Базовою основою роботи QNX Windows із графікою служить унікальна концепція ‘картинки’ (picture). Картинку можна уявити собі як лист папера з координатною сіткою, незалежної від пристрою відображення (ідея, що викликає асоціації з мовою PostScript). Координати виміряються в типсах (tips) - десятих частках пункту - типографської одиниці, рівного 1/72 дюйма. Початок координат знаходиться в лівому верхньому куті, розміри картинки обмежені координатами 65535. Весь графічний висновок, якщо спеціально не зазначене інше, відбувається не у вікна, а в картинки (вікно може і не існувати).З кожної з ‘кватирок’ вікна можна динамічно зв'язати будь-яку існуючу картинку, можна також перемінити картинку в будь-який момент.
Інша фундаментальна концепція полягає у визначенні поняття графічного елемента(picture element), інакше кажучи об'єкта маючого тип. Типи в основному відповідають стандартним елементам, визначеним в інтерфейсі OPEN LOOK, і, саме головне, ці типи відомі менеджеру екрана. Висновок у картинку здійснюється сервером, по запиті додатка, що повідомляє серверу тип елемента, якому необхідно створити, і його атрибути. Усе, що з'являється на екрані є екземпляри елементів того чи іншого типу. Картинка ж є не що інше, як упорядкований список елементів.Це відноситься не тільки до картинок, створеним програмою, але і до вікон, меню, іконкам і т.п.
QNX Windows використовує наступні типи елементів:
| arc | дуга еліпса |
| button | кнопка |
| curve | крива Безьє 3-го порядку |
| group | комбінований елемент визначений програмістом |
| image | довільний кольоровий растр, від 4 до 16 біт на піксель |
| line | лінія |
| link | посилання на інший елемент |
| number | число ( чиціле з крапкою, що плаває,) |
| paragraph | параграф тексту (з табуляцією, відступами і шрифтом) |
| pixmap | растр, у форматі залежному від пристрою висновку |
| points | полігон (можливо замнкутый) |
| rectangle | прямокутник |
| symbol | довільний растр, що містить до 16 бітових площин |
| string | простий неформатованный текст |
| text | форматованный текст (з довільним шрифтом) |
З будь-яким елементом може бути асоційована мітка (label), діалог чи довільні дані, визначені програмістом. У залежності від типу, елементи мають характерний набір атрибутів (координати, колір, колір тіла, товщина ліній, шрифт і т.п.). Елементи всіх типів можуть мати також опції (options) і стану (states), що визначають поводження елемента і спосіб його висновку. По поводженню при натисканні на нього мишею, елемент може бути 'обираним' (selectable), що редагується, ' щоповідомляє' (notify), блокованим, що інвертує чи стан запам'ятовує стан. Виводитися елемент може стандартно, безпосередньо у вікно (минаючи картинку), із затемненням, з рамкою, з 3D-ефектом, з тінню.
Описуються елементи з незалежним від пристрою способом, за допомогою спеціальних структур даних. Упорядкована сукупність таких описів, постачена заголовком, утворить стандартну картинку (елементи існують тільки усередині картинок). Така картинка може бути збережена у файлі формату PICT і прочитана з нього.
Як уже згадувалося вище, елементами можна маніпулювати. Основним засобом ідентифікації елементів служить ім'я елемента (звичайно називане тегом). При цьому можуть використовуватися шаблони, схожі на шаблони імен файлів, що дозволяє ідентифікувати для однієї операції групу елементів (чи усі). Крім того, для ідентифікації може бути використана будь-яка комбінація опцій, що обмежує список елементів до бажаного складу (наприклад, можна специфікувати усі 'обирані' елементи), послідовний номер елемента в картинці, координати, прямокутна область картинки і т.д.
Для того, щоб зробити що-небудь з картинкою, додаток спецефікує елементи і вказує операцію, яку потрібно до них застосувати. З іншого боку, елементами може маніпулювати користувач, наприклад редагуючи значення текстового чи рядка змінюючи значення числа. У цьому випадку власник відповідного ресурсу (звичайно це процес створивший його), одержить відповідне повідомлення, якщо він замовляв подібне повідомлення. Інший підхід полягає в тому, що нові значення елементів можна запросити тоді, коли вони реально знадобляться. Процес-власник може також передати свої повноваження іншому процесу.
Для мінімізації вихідного коду QNX Windows використовує поняття графічного контексту, у якому зберігаються поточні значення ресурсів і атрибутів елементів усіх типів. Графічний контекст теж може бути збережений у файлі і відновлений відтіля.
Розглянуті вище концепції дозволили розроблювачам QNX Windows застосувати трохи дуже красивих і ефективних рішень, деякі з який не мають аналогів.
По-перше, усі ресурси, створювані додатками (вікна, картинки, діалоги) створюються менеджером екрана і зберігаються в його адресному просторі. Це радикально зменшує вимоги програм до оперативної пам'яті і підвищує швидкість виконання графічних операцій. Саме в цьому головну відмінність графічних елементів QNX Windows від виджетов X Window, що хоча і маскують від додатка деталі своєї роботи, але зберігаються в адресному просторі додатка. При цьому сервер у X Window усього лише виконує X Protocol, що має досить низький рівень. Наслідком цього є не тільки високий внутрішній трафік але і той менш помітний факт, що нитка керування при модифікації вмісту екрана дуже часто передається додатку, що дуже небажано для додатків реального часу. У QNX Windows усі зовсім інакше, тому що додаток повинний тільки замовити високорівневу операцію серверу, а виконує він її без подальшого втручання. При цьому витрати пам'яті на сервері теж невеликі, оскільки поняття типу елемента дозволяє відмовитися від збереження растрів, застосовуючи замість них картинки (сервер знає як малювати елементи відомого йому типу). Це злегка нагадує ОС NextStep, де зображення зберігаються у форматі Display PostScript, але картинки QNX Windows вимагають на порядок менше пам'яті (пом’ятаєте, що для кольоровий NextStep потрібно 64Mb пам'яті?) тому що PostScript описує абстрактні команди малювання, а не об'єкти визначених типів. По-друге, можливість групової ідентифікації елементів знижує трафік повідомлень і дозволяє серверу оптимізувати виконання графічних операцій. Крім того, це сильно спрощує логіку і розмір прикладних програм, про що ше буде сказано далі.
По-третє, маючи у своєму розпорядженні всі картинки і вікна, сервер може сам відслідковувати перекриття вікон, обчислювати відсікання і виконувати перемальовування умісту вікон! Це означає, що програма в QNX Windows не зобов'язана обробляти повідомлення типу EXPOSE чи WM_PAINT, як це приходиться робити в системах X Window чи MS Windows. Режим Backing Store, що з'явився в X Window System release 11, не йде ні в яке порівняння, оскільки там зберігаються растри, і у випадку недостачі пам'яті (що дуже ймовірно) сервер цей режим виключає (тобто програма не може і не повинна на нього покладатися). Звичайно, будь-яка проміжна ступінь вносить затримки, тому для програм, критично залежних від швидкості висновку на екран, передбачений режим прямого висновку елементів у вікно.
По-четверте, менеджер екрана може автоматично забезпечувати бажане поводження вікон і кватирок, що задається набором опцій, як і у випадку з елементами. Наприклад, можна спецмфікувати які події варто посилати власнику ресурсів, а які немає.
Більш того, деякі типові ситуації сервер може обробляти самостійно, наприклад видавати повідомлення при введенні користувачем значення, що виходить за границі зазначеного діапазону, автоматично виводити смуги прокручування при якщо картинка не міститься в кватирку цілком і підтримувати скролінг. Вікно може містити елементи зі стандартними тегами, при натисканні на який сервер буде виконувати стандартні дії. Для елементів можна задати їхнє поводження при проходженні над ними чи курсору при натисканні на них.
Якщо грамотно спроектувати інтерфейс, то в більшості простих випадків прикладній програмі залишиться тільки ініціалізувати його і закрити при виході, не вважаючи обробки декількох повідомлень, заради яких програма і написана. Саме завдяки таким можливостям QNX Windows можна називати інтелектуальним графічним сервером.
Ті, хто має досвід програмування в X Window, знають, що програми для цієї системи надзвичайно багатослівні. Величезна кількість функцій API робить його важкодоступним до огляду і ускладнює життя програмістам, через що для X Window була написана найбільша кількість генераторів коду. Мінімальна програма, що виводить у вікно напис hello world! має довжину близько 30 рядків, що ще дуже непогано в порівнянні з MS Windows. Розмір модуля, що виконується, виходить близько 800 Kb, у залежності від конкретної реалізації. У QNX Windows така програма виходить усього на двох рядків довше, ніж класичний варіант Керингана і Рітчі, якщо використовувати стандартний діалог, і ще на дві строчки довше, якщо використовувати звичайне вікно. Розмір модуля, що виконується, 7500 байт, при запуску програма займає 92 Kb (32-х розрядна версія, flat-модель).