Opbygning af den næste generation af apps

Platform forbedringer og mål for Juno

I lidt over 7 år nu har elementæret til hensigt at bringe dræber-apps til Open Source-desktops. I løbet af Juno-udviklingscyklus har vi arbejdet hårdt for at levere vores vision om disse apps, men ikke alt det arbejde, vi har udført, er synligt for den afslappede bruger. I dette indlæg taler jeg om lidt historie omkring, hvordan vi sætter tingene sammen under hætten, og hvordan den nye normale ser ud for elementære apps. Spænd dine dev-hjelme, og lad os blive nørdige.

Gen I

Vi leverede den allerførste version af elementær OS med vores bedste skud på at udvikle overbevisende Open Source-apps. Vi havde intet standardsprog. Apps blev skrevet i Python, C #, C, Vala, hvad som helst. Der var ingen guide til kodestil. Vores kode var meget rodet og ikke særlig konsistent. Gtk2 var en ting. Og også tegne ting for hånd i Kairo. Det var "duct tape and bailing wire" æraen med elementær appudvikling.

0,1 Jupiter, bedst set med denne ledsagende score

Under vores tur til Ubuntu Developer Summit langt tilbage i 2011 efter at have kastet nogle af vores nye apps til Ubuntu Desktop Team, satte vi os sammen med Unity-udvikler Jason Smith, der leverede en hård sandhed til os: Vi var ikke en fantastisk kodebutik og vi var nødt til at ændre den måde, vi arbejdede på.

Gen II

Vi tog mange hårde valg under udviklingen af ​​Luna, og nogle af dem koster os værdifulde bidragydere. De to største ændringer var standardisering af Vala og introduktion af kodevurderinger.

At vælge et standardsprog var virkelig porten til at hæve vores standarder. Dette gjorde det meget lettere for alle, der arbejdede på en app, at være i stand til let at bidrage til en anden app, og det gjorde det muligt for os at oprette en enkelt kodestilguide, som alle kunne blive bekendt med. Senere vil det give os mulighed for at skrive omfattende udviklerdokumenter og give tredjepart en klar sti til levering af deres apps til elementære OS-brugere. Vi valgte også et standard build-system med CMake af lignende grunde.

Det var en meget vanskeligere opgave at introducere kodevurderinger. I modsætning til moderne værktøjer som GitHub, havde vores kodehostingsplatform fra yore, Launchpad, ikke noget oprindeligt koncept med anmeldelser. Vi begyndte at bruge en bot kaldet Tarmac, som var det, udviklere hos Canonical var begyndt at bruge. Det var langsomt og smertefuldt, og nogle udviklere tog det virkelig personligt, at vi ønskede, at deres kode blev peer review, før den kunne lande i udviklingsstammen.

Filer med en Gtk + HeaderBar i 0,3 Freya

Fra Luna, men i hele Freya og endda i Loki, stræbte vi efter et rent Gtk3-skrivebord, og jeg er virkelig stolt over at sige, at vi afsluttede vores overgang, før mange andre projekter endda var begyndt på deres. Vi omfavnede og implementerede HeaderBars overalt, selv på steder, hvor GNOME endnu ikke har gjort det. Gtk3 gjorde det også muligt for os at oprette mere komplekse, tilpassede stilarter med CSS og introducere bedre typografi i vores apps med meget finere kornet kontrol over fonthøjder og -vægte.

Vi introducerede også et nyt bibliotek kaldet Granite til at dele fælles kode på tværs af projekter og udvide de ting, vi fik fra Gtk +. Mange af de widgets, vi har bygget, ville til sidst blive erstattet af implementeringer i selve Gtk + inklusive HeaderBars, Popovers og mere. Mens granit fortsat forbedres og nye funktioner og widgets tilføjes, er vi også meget glade for, når vi kan afskrive klasser, da Gtk + får funktioner.

Gen II var lang og god, og det bragte en masse store fremskridt til den måde, vi byggede apps på. Det har været en tid med gradvis forandring uden for mange store forstyrrelser, da vi tog de svære valg i Luna. Tid til at ryste tingene op.

Gen III

Med den nyeste generation har vi foretaget flere store ændringer med det mål at gøre det meget lettere for nye bidragydere at blive involveret og for gamle bidragydere at opretholde modne kodebaser.

En af de største er fuldt ud at omfatte omvendt domænenavnsnotation (RDNN). På grund af vores lange historie, kan nye bidragydere muligvis opleve, at når de for eksempel kloner elementær / filer, er projektets binære navn pantheon-filer, kaldes .desktop org.pantheon.files, og indstillingerne gemmes på nettet. launchpad.marlin. Når al navngivning er RDNN-baseret, kan nye bidragydere let forudsige, at navnene på binære filer, .desktops, GSettings-stier osv. Altid vil være for eksempel io.elementary.files. Dette garanterer også, at vi ikke har filnavnkonflikter med pakker fra vores opstrømme som Debian eller Ubuntu. Du kan læse mere om det i Cassidys forrige artikel, "Oprydning af app-kodenavne".

En visuel gengivelse af, hvordan Gen III føles under hætten

Vi skubber også til at have en konsistent kildetræ-mappestruktur med standardfiler som Application.vala i src-biblioteket, der indeholder applikationsklassen (forestil dig det!), En forventning om, at du kan finde .desktops og appdata.xml i dataene katalog osv. Dette gør det lettere for udviklere, der arbejder på flere projekter, hurtigt at finde almindelige filer på tværs af projekter.

Gen III-apps bruger også GResources til brugerdefinerede aktiver som ikoner, billeder og CSS i stedet for at installere filer til filsystemet. Dette er vigtigt både for at sikre, at disse aktiver ikke forårsager emballagekonflikter, hvis de er installeret i et systemmappe som hicolor-ikon-biblioteket og for at reducere IO-fejl og øge ydelsen.

Til venstre: Lingo a Gen I app | Til højre: Palaura a Gen III-app

Du vil også bemærke mange Gen III-apps, der bruger meget mere omfattende brug af Gtk.CSS til at levere branding, herunder ting som mere stiliserede skrifttyper og farvede HeaderBars. Du kan læse mere om nogle af de værktøjer, der er tilgængelige for udviklere her i vores nyeste artikel om udviklertips.

Vi talte sidste år om at omfavne nye metadatastandarder i form af AppStream og grøfte “About” -dialogbokse. Vi fortsætter ad denne vej og undersøger i øjeblikket nye standarder som OARS, som tillader nye former for forældrekontrol og sikrer, at brugerne har mere kontrol over den slags indhold, der forbruges på deres enheder.

Vi har også gjort en masse fremskridt med at opbygge alle vores apps med Meson og har bidraget med programrettelser opstrøms for bedre Vala support og lokaliseringsværktøjer. Du kan læse mere om det her.

Sidst, men ikke mindst, har vi gjort meget mere omfattende brug af automatiseret test i form af Travis CI på GitHub og Flightcheck, vores testløsning til AppCenter Dashboard. Kontinuerlig test ud over kodegennemgang hjælper os med at holde kode- og metadatakvalitet høj og undgå at indføre regressioner. I øjeblikket tester vi en kontinuerlig version af Flightcheck for at gøre det lettere for alle at køre den fulde pakke elementært vedligeholdte tests med Travis. Mere om det snart.

Vi håber også at kunne levere flere værktøjer og bedre dokumentation i hele Juno-cyklussen, så hold os afstemt her til vores blog for at få mere information om, hvordan du også kan levere dræber Open Source-apps.

Tak igen til alle udviklere, der laver apps til AppCenter, alle, der har købt en app på AppCenter, vores tilhængere på Bountysource og Patreon, og dem, der har købt en kopi af elementært OS eller merch fra vores butik. Ethvert bidrag hjælper med at gøre alt dette muligt, og vi ville ikke være her uden dig! Hvis du gerne vil hjælpe med at forbedre det elementære OS, skal du ikke tøve med at blive involveret!