TableOfContents

Tkinter

Baseada em Tcl/Tk, a Tkinter acompanha a distribuição oficial do interpretador Python. Muitos consideram a melhor coisa do mundo, outros vão gargalhar e dizer que é horrível, principalmente pela performance e aparência, mas vai continuar sendo a biblioteca padrão da linguagem Python por um bom tempo.

Licença: Python (permite escrever livremente softwares comerciais, GPL ou sob qualquer outra licença).

Plataformas: Unix, Linux, Windows, MacOS/X

Website: http://www.python.org/topics/tkinter/

Vantagens:

• Portabilidade - Programas escritos usando a Tkinter são portáveis livremente entre Linux, Unix, Windows e Mac, além da garantia de que qualquer um poderá executar o programa sem precisar instalar bibliotecas extras.
• Aprendizado - Tem uma API simples de se aprender e fácil de lembrar.
• Documentação - Muito bem documentada, com inúmeros tutoriais e referências de ótima qualidade disponíveis na Web.

Desvantagens:

• Pobre - Faltam muitos componentes importantes, como notebooks e combo box (apesar de estes poderem ser feitos combinando outros componentes). Alguns elementos (listbox por exemplo) são incompletos ou limitados. Em compensação o componente Text é muito poderoso.

• Aparência - A Tk usa uma função própria para acessar diretamente as funções do sistema operacional e desenhar seus próprios elementos na tela. Isso tem a vantagem de ser mais facilmente portável, mas a grande desvantagem de ter uma aparência diferente da nativa do sistema operacional. Pessoalmente, quando eu uso Tkinter me sinto 10 anos atrás, usando Windows 3.1 :).
• Performance - O desempenho é horrível tendo em vista o que a biblioteca oferece.

Exemplo de código:

   1 from Tkinter import *
   2 
   3 class App:
   4           
   5     def __init__(self, master):
   6 
   7         frame = Frame(master)
   8         frame.pack()
   9 
  10         self.button = Button(frame, text="QUIT", fg="red",
  11                          command=frame.quit)
  12         self.button.pack(side=LEFT)
  13 
  14         self.hi_there = Button(frame, text="Hello",
  15                            command=self.say_hi)
  16         self.hi_there.pack(side=LEFT)
  17 
  18     def say_hi(self):
  19         print "hi there, everyone!"
  20 
  21 root = Tk()
  22 
  23 app = App(root)
  24 
  25 root.mainloop()

PyGTK

É um wrapper para o GIMP Toolkit (GTK), a biblioteca usada pelo GNOME e muitas outras aplicações para Linux. Tem ótimo desempenho, elementos ricos e visual agradável.

Licença: LGPL

Plataformas: Unix, Linux, Windows(Beta)

Website: http://www.pygtk.org

Vantagens:

• Desempenho - PyGTK 0.X (para GTK 1.2) tem provavelmente o melhor desempenho entre todas as bibliotecas avaliadas aqui. A versão 2.0 (para gtk 2.X) não tem o mesmo desempenho, mas é bem satisfatória.
• Documentação - Bem documentada. Existem bons tutoriais para ambas as versões. Apesar de não haver uma referência completa para PyGTK 0.X, existe uma muito boa para a versão 1.9X, 2.X.

• API - PyGTK usa uma API eficiente, baseada em propagação de sinais e callbacks. Um elemento qualquer emite um sinal, que é propagado "pra cima" até ser capturado e gerar a chamada de um callback.

• IDE - Possui uma ferramenta para construção de interfaces, o Glade, que permite gerar uma referência em XML da interface, que pode ser usado diretamente pela biblioteca.

Desvantagens:

• Portabilidade - Rodar aplicações usando PyGTK em Windows é uma tarefa complicada.

• Tamanho do código - Muito do código escrito em PyGTK chega a parecer redundante, mas é necessário. Por exemplo, para usar um elemento qualquer precisamos criá-lo, chamando a classe, configurá-lo através dos seus métodos de configuração, posicioná-lo e por fim mostrá-lo com o método show(). São no mínimo três chamadas de métodos pra cada objeto. Como resultado disso, temos arquivos de código fonte imensos. Linhas e mais linhas de código necessárias para se fazer qualquer coisa.

Exemplo de Código:

   1 import gtk
   2 
   3 class HelloWorld:
   4 
   5     def callback(self, widget, data):
   6         print "Hello again - %s was pressed" % data
   7 
   8     def delete_event(self, widget, event, data=None):
   9         gtk.mainquit()
  10         return gtk.FALSE
  11 
  12     def __init__(self):
  13         self.window = gtk.GtkWindow(gtk.WINDOW_TOPLEVEL)
  14         self.window.set_title("Hello Buttons!")
  15         self.window.connect("delete_event", self.delete_event)
  16         self.window.set_border_width(10)
  17 
  18         self.box1 = gtk.GtkHBox(gtk.FALSE, 0)
  19         self.window.add(self.box1)
  20 
  21         self.button1 = gtk.GtkButton("Button 1")
  22         self.button1.connect("clicked", self.callback, "button 1")
  23         self.box1.pack_start(self.button1, gtk.TRUE, gtk.TRUE, 0)
  24         self.button1.show()
  25 
  26         self.button2 = gtk.GtkButton("Button 2")
  27         self.button2.connect("clicked", self.callback, "button 2")
  28         self.box1.pack_start(self.button2, gtk.TRUE, gtk.TRUE, 0)
  29         self.button2.show()
  30 
  31         self.box1.show()
  32         self.window.show()
  33 
  34 def main():
  35     gtk.mainloop()
  36 
  37 if __name__ == "__main__":
  38     hello = HelloWorld()
  39     main()

wxPython

wxPython é um wrapper da biblioteca wxWindows. Assim como a Tkinter, as aplicações são facilmente portáveis. A diferença é que a wxWindows utiliza um wrapper sobre a interface gráfica padrão do sistema operacional (GTK em Linux, MFC em Windows), o que permite que as aplicações sejam mais facilmente portáveis e que tenham a aparência de uma aplicação nativa. Em compensação, o desempenho vai ladeira abaixo com o acréscimo de mais uma camada entre a aplicação e o sistema operacional.

Licença: GPL

Plataformas: Unix, Linux, Windows, MacOS/X

Website: http://www.wxpython.org

Vantagens:

• Portabilidade - Aplicações escritas em wxPython rodam praticamente sem problemas em várias plataformas. Esse é provavelmente o principal (senão o único) motivo pelo qual está se tornando bem popular.
• Componentes ricos - Nesse ponto a wxPython é imbatível. Há todo tipo de componentes, prontamente disponíveis, de telas a caixas de texto que interpretam HTML e até mesmo a Scintilla.

• Documentação - o wxPython vem com um demo da maioria dos seus widgets que serve como teste e exemplo de uso.

• Disponibilidade de Construtores de GUI - apesar dos melhores serem produtos comerciais, fiz alguns testes com o PythonCard e fiquei muito satisfeito. Embora o BoaConstructor seja mais popular, só consegui faze-lo funcionar utilizando versões antigas da wxWindows, enquanto o PythonCard funcionou perfeitamente com a versão 2.4.2, última estável. Além disso o PythonCard separa a parte visual do comportamento associado à interface (métodos e propriedades dos controles em arquivos diferentes). Considero a disponibilidade dessas ferramentas muito importantes, por julgar construção das interfaces a parte mais tediosa e desagradável da codificação. Sem citar nomes, as experiências de mercado demonstram que os usuários de programas valorizam muito mais interfaces agradáveis esteticamente do que robustez, confiabilidade, algoritmos eficientes e elegantes ou outros aspectos objetivos, até porque é o que eles observam. (RômuloCampelo)

Desvantagens:

• Desempenho - A performance das aplicações em si não é ruim. O problema é o uso de memória e o tempo de inicialização.

• Instabilidade - Mesmo estando ativamente em desenvolvimento, ainda tem alguns problemas de estabilidade. No mínimo 10% das mensagens na lista wxPython são reportando bugs.

• API complicada - wxWindows é uma biblioteca com quase 10 anos de idade, que foi sendo remendada precariamente com o passar dos anos. Apesar da wxPython ser um wrapper excelente, muito bem escrito, os problemas da wxWindows aparecem: API completamente diferente entre alguns componentes e outros, números de ID, macros, etc. Porém tem melhorado bastante a partir da versão 2.5 e o wrapper wxPython oculta bastante a complexidade e idiossincrasias do wxWindows.

• Aprendizado - Complicado de aprender graças à API mal planejada (50% ou mais das mensagens na lista wxPython são de iniciantes com problemas). Além disso, os nomes de classes encorajam o uso de "from wx import *" (aliás, mesmo problema da PyGTK 0.X, para GTK 1.2).

Aqui vou (RodrigoSenra) discordar um pouco, achei o aprendizado fácil, especialmente devido à abundância de exemplos. A versão 2.5 apresenta uma API mais consistente.

• Documentação - Apesar de alguns tutoriais razoáveis, há pouca documentação específica para wxPython. Para uma referência da biblioteca, tem de se recorrer à referência da wxWindows. Entretanto, muitas vezes basta seguir o código dos demos (em Python), sem ser necessário recorrer a documentação do wxWindows.

• IDEs Livres - O wxDesigner (http://www.roebling.de/) é um IDE bom, mas é comercial. Não há nenhum IDE RAD de qualidade e que seja disponível livremente, embora o BoaConstructor pareça muito promissor.

Exemplo de Código:

   1 from wxPython.wx import *
   2 
   3 ID_ABOUT = 101
   4 ID_EXIT  = 102
   5 
   6 class MyFrame(wxFrame):
   7     def __init__(self, parent, ID, title):
   8         wxFrame.__init__(self, parent, ID, title,
   9                          wxDefaultPosition, wxSize(200, 150))
  10         self.CreateStatusBar()
  11         self.SetStatusText("This is the statusbar")
  12 
  13         menu = wxMenu()
  14         menu.Append(ID_ABOUT, "&About",
  15                     "More information about this program")
  16         menu.AppendSeparator()
  17         menu.Append(ID_EXIT, "E&xit", "Terminate the program")
  18 
  19         menuBar = wxMenuBar()
  20         menuBar.Append(menu, "&File");
  21 
  22         self.SetMenuBar(menuBar)
  23 
  24 
  25 class MyApp(wxApp):
  26     def OnInit(self):
  27         frame = MyFrame(NULL, -1, "Hello from wxPython")
  28         frame.Show(true)
  29         self.SetTopWindow(frame)
  30         return true
  31 
  32 app = MyApp(0)
  33 app.MainLoop()

PyQT

PyQT é um wrapper para a biblioteca QT, que é a base do KDE (ambiente desktop para Linux). Muitas das vantagens e desvantagens do PyQT coincidem com as do PyGTK, pelo fato do GNOME e KDE serem "concorrentes" e se equivalerem em muitos aspectos. Existe uma biblioteca complementar, PyKDE, que atua sobre elementos específicos do KDE, como por exemplo interação com o kicker e a barra de tarefas.

Licença: segue de perto o sistema do QT, que é GPL para programas sem fins comerciais nas plataformas UNIX/X11 (Linux etc). Para Windows, apenas uma licença comercial está disponível no momento.

Plataformas: Unix, Linux, Windows, Mac OS/X

Website: http://www.riverbankcomputing.co.uk/pyqt/index.php (http://doc.trolltech.com/3.1/index.html)

Vantagens:

• Desempenho: Como o Qt foi construído de forma a facilitar o desenvolvimento de wrappers, o desempenho do PyQT é bem próximo do Qt quando usado com C++.

• Fácil de aprender: A biblioteca Qt é famosa por ser extremamente bem documentada, pois a própria Trolltech possui um time de escritores técnicos. Apesar da documentação ser para C++, é fácil "traduzir" os exemplos para Python. Existe também um ótimo livro online sobre PyQT no site [http://www.opendocs.org/pyqt opendocs.org]

• API: A API do PyQT utiliza um sistema de "slots" e "sinais", levemente similar ao sistema de sinais e callbacks utilizado por outras bibliotecas. A API é bastante rica e coerente.

• IDE: Possui uma IDE muito boa para criação de interfaces, chamada QT Designer. O programa pyuic transforma essas definições de interfaces em código Python, que pode então ser usado por outros programas.

Desvantagens:

• Portabilidade: Usar o PyQT é excelente para programas Linux (em especial para rodar em cima do KDE, embora isso não seja obrigatório), mas como não existe licença GPL para Windows, provavelmente não é uma boa idéia utilizá-lo nessa plataforma. No ambiente Windows existem DLLs disponíveis para download da Qt 2.x para fins não comerciais, sobre as quais se encontra disponível também o PyQt para Windows. DLLs para fins não comerciais da Qt 3.x somente se encontram disponíveis no livro [http://www.amazon.com/exec/obidos/tg/detail/-/0131240722/102-6076920-5337716 C++ GUI Programming with Qt 3].

Exemplo de código:

   1 import sys
   2 from qt import *
   3 
   4 class HelloButton(QPushButton):
   5 
   6     def __init__(self, *args):
   7         apply(QPushButton.__init__, (self,) + args)
   8         self.setText("Hello World")
   9 
  10 class HelloWindow(QMainWindow):
  11 
  12     def __init__(self, *args):
  13         apply(QMainWindow.__init__, (self,) + args)
  14         self.button=HelloButton(self)
  15         self.setCentralWidget(self.button)
  16 
  17 def main(args):
  18     app=QApplication(args)
  19     win=HelloWindow()
  20     win.show()
  21     app.connect(app, SIGNAL("lastWindowClosed()"),
  22                 app, SLOT("quit()"))
  23     app.exec_loop()
  24 
  25 if __name__=="__main__":
  26     main(sys.argv)

PyFLTK

FLTK (pronuncia-se fulltick) significa Fast Light Toolkit ou Toolkit rápido e leve. Ele cumpre exatamente o que promete, é rapido e não compromete a memória (você pode usar para programar para um 386 com 4Mb). A API utiliza chamadas ao sistema gráfico em uso para criar seus componentes, o que os mantem idênticos, indepente do sistema operacional (aliás, de uma maneira semelhante ao Tk, só que quando bem configurado, ficam bonitos) e isso aumenta a portabilidade. FLTK roda em mais plataformas que o próprio Python (existe inclusive uma versão para DOS 16 bits).

Licença: LGPL

Plataformas: Linux, FreeBSD, Windows, Solaris, Amiga, Dos, MacOS, OpenBSD

Vantagens: Rápido e portável, o aprendizado também é bem simples, tão fácil ou mais que o Tk, só que ele é mais completo.

Desvantagens: A principal desvantagem dele é no quesito posicionamento de widgets, ele só trabalha na base do x,y, o que torna a programação impossível sem um construtor de interface (ou, pelo menos, muito chata). Em C++ tem o FLUID, que vem com ele, só que o pyconvert, que vem no PyFLTK, não consegue converter todo o código da saída do FLUID para Python (parece que ele não converte classes e alguns outros recursos), o que torna desagradável a programação (primeiro, desenha-se toda a janela, depois gera-se o código e transforma-se o mesmo em objeto, então, se quiser mudar a janela, tem que ser na mão).

Programa de exemplo:

   1 from fltk import *
   2 import sys
   3 from string import *
   4 
   5 def theCancelButtonCallback(ptr, data):
   6         print "type = ", type(ptr)
   7         print "theCancelButtonCallback(%s)"%str(data)
   8 
   9 window = Fl_Window(100, 100, 200, 90)
  10 window.label(sys.argv[0])
  11 button = Fl_Button(9,20,180,50)
  12 button.label("Hello World")
  13 button.labeltype(FL_EMBOSSED_LABEL)
  14 button.callback(theCancelButtonCallback, "'some callback data'")
  15 
  16 window.end()
  17 window.show(len(sys.argv), sys.argv)
  18 Fl.run()

Website: http://pyfltk.sourceforge.net/ (http://www.fltk.org/)

FXPy

Website: http://fxpy.sourceforge.net/ (http://www.fox-toolkit.org/)

Anygui

Anygui é uma biblioteca que ainda se encontra em estágio muito inicial de desenvolvimento, mas é mencionada aqui a título de curiosidade. Se um dia chegar a ficar "pronta", será muito atraente e provavelmente vai tomar o lugar da Tkinter na biblioteca padrão. É escrita puramente em Python e funciona como um frontend para as outras bibliotecas disponíveis. Atualmente ela suporta PythonWin, Tkinter, wxPython, Swing (Jython), PyGTK, Bethon (BeOS), PyQT e até mesmo Curses ou texto puro, quando nenhuma outra biblioteca está disponível. A idéia é escrever uma aplicação usando Anygui e depois poder usá-la em qualquer plataforma com qualquer biblioteca.

Licença: MIT License

Plataformas: Python

Website: http://anygui.org

Vantagens:

• Portabilidade - A Anygui permite executar uma aplicação em qualquer plataforma suportada pela Python sem alterações, usando qualquer biblioteca disponível no sistema. O que mais você pode querer ?

Desvantagens:

• Pobre - Obviamente, os componentes têm de ser nivelados por baixo. Não é possível ter acesso a um componente que existe em uma biblioteca mas não nas outras, por isso, ela se presta apenas para projetos simples.

Exemplo de Código:

   1 import anygui
   2 
   3 
   4 class MyWindow(anygui.Window):
   5     def __init__(self, app):
   6         anygui.Window.__init__(self, title="Hello", width=220,
   7                                      height = 45)
   8         self.app = app
   9         button = anygui.Button(text="New Window", size=(200,25),
  10                                      x=10, y=10)
  11         anygui.link(button, self.new_window)
  12         self.add(button)
  13         self.app.add(self)
  14 
  15     def new_window(self, **kw):
  16         win = MyWindow(self.app)
  17         self.app.add(win)
  18 
  19 
  20 app = anygui.Application()
  21 win = MyWindow(app)
  22 app.run()

SWT

SWT? Você deve estar me perguntando: "Porque ele colocou SWT num artigo para GUIs Python, se só existe a SWT para Java?". Simples: Porque aqui mora uma idéia sensacional para um projeto feito no Brasil. Como vocês puderam perceber nessa lista, Python sofre hoje de um mal que o Java também sofreu: GUI. É sabido de todos os maus bocados que a Sun passou quando criou a AWT e, posteriormente, para 'corrigir' esse erro, inventou o "Swing". A IBM, do outro lado, resolveu esse problema criando (na verdade, portando) a SWT para utilizar no projeto [http://www.eclipse.org Eclipse] que muitos devem saber, é uma das melhores ferramentas de produtividade de código existentes hoje. O Eclipse é fantástico e utiliza a SWT. A SWT é multiplataforma e não nivela os recursos para o 'mínimo comum' das plataformas. Quando a plataforma oferece um componente nativo, a SWT a usa e quando a plataforma não oferece, a SWT cria este componente.

Acho que com a SWT o problema de GUI em Java foi resolvido. Imaginem usar a mesma SWT para resolver um problema Pythonico?

Porque eu não faço isso? Simples: Eu não uso GUI, não entendo nada de GUI e acredito que quase tudo que se faz com GUI é possível se fazer com interfaces Web. Mas isso é um assunto para discussões filosóficas em uma mesa de boteco e não no PythonBrasil

E porque eu que não entendo nada de GUI posso falar que SWT é a solução para esse problema? Porque quem usa Java acha isso e porque eu acho que o Eclipse tem uma GUI muito boa.

A SWT pode ser encontrada (com fontes e licença free) no site do [http://www.eclipse.org Eclipse].

Nota importante: Já existe há algum tempo um bind funcional do SWT para python: [http://www.cs.nyu.edu/zilin/pyswt/pmwiki.php?n=PySWT.Introduction PySWT]

Conclusão

Se você não tiver algum bom motivo para não usá-la, a Tkinter é uma opção razoável.

Apesar de estar atualmente "em moda", existe um nicho muito pequeno de aplicações onde a wxPython é a melhor opção, que são justamente aplicações multiplataforma, que precisam funcionar com pouca ou nenhuma alteração em Windows e Linux e que a Tkinter não seja suficiente (ou desejável). Mesmo assim, wxPython tem muitos bugs sérios que tem de ser considerados dependendo da aplicação.

No desenvolvimento de aplicações para Linux, na minha opinião não há dúvidas: PyGTK (porque não PyQt também?). Além de poder usar Glade e ter disponíveis componentes poderosos, a biblioteca se integra perfeitamente com o GNOME (usando pygnome).

Outras comparações

http://www.awaretek.com/toolkits.html - Ferramenta que compara os diversos toolkits para desenvolvimento GUI em Python e informa qual o ideal para você, baseado nos critérios que você pontua. Além disto, existem informações sobre cada um dos toolkits e o link para a página. (dica passada por Marco André Lopes Mendes - marcoandre at gmail.com)

Criei uma página com um EmailSobreToolkitsGui que enviei para a lista de discussão e me pediram para colocar aqui. -- OsvaldoSantanaNeto

Obs: os códigos de exemplo foram extraídos de tutoriais das respectivas bibliotecas. Eu pensei em escrever um exemplo em comum a todos, mas acredito que com isso eu iria inserir vícios adquiridos e não seria muito imparcial, já que os códigos das bibliotecas que eu gosto mais e tenho mais experiência ficariam melhores. -- PedroWerneck

A seção sobre SWT foi colocada ali por mim por achar que GUI em Python ainda é deficiente. -- OsvaldoSantanaNeto

A seção sobre o fltk foi escrita port mim RodrigoCesarHerefeld, eu ia comentar também sobre o Fox(FXPy) mas ainda não testei o suficiente

PedroWerneck (esperando outros colaborarem com este artigo )