Изграждане на следващото поколение приложения

Подобрения и цели на платформата за Juno

Вече малко повече от 7 години елементарно си постави за цел да внесе убийствени приложения на настолни компютри с отворен код. По време на цикъла на разработка на Juno работихме усилено, за да постигнем нашето виждане за тези приложения, но не цялата работа, която свършихме, е видима за случайния потребител. В тази публикация ще говоря за малко история около това как поставяме нещата под капака и как изглежда новото нормално за елементарни приложения. Пристегнете се към шлемовете на разработчиците си и нека бъдем страховити.

Ген I

Ние доставихме първата версия на елементарна ОС с най-добрия си опит в разработването на завладяващи приложения с отворен код. Нямахме стандартен език. Приложенията бяха написани на Python, C #, C, Vala, всичко. Нямаше ръководство за стил на код. Кодът ни беше много разхвърлян и не много последователен. Gtk2 беше нещо. И също така да рисувате нещата на ръка в Кайро. Това беше ерата на „лентовата лента и телената лента“ на елементарното разработване на приложения.

0,1 Юпитер, най-добре гледан с тази съпътстваща оценка

По време на пътуването ни до срещата на върха на разработчиците на Ubuntu през 2011 г., след като хвърлихме някои от нашите нови приложения към екипа на работния плот на Ubuntu, седнахме с разработчика на Unity Джейсън Смит, който ни предаде твърда истина: не бяхме голям магазин за кодове и трябваше да променим начина на работа.

Ген II

Ние направихме много труден избор по време на развитието на Luna и някои от тях ни костваха ценни сътрудници. Двете най-големи промени бяха стандартизиране на Vala и въвеждане на прегледи на кодове.

Изборът на стандартен език наистина беше вратата към повишаване на нашите стандарти. Това направи много по-лесно за всеки, който работи върху едно приложение, да може лесно да допринесе за друго приложение и ни позволи да създадем едно ръководство за стил на кода, с което всеки може да се запознае. По-късно това ще ни позволи да напишем всеобхватни програми за разработчици и да даде на трети страни ясен път към доставката на техните приложения на елементарни потребители на ОС. Избрахме и стандартна система за изграждане с CMake по подобни причини.

Въвеждането на прегледи на кодове беше много по-трудна задача. За разлика от съвременни инструменти като GitHub, нашата платформа за хостинг на кодове на Yore, Launchpad, нямаше родна концепция за рецензии. Започнахме да използваме бот, наречен Tarmac, който разработчиците на Canonical бяха започнали да използват. Това беше бавно и болезнено и някои разработчици го приеха наистина лично, че искахме техният код да бъде проверен, преди да може да кацне в багажника на разработката.

Файлове с Gtk + HeaderBar в 0,3 Freya

Започвайки в Луна, но в цяла Фрея и дори в Локи, се стремяхме към чист Gtk3 десктоп и наистина съм горд да кажа, че приключихме прехода си преди много други проекти дори да са започнали своя. Прегърнахме и внедрихме HeaderBars навсякъде, дори на места, където все още не е имало GNOME. Gtk3 също ни позволи да създадем по-сложни, персонализирани стилове с CSS и да въведем по-добра типография в нашите приложения с много по-фин зърнен контрол над височината и теглата на шрифта.

Представихме и нова библиотека, наречена Granite, за да споделяме общ код в проектите и да разширим нещата, които получихме от Gtk +. Много от приспособленията, които изградихме, в крайна сметка ще бъдат заменени от реализации в самия Gtk +, включително HeaderBars, Popovers и други. Въпреки че Granite продължава да се усъвършенства и се добавят нови функции и джунджурии, ние също сме много развълнувани, когато можем да оттеглим класовете като Gtk + придобива функции.

Gen II беше дълъг и добър и донесе много голям напредък в начина, по който изграждахме приложения. Беше време на постепенна промяна без много големи разстройства, откакто направихме тези трудни избори в Луна. Време е да разтърсиш нещата.

Ген III

С най-новото поколение направихме няколко големи промени с целта да улесним участието на новите сътрудници и старите сътрудници да поддържат зрели кодови бази.

Една от най-големите от тях е напълно обхващането на обратна нотация на имена на имена (RDNN). Поради дългата ни история, новите сътрудници могат да открият, че когато например клонират елементарни / файлове, двоичното име на проекта е пантеон-файлове, .desktop се нарича org.pantheon.files, а настройките се съхраняват в мрежа. launchpad.marlin. Когато цялото именуване е базирано на RDNN, новите сътрудници лесно могат да предвидят, че имената на двоични файлове, .desktops, GSettings пътища и т.н. винаги ще бъдат например io.elementar.files. Това също гарантира, че нямаме конфликти при именуване на файлове с пакети от нашите upstreams като Debian или Ubuntu. Можете да прочетете повече за това в предишната статия на Cassidy, „Почистване на кодови имена на приложения“.

Визуално представяне на това как се чувства ген III под капака

Ние също така настояваме да имаме последователна структура на директорията на дърво на източник със стандартни файлове като Application.vala в директорията src, която съдържа класа на приложението (представете си това!), Очакване, че можете да намерите .desktops и appdata.xml в данните директория и т.н. Това улеснява разработчиците, работещи по множество проекти, бързо да намерят общи файлове в проектите.

Приложенията от Gen III също използват GResources за персонализирани активи като икони, изображения и CSS, вместо да инсталират файлове във файловата система. Това е важно както за да се гарантира, че тези активи не причиняват конфликти при опаковане, ако са инсталирани в системна директория като директорията с икони на hicolor, както и за намаляване на IO грешките и повишаване на производителността.

Отляво: Lingo a app I Gen | Вдясно: Palaura приложение III

Също така ще забележите много приложения от Gen III, които използват много по-всеобхватно Gtk.CSS за предоставяне на брандиране, включително неща като по-стилизирани шрифтове и цветни HeaderBars. Можете да прочетете повече за някои от инструментите, достъпни за разработчиците тук, в най-новата ни статия за съвети за програмисти.

Миналата година говорихме за възприемане на нови стандарти за метаданни под формата на AppStream и изтръпване на диалозите „About“. Ще продължим по този път и понастоящем изследваме нови стандарти като OARS, които биха позволили нови форми на родителски контрол и гарантират, че потребителите ще имат по-голям контрол върху вида съдържание, което се използва на техните устройства.

Направихме също така напредък в изграждането на всички наши приложения с Meson и допринесохме пачове нагоре за по-добра поддръжка и инструменти за локализация на Vala. Можете да прочетете повече за това тук.

Не на последно място, но не на последно място, използвахме много по-всеобхватно автоматизирано тестване под формата на Travis CI на GitHub и Flightcheck, нашето решение за тестване за табло за управление на AppCenter. Непрекъснатото тестване в допълнение към прегледа на кода ни помага да поддържаме високо качество и метаданни и да избягваме въвеждането на регресии. В момента тестваме непрекъсната версия на Flightcheck, за да улесним всеки да изпълнява пълния набор от елементарно поддържани тестове с Travis. Повече за това скоро.

Надяваме се също така да доставим повече инструменти и по-добра документация през целия цикъл Juno, така че следете тук нашия блог за повече информация за това как вие също можете да доставяте убийствени приложения с отворен код.

Благодарим отново на всички разработчици, които правят приложения за AppCenter, на всички, които са закупили приложение в AppCenter, на нашите поддръжници в Bountysource и Patreon и на тези, които са закупили копие на елементарна ОС или мерч от нашия магазин. Всеки принос помага да се направи всичко това възможно и ние не бихме били тук без вас! Ако искате да помогнете за подобряване на елементарната ОС, не се колебайте да се включите!