Como o próprio Wiki da Haskell afirma :
Há um grande número de bibliotecas de GUI para Haskell. Infelizmente, não existe um padrão e todos são mais ou menos incompletos. Em geral, os laminados de baixo nível estão indo bem, mas são de baixo nível. Abstrações de alto nível são bastante experimentais. Há uma necessidade de uma biblioteca GUI de nível médio suportada.
Um professor da minha faculdade pediu a mim e a três outros especialistas em ciência da computação que considerassem trabalhar em uma biblioteca GUI para Haskell. Sua idéia inicial para o projeto foi escrever uma camada sobre o OpenGL que imitava a biblioteca mórfica encontrada no Smalltalk ; no entanto, isso é apenas uma sugestão e vale a pena considerar outro sistema.
Isso nos leva à questão real, com várias partes.
- Para que nível de abstração nossa biblioteca deve se esforçar? O Haskell Wiki parece indicar fortemente que uma biblioteca GUI de nível médio seria preferida; no entanto, uma biblioteca de alto nível ainda seria bem-vinda.
- Sobre o que nossa biblioteca deve ser construída? (Ex. OpenGL)
- Que biblioteca GUI existente você gostaria de ver nossa biblioteca imitar (se houver) e por quê? (Por exemplo, PyGame, mórfico, Swing, etc)
- Quais recursos você gostaria que a nossa biblioteca implementasse ou evitasse? Por exemplo, as pessoas boas do Gnome podem argumentar que o botão minimizar é desnecessário.
- Você tem alguma sugestão geral?
- Que nome inteligente você daria a essa biblioteca imaginária? (Ex. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)
Respostas:
Eu gostaria de ver uma biblioteca que seja elegante e simples de usar com o Haskell. O restante são detalhes técnicos que devem servir a esse propósito, não redefini-lo. Assim meus $ 0,02.
Não o baseie em um kit de ferramentas existente , como Qt ou GTK ou FLTK ou ... - isso limitará severamente você e provavelmente causará muito mais dor do que lucro. O PyQt é, erm, engraçado e artificial o suficiente, e o Python e o C ++ são linguagens OO imperativas extremamente flexíveis. No caso de Haskell, as coisas seriam muito mais difíceis, suponho.
Depende apenas das primitivas gráficas mais básicas e , em seguida, desenvolva isso. O OpenGL é bom, mas mesmo algo mais simples (somente 2D, por exemplo, SDL) também faria bem. Isso lhe dará flexibilidade e portabilidade máximas. Consulte Smalltalk / Morphic, Java / Swing, TCL / Tk.
Faça conceitualmente pequeno. As GUIs são difíceis como são, não há necessidade de adicionar outro Everest para escalar. Espero que Haskell possa ajudar a tornar a coisa compacta e modular.
Para pontos de bônus, torne-o skinnable. No mínimo, saiba como aplicar as cores do sistema (e apenas as cores do sistema) para pintar todo o seu repertório de controles, para que um aplicativo criado com este kit de ferramentas não seja desagradável. No máximo, saiba como fazer o Win32 / Gtk / Qt / Cocoa desenhar seus controles para que pareçam totalmente nativos. A capacidade de skin básica é simples e lógica; obter uma aparência nativa completa é bastante difícil.
Além disso, execute o sistema sem raiz e deixe o gerenciamento de janelas no sistema gráfico subjacente - X, Windows, qualquer que seja. Não fazer isso desafiará a sanidade dos usuários e dificultará a adoção drasticamente.
Como sempre, 'torne simples as coisas simples e complexas' + 'evite o tarpit de Turing, onde tudo é possível, mas nada de interessante é simples' + 'torne o mais simples possível, mas não mais simples'.
O nome é a coisa menos importante. De todos os kits de ferramentas GUI populares, apenas o Qt tem um nome de alguma forma inteligente. Vários projetos populares mudaram de nome, mesmo durante o vôo (Firefox, née Firebird). Tem algo para nomear, e você nomeará.
Boa sorte!
fonte
Depois de conversar com todos os alunos envolvidos e de dar a essa pergunta tempo suficiente para gerar interesse, acredito que chegamos a um consenso sobre algumas das principais perguntas no meu post original.
Decidimos procurar uma biblioteca de nível médio de acordo com a sugestão do Haskell Wiki.
Escolhemos o OpenGL devido à sua popularidade e suporte. Usaremos os projetos de wrapper GLUT ou GLFW Haskell como base.
Escolhemos o Morphic após um debate considerável entre ele e o PyGame. Não consideramos o QT ou o GTK, pois ambos já têm um ou mais projetos de biblioteca Haskell em desenvolvimento ativo .
Isso ainda está em debate. Decidimos não considerar o HAWT e, em vez disso, estamos analisando:
fonte