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

Isn't it only a matter of designing buttons that look like 'native' buttons?

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 eles não são muito bem dimensionados) - eles geralmente são gráficos vetoriais com muitos casos de canto programados neles ( então, quando o botão alcança a borda da tela, pode parecer um pouco diferente, por exemplo.) E, claro, você precisará de gráficos diferentes quando um botão é clicado. Por razões de direitos autorais, os desenvolvedores muitas vezes não podem usar apenas esses gráficos, então eles precisam ser recriados - e enquanto eles fazem um bom trabalho na maioria das vezes, inevitavelmente algumas coisas são perdidas dada a enorme variedade de componentes gráficos existentes. Isso é muito menos grave do que costumava ser - atualmente, se eu definir a aparência e o comportamento da plataforma padrão no Swing, noto muito pouco que pareça estranho.

Estou dizendo tudo isso com base no Swing, que é claro, um kit de ferramentas de GUI leve e não nativo. Você menciona especificamente que o SWT não parece nativo, o que é um pouco estranho, porque o SWT é nativo. É um kit de ferramentas que usa o JNI para chamar componentes nativos - portanto, se algo não parece certo, não é vai ser por causa da aparência e sensação.

Há literalmente meia dúzia de kits de ferramentas que podem ser considerados "nativos" em algum sistema. Alguns deles têm conceitos ou capacidades bastante exclusivos, e replicá-los em um kit de ferramentas de plataforma cruzada é tedioso. A aparência & A sensação de uma aplicação não é apenas determinada por uma “skin”, mas também pelo layout e como ela se comporta. Algumas considerações:

• Em um diálogo, em qual lado o botão “OK” pertence - à esquerda ou à direita? Justo, vamos construir um diálogo separado para cada sistema.
• Como marcamos o botão padrão em uma tela? Cor de tingimento, fonte em negrito, ampliando o botão? Justo o suficiente, 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 é 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, já que já descartamos o layout exato do pixel
• Como as fontes são processadas? Tão nítido quanto possível, ou suave e antialiased? E qual fonte deve ser usada? Observe que fontes diferentes têm métricas diferentes, portanto, o mesmo parágrafo renderizado para a mesma largura pode ter um número diferente de linhas, dependendo da fonte.
• O plano de fundo de uma janela é uma única cor, uma imagem ou um gradiente? Vamos apenas colocar isso em uma folha de estilo também.
• Como as barras de rolagem aparecem? Onde estão os botões - se eles têm algum? Até que ponto eles são ou são revelados apenas quando o ponteiro se move para uma determinada região?
• Como incorporamos outros esquemas de cores?
• O que se espera que seja arrastável? Onde os menus de contexto são esperados?

Esses problemas não podem ser resolvidos por meio de uma folha de estilos simples quando eles tocam no comportamento ou no layout geral do aplicativo. A única solução real é reescrever o aplicativo para cada sistema (ignorando, assim, 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 os kits de ferramentas específicos do sistema. A solução tomada pelo Swing é emular vários sistemas, que falham espetacularmente.

Além disso, há consistência entre plataformas, a ideia de que seu aplicativo pode ser exatamente o mesmo em todos os sistemas (geralmente escolhido por jogos, em que isso aumenta a imersão). Em aplicativos de desktop, isso é apenas irritante e quebra as expectativas do usuário.

Sim, é mais profundo.

É fácil criar um botão que se pareça com um botão do Windows ou OS X, quando você estiver criando apenas esse botão. Mas o botão deve "se comportar" como os originais, o que pode não ser fácil: talvez haja 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 do Windows, etc.

Isso é exacerbado quando você tem uma GUI inteira: um programa OS X apresenta seu conteúdo de forma diferente de um programa do Windows. Isso é quase impossível de capturar em uma GUI - você precisaria de duas GUIs, mas não muitas aplicações fazem tanto barulho. Em vez disso, eles estão apontando para "parece ok 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 ou um botão do Windows ou de qualquer outro kit de ferramentas. Mas as diretrizes da interface do usuário para a maioria dos ambientes não são tão simples quanto as noções básicas de "isto é como 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. É possível automatizar os casos mais comuns para interfaces de usuário muito simples, mas muitas, se não a maioria das tarefas de interface do usuário, exigem um toque muito mais refinado.

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

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

Há um trade-off entre esperar que seu aplicativo seja o mais natural possível em todos os sistemas e esperar que seu aplicativo funcione da mesma maneira em cada sistema. Não há escolha "certa".

Além disso, mesmo que você escolha o lado de "aparência natural", talvez queira proteger os usuários de seu kit de ferramentas gráfico contra "aprimoramentos" nos componentes nativos subjacentes e na API que podem interromper seu aplicativo inesperadamente.

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

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

É tudo devido ao histórico.

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

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

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

Hoje em dia, poucos programadores Java se importam com nada além de software baseado em servidor web.

Qualquer pessoa que escreva software de área de trabalho que se preocupa com a aparência "nativa" aprendeu há muito tempo a não usar o Java e tem seus pontos de vista reforçados sempre que usa qualquer software da Oracle.

Portanto, atualmente, não há demanda para "parecer nativa" em software de desktop de programadores Java.

O que você acha que é native é na verdade aplicativos nativos 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, então quando você ativa 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.

Isso ficará ainda pior, já que tanto a Microsoft quanto a Apple adicionam recursos dinâmicos de interface do usuário em suas plataformas de sistema operacional. Permitir que os desenvolvedores modifiquem seus aplicativos da mesma maneira que os designs da Web criam estilos para 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 personalizáveis.

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

Qual sistema operacional você quer parecer "nativo" também?

Você só não pode ser nativa de todos eles 100% do tempo.

O SWT, etc., é a melhor abordagem de esforço para parecer nativa para todos eles, já que é necessário chegar a 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 de sistemas operacionais, mas por causa de dispositivos de entrada. Para telas de toque, você realmente precisa projetar de forma diferente, porque não há botão direito do mouse. Portanto, você precisa acomodar a mesma funcionalidade de outra forma.

Nunca haverá um botão mágico que mova a funcionalidade "intuitivamente" do botão direito do mouse para guestures, sem você especificando cada aspecto detalhado de cada dispositivo de entrada (nesse ponto, você é nativo para todas as plataformas que você considerou, mas não-nativas para qualquer uma que você não considere).

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

Acho que a resposta é bastante simples e muitas respostas não estão realmente investigando o assunto.

Se o seu idioma permitir desenhar o piexel na tela, então é 100% possível criar um framework gui baseado nele que imite os controles de formulário do Windows e & sinta-se precisamente.

Como o Java é uma plataforma cruzada, também é totalmente possível garantir que, com base no tipo de sistema em execução real (Mac / Windows), a interface do usuário escolheria uma aparência 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 bem estruturadas. Escolher os comportamentos "nativos" também é possível se for necessário tempo para isso.

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

Então chegamos ao Swing, isso é apenas uma estrutura de GUI fora do potencial infinito de estruturas de GUI que poderiam ser criadas 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 em ambos os sistemas. Essa é a escolha feita pelos desenvolvedores do Swing, ninguém os forçou a fazer isso e se comportar dessa maneira.