Autor de amigos aqui.
De fato, como você suspeitava, é necessário suporte nas Contas Online do Ubuntu antes que o suporte possa ser adicionado ao Friends. A arquitetura de amigos depende muito do UOA para fazer toda a autorização e gerenciar todas as chaves de API para nós. Meu exemplo favorito é o LinkedIn, porque até agora é o único protocolo que contribuiu com a comunidade. O plug-in UOA é composto principalmente por apenas dois arquivos XML, além de um pouco de truque de autoconf, que se parece com isso. (role um pouco para o diff, que mostra claramente tudo o que precisava ser adicionado para o LinkedIn funcionar).
Depois de fazer o mesmo para o seu protocolo, você precisará propor a mesclagem com os plug-ins lp: account e solicitar à Mardy que os revise, aprove e mescle. Uma vez instalado, você pode começar a escrever o plugin friends, que será escrito em Python 3.
Agora, um dos principais aprimoramentos que o Friends apresenta sobre o Gwibber é o uso de subclasses. No código original do Gwibber, absolutamente nada foi feito com as subclasses; portanto, cada novo plug-in de protocolo era um imenso hackjob de copiar e colar de vários bits de funcionalidade de baixo nível. Ao implementar o Friends, tomei muito cuidado para extrair a funcionalidade comum em uma superclasse, que pode ser facilmente subclassificada e modificada. A superclasse também possui várias doutrinas, às quais você deve se referir ao iniciar. Infelizmente, ainda não configuramos o sphinx para publicá-los em nenhum lugar; portanto, basta ler o código por enquanto.
Algumas coisas importantes a ter em mente é que o nome da sua classe deve corresponder ao "nome de usuário" usado, sem distinção entre maiúsculas e minúsculas. Portanto, se você definiu o nome do instagramusuário, deve criar o arquivo protocols/instagram.pye nomear sua classe Python Instagram.
Os dois métodos mais importantes que você absolutamente precisa implementar para que seu plug-in realmente faça qualquer coisa são chamados _whoamie receive. Eles estão bem documentados em base.py (link acima), mas basicamente o _whoamimétodo será chamado automaticamente e transmitido em um ditado que representa um blob JSON já analisado que nos foi fornecido pelo serviço quando a autenticação ocorreu. Se você tiver sorte, esse ditado conterá seu nome de usuário, ID de usuário e nome de exibição do Instagram, mas, caso contrário, será necessário fazer uma chamada de API secundária para coletar essas informações. Consulte Facebook._whoamium exemplo de protocolo que não forneceu as informações antecipadamente e exigiu uma chamada de API adicional de dentro do método. ConsulteTwitter._whoami para um exemplo de protocolo que nos forneceu todos os detalhes que precisávamos desde o início.
Posteriormente, o receivemétodo é responsável por fazer a chamada da API que consulta o serviço em busca de novas mensagens. Este é um pouco mais de forma livre, porque cada API REST é um pouco diferente, portanto, você deve consultar os documentos da API do site para descobrir o que exatamente precisa ser feito aqui. Em http.py nós fornecemos Uploadere Downloaderclasses que tornam mais fácil para fazer chamadas de API REST, e pode até mesmo de análise respostas do servidor JSON para você. É importante usar essas classes de conveniência, porque elas são agrupadas libsoup, configuradas para respeitar as configurações de proxy do GNOME (você deve se lembrar de quão terrível o suporte a proxy do Gwibber sempre foi, bem, nós corrigimos tudo isso agora).
Depois de obter a resposta da API do servidor, é necessário armazená-la em nosso DeeModel (onde o Gwibber usou um blob JSON despejado em um banco de dados sqlite para armazenar suas mensagens, estamos usando um DeeModel, que é basicamente apenas um banco de dados que compartilha o estado no DBus, facilitando a exibição de dados da mensagem com facilidade por vários clientes). Chamamos o ato de armazenar uma nova mensagem "publicação" e fornecemos um método de conveniência para ela em Base._publish. Basicamente, tudo o que você precisa fazer é preencher os espaços em branco aqui, verifique se o máximo de informações possível é preenchido no maior número possível de colunas. Os possíveis argumentos para _publish estão definidos no esquema e, novamente, você pode consultar os plug-ins existentes para ver como eles o fazem.
Depois de chegar tão longe, você deve ter o suficiente para poder testá-lo. Nós fornecemos algumas ferramentas no toolsdiretório para facilitar a execução do código na árvore de origem, para que você não precise instalá-lo no sistema toda vez que quiser fazer uma alteração. O que você deve fazer é abrir um terminal, fazer o cd na raiz da árvore de origem e executar ./tools/debug_slave.py. O que isso faz é conectar-se ao DeeModel e apenas exibir tudo o que acontece, para que você possa ver as mensagens aparecendo ao vivo à medida que entram. Em seguida, em um segundo terminal, faça o cd para a raiz da árvore de origem e execute ./tools/debug_live.py instagram receivee que acionará manualmente o método Instagram.receive e exibirá vários resultados de depuração para informar sobre o que está acontecendo enquanto ele é executado (você pode polvilhar seu código com chamadas paralog.debug("hi") se você quiser ver ainda mais detalhes sobre o que acontece).
Ah, e se você ainda está lendo, o plugin do linkedin ainda não chegou ao baú, mas ainda pode dar uma olhada aqui.
Se você tiver outras perguntas, eu sempre estou no #gwibber no freenode e também sinto que a nova base de código é muito mais legível e melhor documentada do que qualquer outra coisa que o Gwibber já teve, então leia o código que está lá e não deveria ' não é muito difícil aprender pelo exemplo. Facebook e Twitter são os mais completos.
Obrigado pelo seu interesse em amigos!