Nos últimos meses e talvez até anos, o Ubuntu e a Canonical foram frequentemente criticados por desenvolver componentes de software e desktop sem falar com outros grupos na comunidade de software livre. Eu não quero comentar sobre este tópico, mas vejo problemas surgindo com a criação de uma solução "proprietária" para exibir indicadores e barras de progresso com um iniciador como o Unity.
No mundo dos ambientes de desktop abertos e gratuitos, muitas vezes tentamos padronizar peças e bibliotecas ou escrever especificações para aumentar a colaboração entre diferentes desktops. Temos o instrumento do link e muitas especificações estão sendo implementadas pelos principais ambientes de desktop.
Nesse contexto, propor um padrão para esses indicadores seria um grande passo para uma melhor interoperabilidade entre os desktops.
Esses indicadores representam um ótimo recurso no Linux Desktop e tenho certeza de que outros projetos como o AWN, o Docky etc. o captariam.
Com a grande participação de mercado do Ubuntu, a Canonical está em condições de propor isso como um padrão e incentivar projetos para implementá-lo.
Obrigado antecipadamente, Sebastian Billaudelle
Eu sou o gênio do mal por trás da libunidade, onde muitas dessas coisas serão implementadas: -)
Há um problema inerente com os padrões - ou seja, que são padrões :-) Se você os definir em pedra, você tem que ficar com eles se eles valerem o papel em que estão escritos. Se eles tiverem inconvenientes imprevistos ou problemas de design, você está com problemas. Você pode estender-e-abraçar ou fazer algo completamente diferente. Não importa o que você vai inflamar em algum lugar para sua escolha.
Para o Ubuntu, temos alguns ciclos muito rápidos para o desenvolvimento de recursos e se primeiro negociarmos um padrão no FDO e depois implementá-lo, simplesmente não teríamos como fornecer recursos no ritmo que estamos fazendo agora.
A abordagem que estamos adotando agora é principalmente tentar coisas na prática e, em seguida, quando nos sentimos realmente bem com algo, podemos redigi-los como padrões. Mas, se nos vermos mudando as especificações a cada ciclo, pode ser apenas desperdiçar o tempo de todos, se puxarmos as pessoas para as discussões de padronização, você não acha?
Então, em princípio, tenho certeza de que concordamos :-) O problema é como chegar lá sem prejudicar a experiência do usuário.
Outra maneira de ver isso é não obrigar necessariamente que um "padrão" seja a API DBus ou as especificações escritas. Uma biblioteca estável API + ABI é tão boa no meu livro. Então o padrão não é palavras legíveis por humanos, mas instruções binárias legíveis por máquina.
Desculpe pela longa resposta, mas é um assunto complicado: -)
Tags unity