Construindo a próxima geração de aplicativos
Melhorias na plataforma e metas para Juno
Por um pouco mais de 7 anos, o elementary começou a trazer aplicativos matadores para os desktops do Open Source. Durante o ciclo de desenvolvimento do Juno, trabalhamos arduamente para oferecer a visão desses aplicativos, mas nem todo o trabalho que fizemos é visível para o usuário casual. Neste post, falarei sobre um pouco da história em torno de como colocamos as coisas sob o capô e como é a aparência da nova normal para aplicativos elementary. Amarre seus capacetes de desenvolvimento e vamos ficar nerds.
Gen I
Nós entregamos a primeira versão do sistema operacional elementary com a nossa melhor chance de desenvolver aplicativos Open Source atraentes. Não tínhamos uma linguagem padrão. Aplicativos foram escritos em Python, C#, C, Vala, qualquer coisa. Não havia nenhum guia de estilo de código. Nosso código era muito confuso e não muito consistente. Gtk2 era uma coisa. E também desenhar coisas à mão no Cairo. Foi a era do “duto de fita adesiva e de fiança” do desenvolvimento de aplicativos no elementary.
Durante nossa viagem ao Ubuntu Developer Summit em 2011, após lançar alguns de nossos novos aplicativos para a Equipe do Ubuntu Desktop, nos reunimos com Jason Smith, um desenvolvedor da Unity, que nos deu uma dura verdade: não éramos uma grande loja de códigos e nós precisávamos mudar a maneira como trabalhamos.
Gen II
Fizemos muitas escolhas difíceis durante o desenvolvimento de Luna e algumas delas nos custaram valiosos contribuintes. As duas maiores mudanças foram padronizar o Vala e introduzir revisões de código.
Escolher uma linguagem padrão foi realmente a porta de entrada para elevar nossos padrões. Isso tornou muito mais fácil para qualquer pessoa que trabalha em um aplicativo poder contribuir facilmente para outro aplicativo e nos permitiu criar um único guia de estilo de código com o qual todos poderiam se familiarizar. Mais tarde, permitir-nos-ia escrever documentos de desenvolvimento abrangentes e dar a terceiros um caminho claro para entregar as suas aplicações aos utilizadores elementary do SO. Também escolhemos um sistema de compilação padrão com o CMake por motivos semelhantes.
Introduzir revisões de código era uma tarefa muito mais árdua. Ao contrário das ferramentas modernas como o GitHub, nossa plataforma de hospedagem de código, a Launchpad, não tinha nenhum conceito nativo de revisões. Começamos a usar um bot chamado Tarmac, que era o que os desenvolvedores da Canonical começaram a usar. Foi lento e doloroso, e alguns desenvolvedores entenderam pessoalmente que queríamos que o código deles fosse revisado por pares antes que pudesse ser lançado no tronco de desenvolvimento.
Começando em Luna, mas ao longo de Freya e até mesmo em Loki, nós nos esforçamos para um desktop Gtk3 puro e eu estou realmente orgulhoso de dizer que terminamos nossa transição antes mesmo de muitos outros projetos terem começado. Nós adotamos e implementamos o HeaderBars em todos os lugares, mesmo em lugares onde o GNOME ainda não existe. O Gtk3 também nos permitiu criar estilos mais complexos e personalizados com CSS e introduzir uma melhor tipografia em nossos aplicativos com um controle mais refinado sobre as alturas e os pesos das fontes.
Também introduzimos uma nova biblioteca chamada Granite para compartilhar código comum entre projetos e estender as coisas que obtivemos do Gtk+. Muitos dos widgets que construímos seriam eventualmente substituídos por implementações no próprio Gtk+, incluindo HeaderBars, Popovers e muito mais. Enquanto o Granite continua a ser melhorado e novas funções e widgets são adicionados, também estamos muito animados quando podemos descontinuar as classes à medida que o Gtk+ ganha recursos.
A segunda geração foi longa e boa e trouxe muitos grandes avanços à maneira como construímos aplicativos. Tem sido uma época de mudanças graduais sem muitos problemas importantes desde que fizemos essas difíceis escolhas em Luna. Hora de agitar as coisas.
Gen III
Com a mais nova geração, fizemos várias grandes alterações com o objetivo de facilitar o envolvimento de novos colaboradores e de os antigos contribuidores manterem bases de código maduras.
Um dos maiores é abraçar completamente a notação de nome de domínio reverso (RDNN). Devido à nossa longa história, novos colaboradores podem descobrir que, quando, por exemplo, clonar elementary/fileso nome binário do projeto pantheon-files, o .desktop é chamado org.pantheon.filese as configurações são armazenadas em net.launchpad.marlin. Quando todos os nomes são baseados em RDNN, novos contribuidores podem facilmente prever que os nomes de binários, .desktops, caminhos de GSettings, etc sempre serão, por exemplo io.elementary.files. Isso também garante que não temos conflitos de nomenclatura de arquivos com pacotes de nossos upstreams como Debian ou Ubuntu. Você pode ler mais sobre isso no artigo anterior de Cassidy, “ Limpando nomes de aplicativos ”.
Também estamos insistindo em ter uma estrutura de diretório de árvore fonte consistente com arquivos padrão, como Application.valano srcdiretório que contém a classe Application (imagine isso!), Uma expectativa de que você pode encontrar .desktops e appdata.xml no datadiretório, etc. torna mais fácil para os desenvolvedores que trabalham em vários projetos encontrar rapidamente arquivos comuns entre os projetos.
Aplicativos Gen III também fazem uso de GResources para ativos personalizados, como ícones, imagens e CSS, em vez de instalar arquivos no sistema de arquivos. Isso é importante para garantir que esses ativos não causem conflitos de empacotamento se instalados em um diretório do sistema, como o diretório do ícone hicolor e para reduzir erros de E/S e aumentar o desempenho.
Você também notará muitos aplicativos Gen III fazendo uso muito mais abrangente do Gtk.CSS para fornecer branding, incluindo coisas como tipos de letra mais estilizados e HeaderBars coloridos. Você pode ler mais sobre algumas das ferramentas disponíveis para desenvolvedores no nosso artigo mais recente sobre dicas para desenvolvedores.
Nós conversamos no ano passado sobre a adoção de novos padrões de metadados na forma de AppStream e abandonando as caixas de diálogo “Sobre”. Continuaremos nesse caminho e estamos investigando novos padrões, como o OARS, que permitiria novas formas de Controles dos Pais e garantir que os usuários tenham mais controle sobre o tipo de conteúdo que é consumido em seus dispositivos.
Também fizemos muito progresso na criação de todos os nossos aplicativos com o Meson e contribuímos com upstream de patches para obter melhores ferramentas de suporte e localização da Vala. Você pode ler mais sobre isso aqui .
Por último, mas não menos importante, fizemos um uso muito mais abrangente de testes automatizados na forma do Travis CI no GitHub e no Flightcheck, nossa solução de testes para o AppCenter Dashboard. Testes contínuos, além da revisão de código, nos ajudam a manter alta a qualidade do código e dos metadados e evitar a introdução de regressões. No momento, estamos testando uma versão contínua do Flightcheck para facilitar a execução de todo o conjunto de testes mantidos pelo elementary com o Travis. Mais sobre isso em breve.
Também esperamos entregar mais ferramentas e melhor documentação ao longo do ciclo Juno, portanto, fique atento aqui ao nosso blog para obter mais informações sobre como você também pode entregar aplicativos open source incríveis.
Gostariamos de agradecer a todos que compraram algum aplicativo no AppCenter, nos ajudaram via Bountysource ou Patreon, ou também aqueles que compraram uma copia do elementary OS ou produtos da nossa loja. Toda contribuição nos ajuda a tornar tudo isso possível, e não estaríamos aqui sem vocês! Se você gostaria de nos ajudar a melhorar o elementary OS, não hesite emSe Envolver!
Tradução do medium do elementary OS
