Por que é difícil fazer um programa Java 'parecer nativo'?

A maioria dos aplicativos Java não tem a mesma aparência que os aplicativos C / C ++. O swing pode ter sido projetado propositadamente para ter uma aparência distinta, mas, com base no que li, o SWT, por exemplo, tentou 'parecer nativo' e não foi totalmente bem-sucedido.

Minha pergunta é:

Por que é difícil para os desenvolvedores da linguagem Java projetar um sistema de GUI que copia exatamente a aparência das GUIs nativas? O que há de diferente nas GUIs nativas? Não é apenas uma questão de criar botões que se pareçam com botões 'nativos'? Ou vai mais fundo que isso?

Não é apenas uma questão de criar botões que se pareçam com botões 'nativos'?

Bem - mais ou menos, para botões. Mas isso pode ser mais difícil do que você imagina. Atualmente, os gráficos usados ​​para representar os componentes da GUI não são tão simples quanto os bitmaps aleatórios que são esticados (já que não são muito bem dimensionados) - geralmente são gráficos baseados em vetores com muitos casos de canto programados neles ( portanto, quando o botão atinge a borda da tela, pode parecer um pouco diferente, por exemplo.) E, é claro, você precisará de gráficos diferentes quando um botão for clicado. Por motivos de direitos autorais, os desenvolvedores geralmente não podem simplesmente usar esses gráficos existentes, então eles precisam ser recriados - e, embora façam um bom trabalho na maioria das vezes, inevitavelmente algumas coisas são perdidas, dada a enorme variedade de componentes gráficos existentes.

Estou dizendo tudo isso com base no Swing, que é obviamente um kit de ferramentas da GUI leve e não nativo. Você mencionou especificamente que o SWT não parece nativo, o que é um pouco estranho, porque o SWT é nativo. É um kit de ferramentas que usa a JNI abaixo para chamar componentes nativos - portanto, se algo não parecer bem ali, não será por causa da aparência.

Há literalmente meia dúzia de kits de ferramentas que podem ser considerados "nativos" em algum sistema. Alguns deles têm conceitos ou recursos bastante exclusivos, e replicá-los em um kit de ferramentas de plataforma cruzada é entediante. A aparência de um aplicativo não é apenas determinada por uma "capa", mas também no layout e como ele se comporta. Algumas considerações:

• Em uma caixa de diálogo, de que lado o botão "OK" pertence - à esquerda ou à direita? Justo, vamos criar um diálogo separado para cada sistema.
• Como marcamos o botão padrão em uma tela? Tingimento de cores, fonte em negrito, ampliando o botão? É justo, vamos colocar isso em uma folha de estilo.
• No Windows, o conceito "Faixa de opções" é bastante nativo. Como isso seria traduzido para o Mac, onde a fita não é comum? É justo, vamos esquecer o layout exato do pixel e fornecer uma implementação de barra de ferramentas diferente para cada sistema.
• A barra de menus faz parte da janela (Windows, opcionalmente KDE) ou fica na parte superior da tela (Mac, Unity)? Justo, vamos escrever uma implementação diferente para cada sistema, pois já jogamos fora o layout exato de pixels
• Como as fontes são renderizadas? O mais nítido possível, ou suave e antialias? E qual fonte deve ser usada? Observe que fontes diferentes têm métricas diferentes; portanto, o mesmo parágrafo renderizado na mesma largura pode ter um número diferente de linhas, dependendo da fonte.
• O plano de fundo de uma janela é de uma única cor, imagem ou gradiente? Vamos colocar isso em uma folha de estilo também.
• Como são as barras de rolagem? Onde estão os botões - se houver algum? Qual a largura ou são reveladas apenas quando o ponteiro se move para uma determinada região?
• Como incorporamos outros esquemas de cores?
• O que é esperado ser arrastável? Onde são esperados os menus de contexto?

Esses problemas não podem ser resolvidos por meio de uma folha de estilo simples quando eles tocam no comportamento ou no layout geral do aplicativo. A única solução real é reescrever o aplicativo para cada sistema (ignorando os benefícios de plataforma cruzada do Java). A única solução realista é esquecer o layout exato do pixel e escrever em uma interface comum que abstraia sobre kits de ferramentas específicos do sistema. A solução adotada pela Swing é emular vários sistemas, que falham espetacularmente.

E existe a consistência entre plataformas, a ideia de que seu aplicativo pode ter a mesma aparência em todos os sistemas (geralmente escolhido por jogos, onde isso aumenta a imersão). Em aplicativos de desktop, isso é apenas irritante e quebra as expectativas do usuário.

Sim, isso vai mais fundo.

Criar um botão parecido com um botão do Windows ou OS X é fácil quando você está criando apenas esse botão. Mas o botão deve "se comportar" como os originais, o que pode não ser fácil: talvez exista mais espaço em uma versão disponível, mas não na outra, talvez a cor seja mais adequada ao seu design na versão para Windows, etc.

Isso ocorre quando você tem uma GUI inteira: um programa OS X apresenta seu conteúdo de maneira diferente de um programa Windows. Isso é quase impossível de capturar em uma GUI - você precisaria de duas GUIs, mas não há muitos aplicativos que fazem tanto barulho. Em vez disso, eles visam "parece bom na maioria dos sistemas" - isso ainda parece um pouco estranho, mas é utilizável e muito mais fácil de desenvolver.

Não é difícil criar um botão que se pareça com um botão OSX, Windows ou qualquer outro kit de ferramentas. Mas as diretrizes de interface do usuário para a maioria dos ambientes não são tão simples quanto os conceitos básicos de "é assim que um botão se parece". Existem muitas diferenças mais sutis, desde o espaçamento entre os elementos da interface do usuário até a ordem em que determinadas ações conhecidas devem aparecer em uma lista até a posição exata da caixa de diálogo Preferências / Opções no sistema de menus. Pode-se automatizar os casos mais comuns para interfaces de usuário muito simples, mas muitas, se não a maioria das tarefas da interface do usuário, exigem um toque muito mais refinado.

O SWT tentou automatizar isso até certo ponto e, mais uma vez, ele acertou em tarefas simples da interface do usuário. Mas não existe uma solução única para todos, e, quando as UIs se tornam mais complexas, os métodos básicos que ela usa começam a desmoronar. Geralmente, é possível trazê-lo de volta ao trabalho manual minucioso da interface do usuário, mas isso não é algo que a maioria dos programadores pode ou deseja fazer para todas as plataformas.

A abordagem de Swing para isso foi simplesmente evitar kits de ferramentas nativos sempre que possível. Não é nativo e nem tenta ser: em vez disso, tenta criar algo que parecerá (quase) o mesmo, não importa onde seja executado. Em vez de tentar (inutilmente) agradar a todos, ele tentou agradar a si mesmo e, embora tenha sido bem-sucedido, pode-se questionar a eficácia do resultado para a comunidade mais ampla de usuários.

Há uma troca entre esperar que seu aplicativo pareça o mais natural possível em todos os sistemas e esperar que seu aplicativo funcione da mesma maneira em cada sistema. Não existe uma escolha "certa".

Além disso, mesmo se você escolher o lado "aparência natural", convém proteger os usuários do seu kit de ferramentas gráficas contra "melhorias" nos componentes nativos subjacentes e na API, que podem interromper seu aplicativo inesperadamente.

É por isso que alguns desenvolvedores de kit de ferramentas da GUI preferem fornecer seus próprios componentes que imitam os nativos, mas fornecem sua própria implementação. Por outro lado, desenvolver um kit de ferramentas GUI funcionalmente completo é um esforço significativo e considerações econômicas podem levar a algumas arestas.

Observe que esse problema não é específico de Java, mas é enfrentado por todas as empresas que produzem kits de ferramentas independentes de plataforma.

É tudo devido à história.

A Sun desejou que todo software Java funcionasse da mesma maneira em todas as máquinas.

Para que o software “pareça nativo”, ele deve funcionar da mesma forma que outros softwares no sistema operacional fornecido.

A Sun fez tudo o que estava ao seu alcance para dificultar a criação de software Java integrado a um sistema operacional, pois qualquer integração com um sistema operacional faria o software funcionar de maneira diferente em cada sistema operacional.

Atualmente, pouquíssimos programadores Java se preocupam com nada além de software baseado em servidor da web.

A Sun matou o Java no desktop alterando todos os programadores que usavam os sistemas baseados em Java da Microsoft, fazendo com que qualquer programador que escolhesse Java nos primeiros dias parecesse ruim.

Qualquer pessoa que escreve um software de desktop que se preocupa com "parecer nativo" aprendeu há muito tempo a não usar Java e tem seus pontos de vista reforçados toda vez que usa qualquer software Oracle.

Portanto, atualmente, não há demanda para “parecer nativo” no software de desktop dos programadores Java.

nativeNa verdade, o que você pensa é que aplicativos nativos estão fazendo suas próprias coisas, enquanto kits de ferramentas como o SWT seguem os padrões publicados para a interface do usuário desse sistema operacional. O problema é que ninguém cria aplicativos seguindo esses padrões; portanto, quando você inicia um aplicativo Java. Parece não ser nativo. Como exemplo, quase todos os projetos da Microsoft (Office, Outlook etc.) não podem ser reproduzidos visualmente usando os controles padrão do Windows.

Vai ficar ainda pior, pois a Microsoft e a Apple adicionam recursos dinâmicos da interface do usuário às suas plataformas de sistema operacional. Permitir que os desenvolvedores criem / estilizem seus aplicativos da mesma maneira que os designs da web criam estilos para os sites.

O Java na plataforma Android está seguindo esse caminho. Tornando os elementos da interface do usuário para Android definidos em XML com estilos de skinnable.

Java nunca foi tão popular como plataforma de desktop. Como resultado, essas mudanças no setor não estão se propagando para os tempos de execução da área de trabalho. Simplesmente não há desenvolvedores suficientes dispostos a gastar tempo para corrigir o problema.

Qual sistema operacional você deseja que pareça "nativo" também?

Você simplesmente não pode ser nativo de todos eles 100% do tempo.

O SWT, etc., é a melhor abordagem de esforço para parecer o mais nativo possível para todos eles, quando você precisa alcançar algum compromisso .

E, de fato, esse compromisso começa a se tornar cada vez mais difícil de alcançar; não tanto por causa dos sistemas operacionais, mas por causa dos dispositivos de entrada. Para telas sensíveis ao toque, você realmente precisa criar um design diferente, porque não há um botão direito do mouse. Portanto, você precisa acomodar a mesma funcionalidade caso contrário.

Nunca haverá um botão mágico que mova a funcionalidade "intuitivamente" do botão direito do mouse para as acomodações, sem que você especifique todos os aspectos detalhados de cada dispositivo de entrada (nesse ponto, você é nativo de todas as plataformas que você considerou, mas, no entanto, não -nativo para qualquer um que você não tenha considerado).

Realmente boa pergunta. Eu sempre me perguntei sobre isso por alguns anos subseqüentes no passado, pensei que havia alguma razão legítima por trás disso, mas realmente não existe.

Penso que a resposta é bastante simples, e muitas respostas não estão realmente a aprofundar a questão.

Se o seu idioma permite desenhar o piexel na tela, é 100% possível criar uma estrutura de GUI baseada nela, que imitará a aparência e a sensação dos controles de formulário do Windows com precisão.

Como o Java é multiplataforma, também é inteiramente possível garantir que, com base no tipo de sistema em execução real (Mac / Windows), a interface do usuário opte por parecer diferente nas duas plataformas, correspondendo ao estilo da plataforma de tempo de execução.

Como você pode ver no XAML, por exemplo, a interface do usuário pode ser facilmente apresentada em forma e linguagem muito estruturada. A escolha dos comportamentos "nativos" também é possível se houver tempo para fazer isso.

Portanto, seria possível criar uma estrutura de GUI que permitisse aos desenvolvedores Java obter aplicativos que pareciam nativos no Mac e no Windows.

Então, chegamos ao Swing, que é apenas uma estrutura de GUI do potencial infinito de estruturas de GUI que pode ser criada para Java. Ele se comporta como foi programado, o que não segue o processo acima e você obtém aplicativos de aparência estranha nos dois sistemas. Essa é a escolha feita pelos desenvolvedores do Swing, ninguém os forçou a fazer isso e a se comportar dessa maneira.