Деякі особливості розробки під Ubuntu Touch



Прийшла весна. Коти думаю про кішок, чоловіки про жінок, а програміст — куди б ще портувати наявний код. Я ще минулої осені став володарем Meizu MX4 Ubuntu Edition, і тому вибір був давно очевидна. А тут знайшлося і час, і сили.

Освоєння нової платформи полягало в портировании на неї спочатку бібліотеки Allegro, а потім — моєї гри Return of Dr. Destructo, про яку я вже тут писав, і мобільна версія якої все ще знаходиться в розробці під iOS і Android, але вже ось-ось незабаром коли-небудь вийде.

Втім, на особливостях портування саме мого проекту в цьому пості я зосереджуватися не буду, а просто розповім, з якими підводними каменями зустрівся в цей раз. Цілі у мене дві: по-перше, систематизувати й об'єднати в одному місці інформацію, яка може бути корисна початківцям розробникам під Ubuntu Touch, а по-друге — просто нагадати всім про існування цієї платформи, з надією спільними зусиллями зробити її провідною на світовому ринку, а то на основну пару лідерів у мене професійна алергія.

Мій досвід з даної платформою поширюється виключно на розробку OpenGL додатків, тому якщо вас більше цікавить використання нативного UI (Qt), то тут ви можете знайти для себе не так багато цікавого. Втім, якраз розробка Qt і QML додатків досить непогано документована на офіційних ресурсах, на відміну від моїх завдань (і ЩЕ одна платформа знову забула про геймдеве на старті...).

Чим хороша Ubuntu Touch, і почати з нею працювати
Особисто для мене, як для розробника ігор, Ubuntu Touch хороша, в першу чергу, тим, що на відміну від Android тут програми на C++ є громадянами першого сорту. Всі системні бібліотеки і служби мають C++-інтерфейси, не потрібно писати жодного коду на дивних мовами, щоб створити віконце або відправити запит на оплату. Офіційна IDE — QtCreator, не позбавлена недоліків, особливо в плані налагоджувального UI, але в цілому дуже непогана, а головне — «з коробки» добре підтримує налагодження C++ додатків на пристрої, яку Google у своєму Android Studio досі прикрутити нормально не може, бе-бе-бе. Ну, а плюс у порівнянні з iOS тут головне в тому, що не потрібно мати Mac (або страждати з погано працюючими віртуальними машинами)

Тепер про мінуси. По-перше, вам все ж доведеться поставити Ubuntu або якийсь більш-менш сумісний Linux. Причому поставити його на Virtual Box — поганий варіант! Розробники Ubuntu Touch-плагіна під QtCreator використовували OpenGL (QtQuick) для відтворення свого UI, і як результат, у Virtual Box все це працює дуже погано — наприклад, вікно QtCreator'a завжди поверх інших вікон.


Ubuntu IDE вітає нас

Так, особисто мені не вдалося змусити Ubuntu SDK побачити моє пристрій, поки я намагався працювати в Virtual Box, при тому, що сама Ubuntu його бачила. Але тут, можливо, був мій косяк, я так і не розібрався, і поставив Ubuntu на реальне залізо.

Щоб почати розробляти додаток під Ubuntu Touch, найпростіше поставити Ubuntu SDK. Загалом-то, ніхто не заважає завантажити потрібні компоненти і руками, але мені здається, це більше болю, ніж потрібно в організмі. інструкції для установки SDK треба підключити PPA, в якому вона живе (взагалі-то, SDK є і в звичайному Software Centre, але може бути якийсь не тієї версії?).

Якщо ви будете поки що задовольнятися емулятором, то далі треба його створити в закладці Devices. Процес докладно описаний, однак змусити його працювати мені так і не вдалося — емулятор начебто як створювався, але бачити його IDE не хотіла (можливо, я вказав при створенні версію framework, відмінну від тієї, з якою компилировал програму).

Щоб запуститися на пристрої, доведеться включити на ньому режим розробника. До мого неймовірного здивування, для цього потрібно встановити на ньому PIN-код, яким я раніше не користувався! Дуже незручно, минусик Canonical, Андроїд такий фігньою займатися не змушує.

Крім того, комп'ютер буде бачити телефон, тільки якщо у включений екран і знятий лок-скрін (який з кружечком). Що цікаво, набирати ПІН-код як раз не треба.


Підключений пристрій здорової людини

Якщо навіть після цього ваш телефон (а може бути і планшет) все одно не з'явився у списку пристроїв у вкладці Devices, то доведеться згадати отримані при спілкуванні з все тим же Андроїдом навички, і лізти правити конфігурацію ADB (оскільки поки що все наличиные пристрої з Ubuntu Touch в основі своїй є Андроїд-пристроїв). Пости (1, 2) рекомендують додати в файл ~/.android/adb_usb.ini vendorID вашого пристрою.

chroot, навіщо він потрібен для компіляції під Ubuntu Touch, і що з ним робити
Досвідчені користувачів linux, давно знайомі з chroot, schroot, а може вже навіть і з click, можуть пропустити цю секцію, щоб не сміятися над тим, як жалюгідні виндузятники пізнають міць Лінукса.

Щоб скомпілювати програму, ясна річ, потрібна хмара все — компілятор, програма компонування, гора бібліотек. Все це повинно бути в наявності під ту платформу, під яку ми компілюємо. Google вирішили цю проблему, задавши кілька змінних оточення і створивши свої власні скрипти для складання (ndk-build). Рішення, треба сказати, досить поганий, з працею працює з зовнішніми системами збирання, і ненадійна, як і вся підтримка C++ «корпорація добра». Зате платформо-незалежна (ну, в теорії).

Ubuntu SDK поки працює тільки під Ubuntu, втрачає йому нічого, тому тут все по іншому. Для складання створюється файлова система, повністю відображає нормальну линуксовую, але з gcc під ARM, і з бібліотеками для архітектури armhf в потрібних каталогах. Далі, ця ФС оголошується рутовой на час складання, і все працює, як якщо б у нас просто був ось такий хитрий, спеціально заточений під зборку для ARM Linux.

Досягається це за допомогою механізму chroot, що дозволяє працювати з цими ось самими хитрими ФС. Потрібні chroot'и Ubuntu SDK створює сама по вашій команді, тому розбиратися з ними досконально не обов'язково. Але врахуйте, що це процес досить довгий, т. к. весь вміст chroot'а (а це багато-багато пакетів, близько 1.5 Gb) викачується з мережі, а створювати його треба під конкретну архітектуру (i386 для емулятора, або armhf для реального пристрою або іншого емулятора) і конкретну версію SDK.

Цікаве починається тоді, коли ви вирішили, що хочете використовувати не тільки ті бібліотеки, які йдуть в стандартній поставці chroot'а, а ще які-небудь додаткові. Документація свідчить, що все, що входить в постачання chroot'a — гарантовано буде на телефоні, завжди в сумісних версій, тому з такими бібліотеками можна сміливо лінкуватися динамічно, і розраховувати на те, що у юзера на телефоні все запрацює. Але багато чого з того, що потрібно для життя розробника ігор там немає: libpng, libfreetype, libogg… Все це доведеться ставити руками, і ось тут з'являється необхідність знати про chroot'ах більше.

Справа в тому, що chroot підтримує не тільки роботу з окремою подменной ФС, але і створення її знімків. Базовий, source знімок при звичайній роботі залишається незмінним, щоб ви не робили. Більш того, можна настворювати сесій, і у кожної сесії теж буде свій знімок source, який буде жити, поки жива сесія (і, що важливо, не буде відображати змін в source, якщо вони за цей час відбудуться!). Сесії, створювані Ubuntu SDK переживають не тільки рестарт редактора, але навіть перезавантаження комп'ютера!

Правильні спосіб ставити нові бібліотеки в chroot — використовувати кнопочку «Maintain» в закладці «Click» в розділі «Ubuntu» в налаштуваннях IDE. Це дасть вам консоль, в якій можна покликати apt-get install libpng-dev:armhf тощо. При цьому, зміняться буде як раз source chroot. Щоправда, не знаю, перезавантажить свої сесії редактор.


Ось вам скріншот, щоб не заблукати

Якщо ж вам захотілося полазити по chroot'у руками, з-за меж IDE, або, скажімо, написати скрипт, що автоматизує установку потрібних пакетів в свежескачанный chroot, то команди для цього описані в документації, але я повторю їх тут, бо особисто я їх там в перший раз упустив, і довго гальмував.

click chroot -a armhf -f ubuntu-sdk-15.04 run COMMANDNAME — запускає COMMANDNAME всередині (не source!) chroot'a і відразу ж виходить. Параметр -a — архітектура, для якої створений chroot, -f — версія SDK. За допомогою цієї команди, встановити в chroot нічого не можна (все встановлене тут же зникне), але можна запустити, наприклад, збирання, або find, з метою знайти що-небудь всередині chroot'овою ФС.

click chroot -a armhf -f ubuntu-sdk-15.04 install PKGNAME — запускає apt-get install PKGNAME, змінює source chroot

click chroot -a armhf -f ubuntu-sdk-15.04 maint — аналогічно кнопочці «Maintain», запускає консоль для зміни source chroot'a

І ще пара важливих команд:

schroot --list --all-sessions — нам покаже список всіх активних сесій

schroot --end-session SESSION_ID — уб'є зазначену сесію

Якщо ви поставили бібліотеку в chroot самостійно за допомогою install або maint — не забудьте вбити сесії, що належать Ubuntu SDK, інакше QtCreator не помітить зроблених змін (я втратив із-за незнання цього дня)!

Наостанок, уточню: те, що ви поставили в chroot руками — на телефоні буде відсутня! Тому з такими бібліотеками треба або лінкуватися статично, або тягати їх з собою в click-пакет (просто вказати, які либы вам потрібні, і сподіватися, що при установці вашого пакета в систему залежності докачаются самі, як при використанні deb, не можна — click так не вміє ідеологічно).

Світу — Mir
Звичних Іксів на Ubuntu Touch немає. Замість них, там є давно обіцяний Canonical Mir, який все ніяк не прийде на десктопи, а на мобілках — вже будь ласка, привіт, ось і він. За своїм API, Mir дуже милий — все просто, досить непогано документовано, і, диво із чудес, більшість функцій і мають синхронний, а асинхронний варіант, що таке взагалі супер, що суперее нікуди. Більше того, якщо раптом хочеться чомусь покликати асинхронну функцію, а потім, в іншій точці, дочекатися її результату — є mir_wait_for, який це зробити дозволяє. Просто ніби люди писали, а не звичайні інопланетяни!

З мінусів, слід відзначити майже повну відсутність офіційних прикладів Mir-клієнта. Те, що лежить на вікі — демонструє лише самі-самі основи, і не демонструє того, що потрібно нам — а саме, як зв'язати MirSurface і контекст OpenGL. На щастя, в інших місцях приклади можна знайти.

Врахуйте, що API Mir'a поки не дуже стабільний, тому наведений вище приклад не компілюється — функції mir_surface_get_egl_native_window не існує. Замість неї, для отримання з MirSurface вікна, сумісного з eglCreateWindowSurface, слід використати зв'язку mir_buffer_stream_get_egl_native_window
(mir_surface_get_buffer_stream(surface))
.

Також, слід пам'ятати, що Ubuntu Touch не підтримує OpenGL ES першій версії — тільки OpenGL ES2 і 3! Потрібні хидера і бібліотеки просто відсутні. Тому, якщо у вас, як у мене, десь завалявся легасі-код часів Очаківські та істотно до нового підкорення Криму, то доведеться обкласти його ifdef'ами.

Не забудьте передати в списку атрибутів eglChooseConfig пару

EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT

А в списку атрибутів контексту для eglCreateContext —

EGL_CONTEXT_CLIENT_VERSION, 2

Інакше будете довго здивовано дивитися на багатозначні помилки BAD_CONFIG і BAD_ATTRIBUTE. Чорт забирай, XXI століття надворі, OpenGL досі не вміє розповісти, який саме аттрибут поганий, і що йому не сподобалося в конфіги…

Обробка введення в Mir здійснюється шляхом встановлення обробника подій. Що абсолютно чудово — якщо ви використовуєте Mir з програми на C++, то вам буде доступний варіант API з підтримкою std::function як коллбэков. Ну, а якщо вам більше до душі звичайна C, то буде вам варіант з простими вказівники на функції void *context.

А коди клавіш Mir надсилає ті ж самі, що X11, так що не поспішайте викидати ваш варіант функції get_key_name!

Make it Click
І ось, припустимо, портируемый нами код скомпилировался, і готовий до запуску. Виникає питання, як його засунути на пристрій, разом з ресурсами, динамічними бібліотеками й іншими чортами рогатими. deb нині не модно, на rpm, який ви ніжно любите ще з Mandrake 6.0, Ubuntu Touch навіть не подивиться, а треба використовувати новий формат пакетів — Click. Саме його і збирає Ubuntu IDE для заливки на телефон.

На мій погляд, істотним мінусом Click-пакетів у порівнянні з IPA або APK є те, що він — не ZIP, а щось своє, хитре. Як результат, от просто взяти і подивитися, що ж там напаковалось — ніззя, доведеться лізти в консоль, розбиратися в ключах click. Втім, звичайно, скоро хто-небудь напише плагін для Midnight Commander, щоб була Click VFS, і все знову стане більш-менш добре.

Істотним плюсом click є те, що засунути в нього можна що завгодно, і як завгодно всередині розташувати (майже). Все, що там лежить, під час запуску пакета буде смонтированно в якості файлової системи від кореня, і далі ви зможете шукати бібліотеки і дані за звичним вам шляхами в якому-небудь /usr/local. Це, звичайно, якщо ваш додаток переїхало на Touch з звичайного Лінукса. Якщо ж воно — гість з ворожою Вінди, то може вам і не треба дублювати структуру папок, звичну линуксоидам, а просто плюхнуть виконуваний файл прямо в корінь, а дані — поруч, щоб не шукати, і все зручно і просто. За замовчуванням, Ubuntu IDE робить саме перший варіант, але умовити її перейти до другого за допомогою редагування CMake або QMake файлів — не складно, якщо ви вже знайомі з їх INSTALL-директивами.

І є, значить, ще один тонкий момент, а точніше, три. Для підготовки click-файлу, вам ще знадобляться:

a) manifest.json — файл з описом, що ваша програма є, для якої вона архітектури, і кого бити, якщо щось не працює. Він містить імена для наступних двох файлів у розділі «hooks»

б) AppName.desktop — файл, що описує як вище додаток на телефоні виглядає — ім'я, іконка і т. п. — і як себе веде. Останнє стосується, наприклад, налаштувань сплеш-екрану, а також допустимих орієнтацій (див. нижче)

в) AppName.apparmor — файл, де перераховане, що вашій програмі можна (за замовчуванням — все можна). Аналог permissions в AndroidManifest.xml.

Тут ми з деяким здивуванням натикаємося на відсутність документації. Базове вміст усіх трьох файлів проблеми не представляє — його можна підглянути в шаблонах, або в мережі, але я приведу їх тут для повноти.

manifest.json:

{
"name": "APPNAME.DOMAINNAME",
"description": "DESCRIPTION",
"architecture": "ARCH",
"title": "TITLE",
"hooks": {
"APPNAME": {
"apparmor": "APPNAME.apparmor",
"desktop": "APPNAME.desktop"
}
},
"version": "VERSION",
"maintainer": "NAME SURNAME <EMAIL@ISP.COM>",
"framework": "FRAMEWORK"
}

Вміст manifest.json легко редагується за допомогою вбудованого в Ubuntu IDE редактора.

AppName.apparmor:

{
"policy_groups": [
"networking",
],
"policy_version": 1.3
}

Сюди треба додавати потрібні вам дозволу. Це теж зручніше робити через редактор IDE.

AppName.desktop:

[Desktop Entry]
_Name=VISIBLE_APP_NAME
Exec=EXECUTABLE_NAME
Icon=ICON
Terminal=false
Type=Application
X-Ubuntu-Touch=true
X-Ubuntu-Supported-Orientations=landscape

А ось desktop-файл чомусь не редагується в IDE, точніше, відкривається просто у вигляді тексту. На перший погляд, це не проблема, але на другий, коли добираєшся до кінця і бачиш всі ці X-Ubuntu-Whatever, відразу виникають питання — а скільки цих налаштувань взагалі, і які вони бувають. Розробники під нову платформу — вони подібні дослідникам нового континенту, і тому запитувати їх про такі речі — все одно, що питати дослідника, скільки на новому континенті річок — «а хрін його знає». Документації по нашому континенту Ubuntu в цьому плані майже немає. Відомо наступне:

Загальна документація щодо формату є тут, і містить багато корисного, але тільки не X-поля.

X-Ubuntu-Touch=[true/false] — це несучий милицю, який показує, що додаток телефонне, а не десктопное.
X-Ubuntu-Supported-Orientations=[portrait/landscape/primary] — допустимі для програми орієнтації екрану (primary — це, як я розумію, portrait для телефонів і landscape для планшетів). Список взято звідси, більше офіційних доках є тільки перші два варіанти; щоб підтримувати всі можливі положення екрана — не вказуйте цей ключ взагалі.
X-Ubuntu-Gettext-Domain=[?] — має відношення до вибору файлу перекладу, який буде використовувати. Точніше — я не зрозумів, з документацією всі тухло.

Поля, які контролюють поведінку сплеш-екрану:
X-Ubuntu-Splash-Show-Header=[true/false] — показувати заголовок додатка на сплеш-екрані.
X-Ubuntu-Splash-Title=[TEXT] — який саме текст показувати в заголовку.
X-Ubuntu-Splash-Image=[FILENAME] — зображення, яке буде показано на сплеш-екрані. Зображення буде показано у тому розмірі, в якому вони є, без підгонки під розмір екрану.
X-Ubuntu-Splash-Color=[COLOR] — (суцільний) колір фону сплеш-скрін в форматі QColor::setNamedColor.
X-Ubuntu-Splash-Color-Header=[COLOR] та X-Ubuntu-Splash-Color-Footer=[COLOR] — кольору верху і низу сплеш-скрін, між якими буде зроблений градієнт.

Загальний список цих додаткових полів поки що відсутня. Спроба добути його з исходников Unity8 поки не увінчалася успіхом — я знайшов місце, де обробляються пара налаштувань, але решта там ніде навіть не згадуються, хоча і працюють.


Редактор manifest-файлу. Ось хочу такий же для desktop-файлів

Ubuntu IDE: CMake vs. QMake
Досвідчений линуксоид, звичайно, з презирством дивиться на всі ці ваші IDE, збирає програми за допомогою старого доброго make, встановлює їх на пристрій з консолі, і налагоджує консольним ж gdb. Ми ж, зніжені принадами Visual Studio та інших богопротивных IDE, хочемо, щоб нам було на блюдечку з блакитним графічним інтерфейсом. Тому намагаємося використовувати Ubuntu IDE, а також трохи менше інопланетні системи збирання, наприклад, CMake або QMake.

Якщо ви фанат QMake, і використовуєте його для всіх ваших проектів, у мене для вас чудові новини — на Ubuntu Touch у вас все буде зашибісь! Підключіть потрібний модуль за допомогою load(ubuntu-click), додайте в проект описані вище маніфести, і все повинно запрацювати.

З CMake в теорії теж все просто. Для того, щоб Ubuntu IDE почала запускати ваші проекти на телефоні, достатньо вказати в вашому CMakeLists.txt наступний рядок з шляхом до manifest-файлу вашого додатка:

set(UBUNTU_MANIFEST_PATH "manifest.json" INTERNAL CACHE "Path to empty file")

Дуже важливий момент — обов'язково вкажіть, що змінна потрапляє в кеш! IDE буде її шукати саме там, а якщо не знайде, то нічого не скаже, але працювати все буде неправильно. Крім того, мої експерименти показали, що не можна вказувати шлях до manifest'у через змінні CMake. У всякому разі, значення "${CMAKE_SOURCE_DIR}/manifest.json" приводило до того ж ефекту, як якщо б я взагалі не вказав нічого.

Далі, має місце бути дивне, і я б навіть сказав бажное поведінка IDE. Навіть якщо ви вказали абсолютно правильно, IDE створить для вашого додатки дві конфігурації запуску. Перша буде по імені збігатися з тим, що у вас було зазначено в CMakeLists.txt у add_executable. Це погана, негідна конфігурація, і вона обрана за замовчуванням! У цій конфігурації, складання коду та пакету йде під ARM, а ось запускати все це IDE буде пробувати на десктопі. Чого у неї, природно, не буде виходити (якщо у вас не ARM-десктоп), і ви будете бачити в Application Output помилки виду

Selected architecture arm is not compatible with reported target architecture i386:x86-64
Architecture rejected target-supplied description Debugging has finished

Щоб так не було, треба зайти в закладу Run в розділі Projects вашого проекту, і там перемкнутися на другу конфігурацію. Її ім'я буде взято з manifest-файлу з розділу «hooks». Якщо воно буде співпадати з тим, що було зазначено в add_executable, то до нього буде дописана цифра 2 (наприклад, «cmake_test2»). Це ось хороша конфігурація, якщо вибрати її проект буде намагатися запускатися на вашому пристрої (або емуляторі).

До речі, з бібліотеками, зібраними CMake, вас чекає ще один неприємний сюрприз: якщо ви надумаєте в межах сесії IDE вибудувати залежності між либами і додатком, то нічого у вас не вийде. Справа в тому, що Ubuntu IDE для зібраних бібліотек спробує викликати крок Deploy (чи то пак, Install в термінах CMake), і обламається, тому що у бібліотеки, сюрприз-сюрприз, немає manifest.json (який їй нафіг не вперся). Розробники кажуть, що такий спосіб використання IDE не передбачений, і, швидше за все, в цьому плані нічого не зміниться. Додавайте бібліотеки суб-проектами — тоді все буде добре.

По першому ж дивакуватістю, мною заведений баг багр-треккере Ubuntu IDE.


«Погана» конфігурація. Зверніть увагу на парметр запуску — аргументи командного рядка і робочу папку. Це вірна ознака того, що IDE буде намагатися запускати ваш проект на десктопі замість телефону! Не звертайте уваги на крок «Deploy to Ubuntu Device» у списку кроків запуску — на пристрій-то ваш пакет може і заллється, але запускатися все одно буде на десктопі.


«Хороша» конфігурація. Як видно, замість командного рядка і робочої папки — зовсім інші налаштування.

Як я раніше без цього жив?!
Наостанок, ще поділюся трюком, який не має до Ubuntu Touch ніякого відношення, але який я дізнався лише нещодавно, а хотів дізнатися — як мінімум, рік тому, якщо не більше. Деколи, стоїть завдання слинковать додаток не з динамічною, а зі статичною версією бібліотеки. Звичайно, у gcc є прапор -static, але він не дуже зручний (так ще, по моєму досвіду, і не працює в якихось випадках). Але виявляється, можна робити ось так:

gcc yourprogram.o -ldynamiclib -l:libstaticLib.a
У цьому випадку, перша бібліотека буде взята та, яка є (тобто, зазвичай динамічна), а друга — суворо статична. Зверніть увагу, що після двокрапки треба вказувати ПОВНЕ ІМ'Я файлу, разом з lib і .a!

Цей трюк спрацює в QMake-файлі, а от якщо вам хочеться слинковаться зі статичною бібліотекою в CMake, то просто треба в аргументах target_link_libraries написати не libname, а libname.a, і все спрацює автоматично.

Висновок
Розробка під Ubuntu Touch поки що сповнена труднощів і пригод. Єдиний компонент системи, не завдав мені клопоту, це Mir. Основні труднощі становить майже повна відсутність документації та місцями дивна і непередбачувана поведінка IDE. Крім того, постійне оновлення всього бере участь у розробці софта завжди має шанс що-небудь зламати (наприклад, у мене протягом дня був поламаний chroot для збирання — але не зовсім, а просто не міг оновитися; після викочування фікса, довелося її перебудувати, що є велика трата часу).

Допомога з проблем, пов'язаних з Ubuntu Touch і розробкою під неї можна отримати за наступними каналами:

AskUbuntu — StackOverflow для Убунту в цілому. На питання про Touch відповідають, але мало і з великими затримками.

Ubuntu Phone Mailing List — список розсилки для користувачів Ubuntu Touch. На питання розробників тут майже ніколи не відповідають, але якщо у вас щось глючить в телефоні — то висока ймовірність, що саме тут вам допоможуть.

#ubuntu-app-devel IRC — IRC канал для спілкування розробників під Ubuntu Touch. Якщо вам вдасться достукатися до когось із досвідчених розробників, наприклад, Core-Apps, то вам цілком можуть допомогти вам з вашими питаннями, але більшу частину часу тут, як і в будь-якому технічному IRC, стоїть гробова тиша, а питання «в повітря» игонрируются. Hint: не бійтеся використовувати ключове слово appdevs, щоб захайлайтить розробників (див. тему каналу)!

Також існує список розсилки для розробників, але він мертвий. На IRC є й інші канали, пов'язані з Ubuntu Touch, див. повний список на Вікі.

Що до мене, то я не впевнений, що я буду займатися розробкою під цю платформу за межами портування поточного проекту. Не тому, що мені не сподобалося, але тому, що немає більше відповідних проектів, поки що. Тим не менш, у цієї посади ще може з'явитися продовження — коли я розберуся з новим API для платежів Ubuntu Pay, з тим, чому у мене не працює звук, з проблемами згортання і розгортання програми та в цілому доведу гру до стану, близького до релізу. Якщо, звичайно, набереться якогось цікавого матеріалу.


Ну, і наостанок, скріншот мого проекту, запущеного на пристрої. Як видно, мені поки не вдалося прибрати верхній барчик (IRC кажуть, що це баг поточної версії ОС)

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.