Handcode GUI ou use a ferramenta designer de gui

Eu gostaria de ouvir algumas opiniões sobre como codificar suas GUIs, como normalmente fazemos quando usamos Java ou Qt com C ++, ao invés de usar uma ferramenta de designer de gui? Exemplos de ferramentas de designer de GUI seriam o designer de GUI do MFC, o designer do Qt, o Interface Builder (Apple).

Eu costumava ser um fã de codificação manual, mas da experiência recente eu mudei. O problema que tenho visto com a codificação manual é que é bastante rápido e flexível escrever as GUIs, mas uma vez que você precise fazer uma alteração em uma GUI escrita há muito tempo, pode ser muito difícil. Encontrar o elemento certo no painel grande pode ser difícil.

O segundo problema é que é muito fácil adicionar muita lógica na criação da GUI e no código de layout. Muitas vezes tive que assumir a manutenção do código GUI, que é realmente difícil de reutilizar porque seu comportamento é misturado com sua aparência e o layout e o comportamento de mixagem geralmente tornam a class muito grande e difícil de entender.

Usando uma ferramenta de designer GUI forçar uma separação muito mais clara entre aparência e lógica, na minha opinião.

Eu sinto fortemente que você deve usar um construtor de interface em vez de codificar manualmente uma GUI. Como na pergunta mencionada é uma separação muito mais limpa e uma vez que algo tem que ser editado é muito mais fácil.

O Qt Designer conseguiu esse recurso para criar uma class de um arquivo .ui 1) , mas acho que não usar esse recurso é a melhor maneira, pois isso cria apenas mais códigos que não deveriam existir. O problema de velocidade da criação da janela a partir de um .ui é insignificante, porque a janela precisa ser carregada apenas uma vez.

Este é o PyQt, mas algo semelhante é possível em C ++:

 class SelectDateDialog(QDialog): def __init__(self): QDialog.__init__(self) uic.loadUi("resources/SelectDate.ui", self) 

Essencialmente, isso tem o mesmo efeito de include todo o seu código de interface do usuário no método __init__() , mas a interface do usuário é quase completamente separada do código.

1) arquivos .ui são arquivos XML que descrevem uma interface de usuário

Eu sempre codifico manualmente o design da GUI onde não há linguagem de marcação GUI padrão (ou de fato padrão) (como no Java ). A razão para isso é que descobri que usar uma ferramenta de design de construtor de GUI o ligará para usar um IDE específico. Com o tempo, o melhor IDE para o design da GUI e / ou código de escrita será alterado e cada desenvolvedor deve estar livre para escolher qualquer IDE com o qual se sinta mais à vontade .

Onde eu trabalho no momento, temos um monte de GUIs legadas que foram escritas usando o construtor Netbeans Matisse GUI (contra o meu conselho na época :-). Estes são quase impossíveis de manter porque todos os desenvolvedores preferem o IntelliJ IDEA ou o Eclipse como seu IDE. Não é realista ou viável fazer com que os desenvolvedores ativem o Netbeans apenas para modificar o layout da GUI (as pessoas não mantêm as definições do projeto Netbeans em sincronia, etc.).

Outro ponto é que o tempo total de gravação do código de layout da GUI é provavelmente apenas 5% do esforço total de desenvolvimento de um determinado projeto. Mesmo que você demore o dobro do tempo para escrever o código, isso não significa uma sobrecarga no grande esquema das coisas. E é um preço pequeno a pagar pela manutenção a longo prazo.

Contanto que você tenha clareza sobre separar a lógica de layout da GUI da lógica de negócios, não acredito que nada sofra como resultado. Ninguém aqui usa mais os construtores GUI!

Eu faço isso manualmente, é muito mais fácil embaralhar as coisas e reutilizar os painéis dentro do aplicativo (alguns painéis podem aparecer em vários lugares).

Usando um designer funciona quando você está em uma equipe, os artistas devem fazer o GUI.

Encontrar o elemento certo no painel grande pode ser difícil.

?? Eu nunca vi isso.

Engraçado, foi o contrário para mim. Falando do ponto de vista do WinForms, o código gerado pelo designer é bastante barulhento, com talvez um quarto ou metade de todas as configurações de propriedade realmente necessárias. Fazer controles consideravelmente grandes também é mais uma tentação ao trabalhar com um designer. Alterar alguma hierarquia de controles no designer Winforms é um grande pesadelo aos meus olhos.

No meu último projeto eu criei APIs adicionais para configurar divisores em formulários, dockmanagers, menus, barras de ferramentas, etc. de maneira declarativa. São tais que reforçariam ainda mais a separação de preocupações.

Eu também tento confiar muito mais em resources de layout automático que reconhecidamente são muito mais agradáveis ​​no WPF, mas também podem funcionar de alguma forma no Windows Forms.

Eu aconselharia fortemente que você usasse o Interface Builder no OS X. Fazê-lo manualmente é bom se você quer aprender, mas você vai economizar muitas dores de cabeça usando-o em projetos reais. É realmente muito poderoso.

Quanto ao Java e C ++, depende do que você está fazendo e em quais plataformas. Para aplicativos simples, você pode sair sem nunca ver o código da interface do usuário. No entanto, para aplicativos complicados e clientes avançados, você normalmente precisa executar alguns dos códigos manualmente.

Depende da situação, na verdade. Eu acho que ambos têm o seu lugar, e eu costumo usar uma abordagem híbrida.

Há sempre algumas coisas que o construtor da GUI não pode fazer (por exemplo, configurar a cor para uma constante UIColor no Interface Builder). Por outro lado, a maior parte do trabalho da interface do usuário é bastante mundana (por exemplo, adicionando labels estáticos).

Eu prefiro fazer o material mundano no construtor de GUI, e as coisas mais interessantes no código.

Além disso, ocasionalmente me vejo editando o XML produzido pelo construtor de GUI (Interface Builder e glade no meu caso) manualmente.

Se você estiver projetando um aplicativo de negócios com vários formulários de input e dados tabulares, o código de gravação da interface do usuário será mais rápido e mais fácil de manter do que usar um designer de interface do usuário. Nesses tipos de aplicativos, quase nunca é necessário colocar precisamente um elemento em um local predefinido na canvas, enquanto, por outro lado, há muitas convenções de repetição e design que podem ser simplesmente extraídas em methods separados.

Tomemos por exemplo um diálogo de preferências do Eclipse ou do OpenOffice. Há um monte de categorias e um monte de opções diferentes para definir para cada um. Se você tiver que fazer algo desse tamanho, desenhar manualmente cada canvas é uma tarefa rotineira. Uma abordagem muito melhor é escrever código que irá gerar elementos da interface do usuário on-the-fly, a partir de dados de domínio fornecidos, de acordo com algumas convenções e padrões.

Não vejo como usar um designer facilita uma melhor separação, nem como essa separação aparente ajudaria em nada, já que você já mantém sua lógica de negócios fora da interface do usuário.

E, finalmente, se você estiver usando o Java, não deixe de conferir o MigLayout . Ele funciona com Swing e SWT, sua syntax é muito concisa e clara, e tem um modo de debugging que é incrivelmente útil.

Eu costumo pensar que a resposta correta depende da cultura da plataforma de destino. No OS X, o Interface Builder é uma parte tão integrante da cadeia de ferramentas que é difícil evitá-lo.

Em Java (awt ou swing), o contrário é realmente verdadeiro. Não há suporte para toolchain para isso.

Realmente, a maneira que você pode dizer é a maneira como as ferramentas produzem suas saídas. O Interface Builder produz arquivos no formato .nib que são específicos para o modo como o Cocoa coloca controles na canvas. Ele entende o que é essencialmente um formato de marcação de interface. Java não possui um conceito semelhante. Tudo é uma class compilada e, portanto, é muito mais difícil obter resultados convenientes.

O GTK +, quando combinado com o glade, parece encontrar um equilíbrio razoável entre os dois.

Nada impede de misturar as duas abordagens. Eu costumo fazer o layout principal de um formulário em um designer GUI (porque é rápido e você vê o que você está fazendo), e colocar lá um ou mais painéis que são preenchidos com código. Isso é especialmente útil quando a GUI deve se adaptar a situações específicas – por exemplo, se a GUI precisar mudar de acordo com o hardware conectado.

Em qualquer caso, o mais importante é manter a GUI e a lógica de aplicativo separadas.

Minha opinião sobre isso: 1. Código GUI codificado manualmente é muito mais reutilizável 2. Problemas de layout são mais simples com designers

A codificação manual pode ser útil se você quiser alguns resources não padrão incluídos na interface do usuário. Você tem mais flexibilidade, mas precisará investir mais tempo para criar uma boa interface, pois o Java / C ++ não é uma linguagem para direcionar o design da interface do usuário.

No mais, se você tiver um controle de revisão, poderá ver o histórico de mudanças, algo que não pode ser feito com um design que usa um formato binário, ou um formato xml que não seja amigável ao RCS.

Hoje, a maioria das ferramentas disponíveis para projetar visualmente uma interface de usuário não possui alguns resources. Eles não são flexíveis o suficiente, alguns resources só podem ser alcançados codificando-os. Além disso, em alguns casos, o código gerado não é muito amigo do homem e, se você modificar manualmente, não poderá mais continuar usando o designer.

Mas o projeto pode ser realmente uma economia de tempo, se o design é simples, e podemos esperar que os projetistas sejam aprimorados no futuro, mas não os sustentarei por extensão.

Minha conclusão é que se você precisa de flexibilidade hoje, você terá que codificar manualmente a interface, se você quer algo simples e rápido, então o designer é a melhor escolha.

Talvez no futuro os designers sejam mais poderosos, ou talvez existam novas linguagens especializadas no design da interface do usuário que sejam mais adequadas para uso em C ++ / Java, algo como XUL ou XAML.