Aplicações GUI

October 2nd, 2004 § 6 comments

Um leitor me propôs o seguinte problema:

Você é um programador Windows iniciante, embora você tenha bastante experiência de programação em geral. Você quer desenvolver aplicações GUI simples para rodar no Windows 2000 ou XP. O que você faria. Parece-me que não há nenhum resposta simples.

Esse é um problema realmente difícil. Desenvolvimento de aplicações GUI é fundamentalmente diferente de desenvolvimento para servidores ou programação embutida, e há um monte de questõeas considerar quando se decide partir por esse caminho. Como o leitor mesmo apontou, não parece haver um resposta simples.

Enquanto eu pensava sobre o assunto, me ocorreu que todos os ambientes desktop em todas os sistemas operacionais que eu usei compartilham desse problema. De fato, o desenvolvimento para alguns ambientes, como o Linux, é ainda mais complicado do que o desenvolvimento para Windows porque estes ambientes possuem uma arquitetura GUI mais complexa, geralmente mais flexíveis e poderosas mas menos padronizadas.

Eu acredito que há dois aspectos para a questão: primeiro, o ambiente de desenvolvimento em si, isto é, o IDE e/ou a linguagem e as ferramentas de suporte nas quais o programa será escrito; e segundo, a biblioteca que será usada para fazer a interface para a GUI nativa da plataforma ou que irá emulá-la.

Geralmente, os dois aspectos precisam ser considerados simultaneamente porque o que você escolhe para resolver um deles quase sempre limita as escolhas que você tem para o outro. Por exemplo, se você resolve desenvolver para Windows usando o Delphi, da Borland, você está limitado à Borland’s VCL. (Na verdade, há também a CLX , mas ela não é tão útil ou madura como a VCL.) Por outro lado, se você escolhe desenvolver em Python, você está livre para escolher entre uma dúzia de bibliotecas difernetes, cada qual com seus méritos e desvantagens.

Independentemente da linguagem e ambientes de desenvolvimento, porém, há alguns critérios básicos que precisam ser considerados quando uma biblioteca para desenvolvimento GUI é escolhida. Alguns deles são:

  • Velocidade do desenvolvimento
  • Performance em tempo de execução
  • Identidade visual
  • Facilidade de instalação
  • Extensibilidade
  • Portabilidade
  • Documentação

Velocidade de desenvolvimento é certamente o critério mais importante dos acima. O interessante é que quando

você desconta o efeito da linguagem usada, você percebe que, na maioria dos ambientes de desenvolvimento madures, a

velocidade de desenvolvimento é uma função direta da simplicidade, poder e flexibilidade das bibliotecas de suporte

do ambiente. Programadores experientes podem adquirir uma nova linguagem com cujo paradigma estejam acostumados em

menos tempo do que precisam para realmente absorver toda a API provida pela linguagem e ferramentas de suporte.

Produtividade quando desenvolvendo aplicações GUI depende então de quão bem as bibliotecas GUI suportam a plataforma subjacente (simplicidade), de quão linear é a API apresentada por essas bibliotecas (simplicidade), de quanto os programadores pode exigir das mesmas (poder) e, finalmente, de quão facilmente elas podem ser integradas e extendidas (flexibilidade).

Infelizmente, a maioria das bibliotecas em uso atualmente falham no quesito de simplicidade. O Visual Basic teve sucesso não porque tinha um ambiente de desenvolvimento visual, mas porque fez com que o entendimento do que estava acontecendo por trás das cenas fosse fácil. Os programadores podiam entender como os programas funciovam e criar soluções que atendessem suas necessidades. O mesmo foi válido para o Delphi. A habilidade de criar um formulário visualmente, colocar componentes sobre o mesmo, ligando seus eventos e fazendo a aplicação funcionar, é secundária. A habilidade de evoluir para modelos mais avançados de programação é o que importa. Eu já vi muitas aplicações Delphi baseadas em conceitos MVC onde a interface visual era toda criada programaticamente e cujos programadores eram um ordem de magnitude mais produtivos do que os que editavam seus formulários visualmente.

Muitos ambientes visuais tentam esconder a complexidade das bibliotecas sobre as quais funcionam. Programadores que se acostumam com esse tipo de ambiente tem problemas quando precisam extendê-lo para tarefas mais complexos. Afinal de contas, programar aplicações GUI não é apenas uma questão de empilhar componentes sobre um formulário e criar código para responder aos eventos gerados pelo usuário.

A performance em tempo de execução é um critério importante também. Uma das causas pelas quais o Java falhou no desktop era sua performance abissal na era do AWT. É claro que o fato da máquina virtual não ser tão desenvolvida na época também ajudou. O Swing, hoje, é muito melhor; mas a performance ainda não é boa o suficiente, principalmente quanto ao gerenciador de memória automático.

Muitas bibliotecas GUI resolvem o problema de performance tornando-se apenas finos envólucros ao redor das características providas pelo sistema operacional, que é também uma maneira usada de atender a muitos dos critérios acima.

O aspecto mais essencial da performance entretanto, está relacionado à extensibilidade da biblioeca. O caminho para a extensibilidade não deve afetar a performance. Se o programador precisa desenvolver um novo componente, este componente deve ter uma performance similar aos nativos—considerando, é claro, que ele tenha sido escrito corretamente. Esse é um grande problema para bibliotecas cujos componentes principais são meros envólucros ao redor dos componentes do sistema operacional. Geralmente eles requerem que o programadore faça todo o processamento visual do componente contra um canvas genérico, lidando com todos eventos que o sistema operacional pode disparar contra o componente. O resultado é uma perda de performance considerável e, às vezes, intolerável.

Identidade visual, isto é, a habilidade da biblioteca de mesclar-se transparentemente com o sistema operacional sob o qual a aplicação está rodando, é uma questão interessante. Se a aplicação desenvolvida com uma certa biblioteca é capaz de integrar-se com o fluxo de trabalho do sistema operacional, agindo como os usuários esperam, geralmente os usuários serão capazes de ignorar diferenças cosméticas relativamente grandes. Os usuários esperam consistência. Eles não se importam se os botões são maiores em uma aplicação ou outro. Mas eles se importam se cada aplicação define teclas de atalho diferentes para a mesma ação.

Facilidade de instalação é obviamente essencial porque não importa tão rápido você possa desenvolver uma aplicação, se você não conseguir levá-la aos seus usuários você está condenado a perder a vez. A aplicação pode rodar por si só ou requer máquinas visuais e ambientes de tempo de execução, mas os usuários não vão se importar até que sejam forçados a tomar outra ação que não seja apertar o botão Próximo em um assistente de instalação.

Extensibilidade também é um fator crítico porque geralmente os programadores precisarão criar componentes que não foram embutidos nas bibliotecas originais. A menos que essas bibliotecas facilitem a extensibilidade, elas não terão muito valor para os programadores.

A portabilidade somente é importante quando os usuários estão distribuídos em um ambiente heterogêneo. Ainda assim, eu a inclui porque bibliotecas que são criadas com portabilidade em mente tendem a ser mais capaz de lidar com diferentes ambientes e suas idiosincrasias. O resultado são bibliotecas mais bem pensadas e mais flexíveis.

A documentação é provavelmente um dos aspectos mais vitais de uma biblioteca, especialmente se as ferramentas que ele provê são muitas. Sem documentação, será difícil para programadores entenderem os detalhes de uma determinada biblioteca, principalmente porque não há duas que tenha a mesma API ou se comportem da mesma forma. Mesmo versões de uma biblioteca para linguagens diferentes tendem a se comportar de maneira diferente de modo que o modelo mental de uma biblioteca pode variar com a própria linguagem.

Uma vez que consideramos todos esses critérios, descobrimos que as bibliotecas mais comuns no mercado hoje falhar em atender a maioria deles. Especialmente onde velocidade de desenvolvimento é necessária, a maior parte das bibliotecas provê interfaces complicadas que forçam os programadores a aprenderem uma série de detalhes secundários sobre o funcionamente das bibliotecas mesmo que seja para programar aplicações triviais.

Bibliotecas escritas em C/C++ como o Qt, Gtk e o wxWidgets requerem que os programadores compreendam uma mistura de funções, objetos, macros e arquivos de inclusão antes que possam começar a pensar sobre a lógica da aplicação. Elas não escondem a complexidade. Os programadores precisam enteder signals e slots antes de pensar sobre o fluxo da aplicação—em modelos, visões e controladores. Mesmo quando essas bibliotecas são portadas para outras linguagens mais sofisticas que suportam uma semântica mais produtiva—como o Python, por exemplo—elas tendem a preservar a complexididade desnecessária da biblioteca original, ao invés de fazer um das características da linguagem para criar um API melhor.

Eu acredito que uma das poucas bibliotecas no mercado hoje que atendem a maior parte dos critérios acima é a VCL da Borland, que vem com o Delphi e o C++ Builder. Exceto por portabilidade, ela possui todas outras características mencionadas. Mesmo que a Borland nunca tenha conseguido uma fatia significativa do mercado, a VCL foi tão bem sucedida dentro do seu nicho que inspirou várias outras bibliotecas como o Windows Forms da Microsoft para o ambiente .NET (criado, inclusive, por um dos programadores da VCL) e o Swing da Sun para o ambiente Java. A VCL foi bem sucedida porque era simples para usar e extremamente flexível. Os programadores podiam criar novos componentes baseados em outros já existentes ou criá-los do zero. E todos esses componentes se integravam completamente com o ambiente. Eles não tinham nenhuma diferença real para os componentes nativos da VCL. E se um programador achava um bug em um componente já existente, geralmente era um questão de criar um novo componente herdado do com problemas, sobrepor alguns métodos e a aplicação voltava a funcionar. Há centenas de milhares de componentes para o Delphi disponíveis na Internet hoje por causa dessa flexibilidade. Mesmo sendo tão poderosa, porém, a VCL ainda requeria um bom tempo do programador para entender as suas nuances.

Para finalmente responder ao problema que o meu leitor levantou, eu tenho que concordar com ele. Não há soluções mágicas. Seja qual for a biblioteca escolhida, há muito a aprender de modo a tornar-se proficiente com a mesma. E esse conhecimento geralmente é perdido quando chega a hora de usar uma nova biblioteca.

Algumas bibliotecas se vangloriam no fato de ser possível criar aplicações completas sem escrever uma linha de código com as mesmas. O mal aguarda nesse caminho. Essa é a famosa mentalidade do PowerBuilder. Você pode criar aplicações sem código, mas elas são limitadas a formulário simples de entrada de dados que não podem ser estendidos ou reusados e que quebram quando o programador introduz uma nova regra de negócio. O único tipo de aplicação bem sucedida nesta área que eu conheço é o Squeak, e mesmo assim quando ele é usado em contextos educionais. Em outros contextos, o código é necessário.

Isto dito, eu acredito que há algumas bibliotecas que vale a pena aprender, se você tem a intenção de desenvolver aplicações profissionais. A maioria deles tem problemas sérios com um ou outro critério mencionado acima, mas todos são interessantes e produtivos o bastante para merecerem um lugar no arsenal de qualquer programador.

A VCL, da Borland, pode ser encontrada gratuitamente no Delphi Personal e vale um estudo, embora provavelmente vá desaparecer em um futuro próximo. A Borland está deixando de manter o Delphi para Win32 puro em favor do .NET e novas versões do Delphi vem com uma nova biblioteca, a VCL para .NET, que é um envólucro ao redor do Windows Forms. Mas a VCL ainda é um bom exemplo de biblioteca e excelente para se trabalhar.

Vale a pena aprender Windows Forms também. O ambiente de tempo de execução do .NET pode ser distribuído livremente, há uma versão introdutória grátis do Visual Studio e muitos projetos de ambiente de desenvolvimento abertos interessantes para o .NET. A VCL e o Windows Forms são similares, mas as diferenças valem um estudo. E essa biblioteca é o futuro do Windows também—ou pelo menos isso é dito.

Uma outra biblioteca interessante é o wxPython, a conversão do wxWidgets para o Python. Há até um IDE para o mesmo, embora fosse um pouco frágil da última vez que eu olhei. A coisas mais interessantes sobre o wxPython são sua portabilidade—ele está disponível em mais plataformas do que você precisará suportar—e o fato de ser baseado no wxWidgets, o que o torna bem sólido.

O VisualWorks, uma das implementações dominantes do Smalltalk também tem uma biblioteca GUI poderoso. De fato, Smalltalk e GUI tem raízeis comuns, tendo sido criadas pela mesmo visionário. A biblioteca é um pouco complexa, mas a sua herança MVC do Smalltalk a torna bem poderosa. A JPMorgan recentemente escolheu (PDF, 1MB) o VisualWorks para a sua aplicação de gerenciamento de risco e sistema de preços. Eles estimaramue cortaram os custos e tempo de desenvolvimento por três por causa da solução escolhida.

Se eu fosse escolher um ambiente de desesenvolviment hoje para Windows ou Linux, eu provavelmente escolheira o wxPython (ou qualquer outra de suas implementações irmãs, dependendo da linguagem do projeto). O wxWidgets não é muito mais complexo do que as outras bibliotecas; é baseado nos componentes nativos das plataformas que suporta; é maduro (o desenvolvimento do mesmo começou em 1992); é bem suportado; e é grátis. Adicionalmente, ele vem com um monte de bibliotecas embutidas, como um gerenciador automatica de configurações e suporte para impressão, OpenGL, HTML, protocolos de rede e Unicode. Há muitas ferramentas de suporta para se escolher, incluindo um IDE. Outras tarefas não triviais, como programação, dependem da linguagem usada. Python, por exemplo, tem um bom suporte na área.

Embora essa bibliotecas não sejam exatamente similares, elas oference uma ampla seleção de características que podem ajudar enormemente programadores em suas tarefas. Pode não haver uma resposta simples, mas eu acredito que já respostas boas os bastante para o problema citado.

§ 6 Responses to Aplicações GUI"

  • É um assunto muito chato, mas, pessoalmente, acho que GUI é o mal do século. Graças a ela, perdemos um tempo precioso fazendo desenhos e tomando decisões do que trabalhando em melhorias da aplicação em si.

    Também não é raro perdermos todo o nosso trabalho e recomeçarmos do zero. Volta e meia, vejo alguém falando ‘vamos converter nosso sistema de tal para tal, pois o futuro é vortex’. Dai o pessoal converte um sistema feito em Delphi, VB ou seja lá o que for para trabalhar com .NET ou outra tecnologia ‘da moda’.

    Hoje existe uma grande babel na área. Seja a quantidade de toolkits existentes, sejam pelas tecnologias ‘matadoras’ MVC ou outro semelhante (que já tem uma certa idade mas ainda é muito interessante), Lisp com CLIM, Squeak tem MVC e Morphics (que vem de Self), a MS e o Avalon, XUL, etc. Até pode ser que as coisas melhorem, mas não tenho condições de afirmar. Só sei que a solução não partirá das ‘grandes’ empresas.

    Se a aplicação for grande e duradoura, a velocidade de desenvolvimento deve ser pesada criteriosamente. Muitas vezes a manutenção (correção de problemas e inclusão de novos recursos) pode pesar mais na escolha.

    Sobre os ‘toolkits’ gráficos, como o Ronaldo escreveu, cada uma tem suas vantagens e desvantagens (eu ainda citaria a http://www.fox-toolkit.org/ ). Mas um detalhe sobre eles, é que não são meros desenhadores de botões ou janelas. Geralmente existe uma biblioteca de suporte que é exposta ao desenvolvedor. É claro que vai depender do ‘binding’ para a linguagem. mas a wxWidgets, por exemplo, possui facilidades para trabalhar com ODBC, trabalhar com um arquivo zipado com se fosse uma extensão do sistema de arquivos e tantas outras coisas.

    Só para finalizar, já que o VisualWorks foi mencionado, pode ser interessante uma olhada no pollock: http://www.cincomsmalltalk.com/userblogs/pollock/blogView

    É melhor parar por aqui (ou escrever outra entrada no blog :-)

  • Ronaldo says:

    Bem, eu não sei se eu categorizaria a GUI como mal do século considerando o que costumávamos usar. Mas há realmente uma ênfase muito grande colocada na mesma no desenho de sistemas. Eu achei até interessante ouvir um desenvolvedor uma vez dizer que a primeira coisa que ele fazia era o ícone da aplicação. Pareceu-me uma certa inversão de prioridades. Mas eu posso entender esse interesse por causa da visibilidade da GUI.

    O interessante é que não é raro um time de programação gastar alguns dias fazendo um protótipo, apresentar e a gerência achar que com mais algumas horas a aplicação está pronta.

    E realmente há a questão de perder o trabalho. Mas isso é aplicável não só a GUIs como também a linguagens. De Delphi para .NET não é só VCL para Windows Forms, mas também de Object Pascal para C# ou VB.NET ou qualquer outra linguagem .NET. E o conhecimento é perdido nesse processo. Netscape é um exemplo indireto.

    De certa forma, toolkits são um reflexo do mesmo motivo que leva desenvolvedores a criar novas linguagens. É uma permanente re-invenção da roda em busca de um patamar de melhoria. Vez ou outra acontece uma revolução e ficamos com uma coisa ordens de magnitude melhor. Mas no meio tempo, o processo é bem lento. Há uma certa seleção natural. O wxWidgets não estaria no mercado há tanto tempo se não houvesse uma boa razão para isso.

    Mesmo toolkits mais avançados (ODBC, O/R, etc) ainda falham em oferecer algo mais interessante do que a mera possibilidade de desenhar e integrar uma aplicação um pouco mais rápido. Talvez o foco esteja errado. Talvez seja necessário algo orientado a tarefas, baseado em continuações. Acho que um dia chegamos lá.

    Mas escreva a entrada em seu blog. Outros pontos de vistas e sugestões são mais do que bem-vindos.

  • Joao Pedrosa says:

    Coloquei um grande comentário (mas fichinha perto deste do Ronaldo) no meu blog:
    http://sinsalabintrix.blogspot.com/

  • Ronaldo says:

    Opa! Vou ler com mais calma e comentar.

  • Fernando da Silva Trevisan says:

    Lembrando que Windows Forms é MS.

    MS que vai mudar tudo no Longhorn-Avalon e o Windows Forms não vai mais ser compatível.

    Ok, o Longhorn-Avalon ainda demora. Mas será que vale a pena perder tempo aprendendo, já sabendo que depois vai jogar fora?

    [ ]’s

    Fernando da Silva Trevisan

  • Ronaldo says:

    Obrigado pelo comentário!

    Eu acho que mesmo com a chegada do Avalon, o Windows Forms não vai perder o seu lugar. Como os clientes investiram bastante, a Microsoft vai ser forçada a manter — como é forçada a manter o Windows 98, por exemplo.

    E o Avalon também, se chegar, vai precisar de uma espécie de processamento que você não vê em um desktop comum. Isso pode ser resolvido até lá, é claro, mas como é uma tecnologia que ainda não está disponível em larga escala, acho que vamos ter que esperar para ver.

What's this?

You are currently reading Aplicações GUI at Superfície Reflexiva.

meta