22 comentários

• Tatiana Al-Chueyr Pereira Martins(usuário não autenticado)

  17 de Outubro de 2009, 20:27

   

  Boa noite Nycholas,

  Tenho acompanhado suas atividades na comunidade InVesalius, sendo que valorizo sua colaboração e participação. Considero que tais premissas nos aproximem.

  Em função da última colocação, gostaria de lhe fazer uma pergunta: Por que não trabalhamos juntos? Afinal, há uma certa diferença entre "portar o InVesalius para GNU Linux / BSD" e criar um fork do programa, não acha? ;)

  Temos parceiros hoje trabalhando nesta área (desenvolvimento de ferramentas para odontologia), que serão inseridos dentro do InVesalius em breve, e seria uma oportunidade de unir esforços, ao invés de dividi-los. Afinal, não é muito comum encontrar programadores interessados em contribuir com projetos da área.

  A escolha de GUI é algo não apenas técnico, mas pessoal. Na minha visão, a melhor escolha é aquela que atende às demandas do usuários.

  Desenvolvemos o InVesalius 1 utilizando Tkinter, em 2001, por sua simplicidade. Na ocasião ela atendeu às demandas. Quando iniciamos o InVesalius 2 (+-2004) buscamos uma biblioteca que oferecesse mais widgets e também:
  - que tivesse licenciamento compatível com GPL (na época Qt não era LGPL)
  - multiplataforma
  - comunidade ativa

  Naquele período, o wxPython foi o que mais se enquadrou às nossas necessidades. A princípio utilizávamos o BoaConstuctor como IDE, pela facilidade em construir as interfaces. Entretanto, com o passar do tempo, ele não estava atendendo mais nossas necessidades, e identificamos que a melhor saída era escrever o código fonte da GUI na mão, sem um builder. Isso nos garantiu autonomia e possibilitou que utilizássemos os recursos mais recentes da biblioteca.

  Em termos de velocidade de desenvolvimento, diria que foi bastante rápida a construção da interface gráfica com wxPython sem builder, mesmo por programadores novos no projeto que não tinham experiência com a biblioteca (Thiago fez um editor de rtf em menos de 1 semana).

  Em relação a integração com VTK, hoje desenvolvemos em Ubuntu, Fedora, Windows e MacOS X. A integração wxPython-VTK nestes SOs tem sido satisfatória.

  Antes de iniciarmos o desenvolvimento do InVesalius 3, consideramos mudar de biblioteca de GUI, e o PyQt era um potencial candidato. Entretanto, tínhamos em mente que o InVesalius 2 precisava ser reformulado para ser menos dependente do wxPython e também para ser mais facilmente extendido a outras aplicações. Não nos sentimos aptos a fazer esta reformulação e, simultaneamente, migrar do wx para PyQt, por não termos experiência com a biblioteca. Então, desde novembro estamos escrevendo o InVesalius 3 de modo modularizado o suficiente para que seja simples a alteração da biblioteca de GUI, caso este seja o melhor caminho.

  É importante buscarmos consenso e caso a comunidade avalie que o PyQt atende melhor as demandas, podemos adotar a biblioteca para uma próxima versão do programa. Apenas defendo que é importante fecharmos uma versão do InVesalius 3 funcionando, bem modularizada, antes de alterar a biblioteca GUI empregada.

  O core do InVesalius (manipulação VTK, gerenciamento de projeto, importação, exportação, recursos, otimização de memória) é mais importante do que a biblioteca de interface gráfica utilizada, e acredito que todos ganhariam juntando esforços para melhorá-lo. Você não gostaria de contribuir neste sentido?

  "Coming together is a beginning; keeping together is progress; working together is success."
  - Henry Ford

  Abraços,

  Tatiana

  
  

  • Nycholas Oliveira e Oliveira(usuário não autenticado)

    19 de Outubro de 2009, 13:49

     

    :D, Tatiana,

     

     > Por que não trabalhamos juntos?

    Acredito que seria o ideal trabalharmos em conjunto.

     

    >  Afinal, há uma certa diferença entre "portar o InVesalius para GNU Linux / BSD" e criar um fork do programa, não acha? ;)

    A minha intensão é criar um fork do InVesalius 3, como o mesmo esta modularizado não seria uma dificuldade para se fazer isso. Vou explicar o porque; Na aplicação de implantodontia ela não vai utilizar todas a ferramentas do InVesalius e ainda fazendo algumas modificações para se adaptar ao conceito do projeto. Pensei em utilizar o InVesalius 2 como base para esse fork mas como você mesmo citou ele não esta modularizado para tal façanha e seria demasiadamente custoso adaptá-lo ao projeto.

     

    > O core do InVesalius (manipulação VTK, gerenciamento de projeto, importação, exportação, recursos, otimização de memória) é mais importante do que a biblioteca de interface gráfica utilizada, e acredito que todos ganhariam juntando esforços para melhorá-lo. Você não gostaria de contribuir neste sentido?

    Assim o fork seria uma reescrita da GUI do InVesalius e se utilizando do seu "core", o manuseio do protocolo DICOM e a interface com o VTK. Mas como o InVesalius 3 esta em constante desenvolvimento estou tendo que optar por fazer um "freeze" da sua última versão, para trabalhar em cima dela.

     O que poderia ajudar no trabalho em conjunto seria uma documentação com status do projeto, como um "todo list" com títulos, sub-títulos e porcentagem de conclusão das metas do InVesalius 3. Assim outros desenvolvedores externos ao projeto poderia implementar partes que te convém e fazer um patch e enviar ao projeto. Por exemplo, eu necessito de exportar imagens DICOM para XML e isso não esta implementado no InVesalius, teria duas opções, (1) eu implemento e fico "calado" ou (2) eu implemento e verifico que esse recurso esta na "todo list" do InVesalius, assim eu posso criar um patch e submete-lo ao projeto vocês avaliam podendo aceitar, rejeitar, reescrever se necessário e ambos teremos nos ajudado, :-).

     

    --

    Até mais e boa sorte,

    Nycholas de Oliveira e Oliveira.