Costruire la prossima generazione di app

Miglioramenti della piattaforma e obiettivi per Juno

Da poco più di 7 anni, elementare ha deciso di portare app killer sui desktop Open Source. Durante il ciclo di sviluppo di Juno abbiamo lavorato duramente per fornire la nostra visione di quelle app, ma non tutto il lavoro che abbiamo fatto è visibile all'utente occasionale. In questo post parlerò di un po 'di storia che circonda il modo in cui mettiamo insieme le cose sotto il cofano e come appare la nuova normalità per le app elementari. Allacciati i caschi degli sviluppatori e diventiamo geek.

Gen I.

Abbiamo fornito la primissima versione del sistema operativo elementare con il nostro miglior obiettivo nello sviluppo di app Open Source accattivanti. Non avevamo un linguaggio standard. Le app sono state scritte in Python, C #, C, Vala, qualsiasi cosa. Non c'era una guida allo stile del codice. Il nostro codice era molto disordinato e non molto coerente. Gtk2 era una cosa. E anche disegnare le cose a mano al Cairo. Era l'era del "nastro isolante e del filo di cauzione" dello sviluppo di app elementari.

0.1 Giove, meglio visto con questo punteggio accompagnatorio

Durante il nostro viaggio al Summit degli sviluppatori di Ubuntu nel 2011, dopo aver presentato alcune delle nostre nuove app al Ubuntu Desktop Team, ci siamo seduti con lo sviluppatore Unity Jason Smith che ci ha fornito una dura verità: non eravamo un grande negozio di codici e dovevamo cambiare il modo in cui lavoravamo.

Gen II

Abbiamo fatto molte scelte difficili durante lo sviluppo di Luna e alcuni di loro ci sono costati preziosi collaboratori. Le due maggiori modifiche sono state la standardizzazione di Vala e l'introduzione di revisioni del codice.

Scegliere una lingua standard è stato davvero il gateway per innalzare i nostri standard. Ciò ha reso molto più facile per chiunque lavori su un'app poter contribuire facilmente a un'altra app e ci ha permesso di creare una guida di stile a codice unico con cui tutti potevano familiarizzare. In seguito ci consentirebbe di scrivere documenti per sviluppatori completi e fornire a terze parti un chiaro percorso per consegnare le loro app agli utenti di sistemi operativi elementari. Abbiamo anche scelto un sistema di build standard con CMake per motivi simili.

L'introduzione delle revisioni del codice è stata un'attività molto più ardua. A differenza di strumenti moderni come GitHub, la nostra piattaforma di hosting di codice di un tempo, Launchpad, non aveva alcun concetto nativo di recensioni. Abbiamo iniziato a utilizzare un bot chiamato Tarmac che era quello che gli sviluppatori di Canonical avevano iniziato a utilizzare. È stato lento e doloroso e alcuni sviluppatori hanno preso sul serio il fatto che volevamo che il loro codice fosse sottoposto a peer review prima che potesse atterrare nel bagagliaio di sviluppo.

File con Gtk + HeaderBar in 0.3 Freya

A partire da Luna, ma in Freya e persino in Loki, ci siamo battuti per un desktop Gtk3 puro e sono davvero orgoglioso di dire che abbiamo terminato la nostra transizione prima che molti altri progetti avessero addirittura avviato il loro. Abbiamo abbracciato e implementato HeaderBars su tutta la linea, anche in luoghi dove GNOME non lo ha ancora fatto. Gtk3 ci ha anche permesso di creare stili più complessi e personalizzati con CSS e di introdurre una migliore tipografia nelle nostre app con un controllo molto più preciso sulle altezze e sui pesi dei caratteri.

Abbiamo anche introdotto una nuova libreria chiamata Granite per condividere codice comune tra progetti ed estendere ciò che abbiamo ottenuto da Gtk +. Molti dei widget che abbiamo creato sarebbero stati sostituiti da implementazioni in Gtk +, inclusi HeaderBars, Popovers e altro. Mentre Granite continua a essere migliorato e vengono aggiunte nuove funzioni e widget, siamo anche molto entusiasti di poter deprecare le classi quando Gtk + acquisisce funzionalità.

La seconda generazione è stata lunga e buona e ha portato molti grandi progressi nel modo in cui abbiamo creato le app. È stato un momento di cambiamento graduale senza troppi sconvolgimenti da quando abbiamo fatto queste difficili scelte in Luna. È ora di scuotere le cose.

III generazione

Con la generazione più recente, abbiamo apportato numerose modifiche di grandi dimensioni con l'obiettivo di rendere molto più semplice il coinvolgimento di nuovi collaboratori e di mantenere la base di codice matura per i vecchi collaboratori.

Uno dei più grandi sta abbracciando completamente Reverse Domain Name Notation (RDNN). A causa della nostra lunga storia, i nuovi contributori potrebbero scoprire che quando, ad esempio, clonano elementari / file il nome binario del progetto è file pantheon, il .desktop si chiama org.pantheon.files e le impostazioni vengono archiviate in rete. launchpad.marlin. Quando tutta la denominazione è basata su RDNN, i nuovi contributori possono facilmente prevedere che i nomi di binari, .desktops, percorsi GSettings, ecc. Saranno sempre, ad esempio, io.elementary.files. Ciò garantisce anche che non abbiamo conflitti di denominazione dei file con i pacchetti dei nostri upstream come Debian o Ubuntu. Puoi leggere ulteriori informazioni al riguardo nel precedente articolo di Cassidy, "Pulizia dei nomi in codice delle app".

Una rappresentazione visiva di come si sente la Gen III sotto il cofano

Stiamo anche spingendo per avere una struttura di directory dell'albero dei sorgenti coerente con file standard come Application.vala nella directory src che contiene la classe Application (immaginalo!), Un'aspettativa che puoi trovare .desktops e appdata.xml nei dati directory, ecc. Ciò rende più semplice per gli sviluppatori che lavorano su più progetti trovare rapidamente file comuni in tutti i progetti.

Le app di terza generazione utilizzano anche GResource per risorse personalizzate come icone, immagini e CSS invece di installare file nel filesystem. Questo è importante sia per garantire che tali risorse non causino conflitti di packaging se installati in una directory di sistema come la directory delle icone bicolore, sia per ridurre gli errori di I / O e aumentare le prestazioni.

A sinistra: app Lingo a Gen I | A destra: Palaura a Gen III app

Noterai anche molte app di terza generazione che fanno un uso molto più completo di Gtk.CSS per fornire il marchio, inclusi elementi come caratteri tipografici più stilizzati e barre colorate. Puoi leggere ulteriori informazioni su alcuni degli strumenti disponibili per gli sviluppatori qui nel nostro più recente articolo Suggerimenti per gli sviluppatori.

L'anno scorso abbiamo parlato di abbracciare nuovi standard di metadati sotto forma di AppStream e di abbandonare le finestre di dialogo "Informazioni". Continueremo su questa strada e stiamo attualmente studiando nuovi standard come OARS che consentirebbero nuove forme di controllo parentale e assicurerebbero agli utenti un maggiore controllo sul tipo di contenuto che viene consumato sui loro dispositivi.

Abbiamo anche fatto molti progressi nella creazione di tutte le nostre app con Meson e abbiamo contribuito con patch a monte per un migliore supporto Vala e strumenti di localizzazione. Puoi leggere altro a questo proposito qui.

Infine, ma non meno importante, abbiamo fatto un uso molto più completo dei test automatizzati sotto forma di Travis CI su GitHub e Flightcheck, la nostra soluzione di test per AppCenter Dashboard. Test continui oltre alla revisione del codice ci aiutano a mantenere alta la qualità del codice e dei metadati ed evitare l'introduzione di regressioni. Al momento, stiamo testando una versione continua di Flightcheck per rendere più semplice per chiunque eseguire la suite completa di test elementari con Travis. Ne parleremo presto.

Speriamo anche di fornire più strumenti e una migliore documentazione durante tutto il ciclo di Juno, quindi rimanete sintonizzati qui sul nostro blog per ulteriori informazioni su come anche voi potete fornire app Open Source killer.

Grazie ancora a tutti gli sviluppatori che creano app per AppCenter, a tutti coloro che hanno acquistato un'app su AppCenter, ai nostri sostenitori su Bountysource e Patreon e a coloro che hanno acquistato una copia del sistema operativo elementare o merch dal nostro negozio. Ogni contributo aiuta a rendere tutto ciò possibile e non saremmo qui senza di te! Se desideri contribuire a migliorare il sistema operativo elementare, non esitare a partecipare!