gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Que Toolkit usar?
Contribuído por ajc em 12-04-04 22:39
do departamento what-a-cute-gnome
X gits escreve: " Depois de ler o artigo no osnews, voltei a questionar-me que toolkit gráfico devo usar para os programas que faço em linux. Sempre simpatizei muito com o GTK, mas tenho o problema descrito no artigo, é demasiado lento e grande. Já o QT é bastante mais rápido, e segundo li também é muito bem documentado e os problemas de licença já foram resolvidos há muito.... "
Embora prefira desenvolver em c++, não gostei da ideia do moc (um pré-processador usado pelo QT). Adorei usar o gtkmm, a API era simples e intuitiva e com uma passagem rápida pelo tutorial fiquei apto a usá-lo num instante, mas subsiste o problema da rapidez, e agrava o do tamanho e dependências.

Na mailing list do GTK houve uma discussão sobre este problema levantada por um dos developers do CinePaint que vai passar a usar o FLTK (que decidi experimentar entretanto...). Há muitos outros toolkits disponíveis, e é motivado pela minha indecisão e também pelas recentes notícias da Novell que venho perguntar-vos: que toolkit gráfico usam em linux?

Quais as razões/vantagens?

Cobra investe 50 MegaEuros em Ponte de Lima | WorkShop de Segurança no próximo dia 14 de Abril  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • gtkmm
  • discussão
  • CinePaint
  • FLTK
  • notícias
  • gits
  • artigo
  • osnews
  • GTK
  • QT
  • Mais acerca X
  • Também por ajc
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Que tipo de programa tencionas fazer? (Pontos:2, Esclarecedor)
    por secameca em 12-04-04 22:58 GMT (#1)
    (Utilizador Info)
    Saber isso é muito importante.

    Para um programa que use OpenGL muito e que apenas necessite de um interface simples, o FLTK é uma boa escolha.

    A Qt é uma boa biblioteca, desde que não tenciones fazer software proprietário para Linux ou ports para Windows.

    Eu pessoalmente uso a GTK+ 2.4 nos meus programas. Os problemas que o tipo do CinePaint põe são mal escolhidos na minha opinião. E tentar fazer um port de um programa complicado como o Cinepaint para um toolkit tão básico vai-lhe trazer mais problemas que vantagens.

    Re:Que tipo de programa tencionas fazer? (Pontos:1)
    por secameca em 12-04-04 23:10 GMT (#2)
    (Utilizador Info)
    Ah e quanto à Novell, eles podem-se ir borrifar se quiserem. A Ximian pode ser importante, mas há mais gente a trabalhar no GNOME para além deles. E os chefes da GTK+ trabalham para a RedHat não para a Ximian.

    Aconselho-te a ignorar esse género de rumores enquanto não vires passos reais nesse sentido. O mundo funciona à base de produtos reais e não anúncios de imprensa.

    dialog ou ncurses (Pontos:2, Engraçado)
    por racme em 12-04-04 23:29 GMT (#3)
    (Utilizador Info) http://tinyurl.com/2tjh2




    make world && !war;
    Re:dialog ou ncurses (Pontos:1)
    por Mulder3 em 13-04-04 0:46 GMT (#11)
    (Utilizador Info)
    nahhh... Tens que ser mais hardcore, Xlib rulezz ou então directamente para o FrameBuffer...

    Microsoft Windows: A 32bit extension and graphical shell to a 16bit patch to an 8bit operating system originally coded for a 4bit microprocessor
    Pff (Pontos:3, Interessante)
    por CrLf em 12-04-04 23:38 GMT (#4)
    (Utilizador Info) http://crodrigues.webhop.net
    Sempre simpatizei muito com o GTK, mas tenho o problema descrito no artigo, é demasiado lento e grande.

    Sinceramente nunca consegui perceber isto... O GTK2 é lento onde? De todas as aplicações que vi migrar de GTK 1.2.x para 2.x não conheço nenhuma que tenha ficado mais lenta. Apesar das primeiras versões do GTK 2.x terem tido alguns problemas de performance derivados da melhor qualidade gráfica (double-buffering especialmente), isso foi rapidamente resolvido. E o QT não é certamente "bastante mais rápido", pelo menos não é essa a minha experiência.

    Dito isto, eu gosto bastante de ambos os toolkits e não acho que o "moc" seja uma desvantagem do QT. Do ponto de vista da API acho o QT bastante elegante e a minha preferência em C++ (até porque me permite ignorar toda aquela horrorosidade que é a STL) mas não sei dar uma preferência a nenhum dos dois (já fiz coisas em ambos -- na realidade em GTK 1.2.x com algumas, poucas, coisas em 2.x).
    O gtkmm também me parece bastante elegante mas é mais uma dependência. Se fosse incluido nas distribuições até o consideraria um bom concorrente ao QT (dada a minha preferência do GNOME) mas isso ainda não acontece (e não acontecerá até existirem aplicações que o justifiquem, o que é um ciclo vicioso).

    Na mailing list do GTK houve uma discussão sobre este problema levantada por um dos developers do CinePaint que vai passar a usar o FLTK (que decidi experimentar entretanto...).

    O FLTK não está ao nível de um QT ou de um GTK2 mas é pequeno (pode ser compilado estaticamente sem grande "bloat") e portável entre Windows e Unix sem grandes questões, o que não acontece com os outros dois (o QT tem as licenças dispendiosas e o GTK tem a fraca integração com o Windows) pelo que é um bom concorrente se a portabilidade entre plataformas for desejável.
    Penso que será mesmo por esta razão que o CinePaint irá migrar para FLTK (juntamente com a proximidade com os developers deste) mas não sei se será uma grande ideia da parte deles... aquilo está tão integrado com o GTK que será preciso fazer quase tudo de novo...

    Resumindo, se o desenvolvimento for em C++ e o software nunca será comercial então vai pelo QT; se não te importares com as dependências extra vai pelo gtkmm; se for em C (ou Python) vai pelo GTK2 e se for para correm em Windows e Linux vai pelo FLTK.

    PS: outra hipótese é o FOX Toolkit, que nunca experimentei.

    -- Carlos Rodrigues
    Re:Pff (Pontos:1, Redundante)
    por gits em 13-04-04 0:58 GMT (#12)
    (Utilizador Info)
    Sempre notei uma certa deficiência de desempenho do GTK relativamente ao QT. Desde a versão 1.4 que uso o GNOME, e ainda aqui tenho o 2.4; experimentei o KDE 3.2 (apt-get... debian unstable here) só para ver como estava e enfim, converti-me. Aproveito para recomendar a todos os utilizadores de GNOME para experimentarem o último KDE se não o fazem há algum tempo, talvez gostem também. Mas voltando à questão do desempenho, o gnome-terminal chegava a mostrar chars a passo de caracol enquanto usava o vim... já o konsole é muito mais fluido. Outras coisas mínimas, como mover janelas, que se arrastam com o GTK, o texto e muitos widgets que parecem ocupar mais espaço que deviam; no KDE tudo parece mais arranjado e no seu sítio, apesar dos polish polish feitos ao GNOME.

    Também não acho o moc uma desvantagem mas é um hack que já não se justifica, os templates e a libsigc++ (adoro!) fazem um bom trabalho sem alterar a linguagem. Discordo contigo quanto à STL, acho a library fantástica e muito bem desenhada. Uma das coisas que gosto no gtkmm é ter nomes tipo STL e não redefinir coisas que já existam; por exemplo, as linked lists da Glib não estão wrapadas na Glibmm, uma vez que existe a list na STL. Também são reutilizados os conceitos de iterator, por exemplo para iterar nos widgets contidos num container qualquer, tipo HBox.

    De facto espero que o gtkmm pegue, ainda é o toolkit que uso para já à falta de arranjar melhor.

    A hipotese do FLTK é que para projectos simples que quero mais é fazer depressa que bem (tools que uso, não para distribuir) pareceu-me bem.

    Pensei mais entretanto nestes assuntos todos, e acho que o GTK ganhava muito com uns melhoramentos de desempenho, mas mais que tudo o que falta no GTK/GNOME é documentação de jeito. O tutorial de introdução é bastante bom, mas as API references são basicamente os headers, e há muitos widgets e funções e argumentos usados que só um developer do GTK sabe o que lá estão a fazer. O gtkmm já oculta mais isto e tem uma interface tão consistente que até "adivinhamos" o nome e modo de uso das classes. Embora nunca tenha feito nada com o QT, já passei pela documentação e de facto, é aquilo que falta ao GNOME.

    Ainda hoje estive a usar o Glade, o programa é fantástico. Mas já não foi a primeira vez; da primeira acabei por desistir por não perceber como fazer alguma coisa com aquilo. Depois de uns tempos de desenvolvimento com GTK lá consegui perceber bem aquilo, e vejo agora quão bom é (juntamente claro, com o glademm e a libglade; que também me faz pensar que XAML afinal não é inovação alguma). O problema é documentação de jeito. Fico à espera do Glade3 que está anunciado na página. Mais uma vez, o QTDesigner está muito à frente.

    Espírito de contradição (Pontos:2)
    por CrLf em 13-04-04 2:09 GMT (#13)
    (Utilizador Info) http://crodrigues.webhop.net
    Sempre notei uma certa deficiência de desempenho do GTK relativamente ao QT. Desde a versão 1.4 que uso o GNOME, e ainda aqui tenho o 2.4;

    Eu nunca notei isso.

    o gnome-terminal chegava a mostrar chars a passo de caracol enquanto usava o vim... já o konsole é muito mais fluido.

    Estás a confundir o gnome-terminal com o GTK. O problema do gnome-terminal é o widget de emulação vt100 que tem alguns problemas de performance, não o GTK. Mas, no entanto, uso o gnome-terminal a toda a hora e nunca o notei lento em uso normal (só se nota, por exemplo, num "ls -la /dev/", onde é 4x mais lento que o konsole).

    Outras coisas mínimas, como mover janelas, que se arrastam com o GTK

    Não noto isso. Arrastar o nautilus parece-me tão rápido quanto o konqueror...

    o texto e muitos widgets que parecem ocupar mais espaço que deviam; no KDE tudo parece mais arranjado e no seu sítio, apesar dos polish polish feitos ao GNOME.

    Eu tenho exactamente a opinião contrária. No KDE parece haver uma certa tendência para empacotar tudo, o que lhe dá um certo aspecto "widgets ao monte". Eu prefiro o estilo "less is more" do GNOME.

    Ainda hoje estive a usar o Glade, o programa é fantástico. Mas já não foi a primeira vez; da primeira acabei por desistir por não perceber como fazer alguma coisa com aquilo.

    Eu já percebi como aquilo funciona e é sinceramente mau... alterar qualquer coisa é um pesadelo, obrigando a escangalhar quase tudo o que está feito... O Glade segue o principio de funcionamento do GTK e é aí que falha pois o que é boa ideia no código é má ideia numa ferramenta de construção de interfaces. Aí o QT-designer está milhas à frente, pois usa no desenho principios diferentes aos do código (não se andam por ali a criar containers e a enfiar widgets lá dentro, criam-se os widgets e depois agrupam-se em containers... muito mais usável). O que é curioso é que o QT-Designer até poderia gerar interfaces para o GTK, só seria preciso ajustá-lo um pouco e criar um novo "uic".

    -- Carlos Rodrigues
    Re:Espírito de contradição (Pontos:2, Interessante)
    por gits em 13-04-04 3:58 GMT (#14)
    (Utilizador Info)
    Quanto ao glade, misturei um bocado duas ideias: o glade como ui designer, e por outro lado a libglade.

    Como designer, acho-o mesmo bom, mas temos de entrar no estilo de pensamento do GTK, do boxing e tal. Consigo introduzir alterações com facilidade sem ter de alterar tudo. O problema que tive no início foi estar habituado ao Visual Basic (ya ya, teve de ser para fazer o 12º ano) e a fixed positioning do widgets. E o código gerado é correctíssimo c/c++ e adere muito bem à estrutura de código GTK. Digo eu... :)

    Agora quanto à libglade. É muito interessante a ideia do GUI todo estar descrito num ficheiro XML que é loadado em runtime, e basta invocar uma função para criar um widget a partir do ficheiro: cria o widget, connect()a os signals, etc. Isto permite alterar o GUI com o programa a correr, não é preciso recompilar para testar GUIs diferentes, e permite também ao programa desenhar widgets que não sabe como são. Quando disse que o glade era fantástico, era à libglade que me referia :)

    Já agora, são quase 5 da manhã e amanhã tenho aulas às 9... o que estive a fazer desde a meia-noite quando me levantei porque não conseguia dormir? wikipedia. É incrível começar por ir procurar qualquer definição que vi num sítio qualquer e acabar por ler cenas sobre tudo e mais alguma coisa ainda já sem nada a ver com o tema original. E agora vem-me à cabeça uma quote: "it's probably later than you think" ;)

    Re:Espírito de contradição (Pontos:2)
    por CrLf em 13-04-04 14:34 GMT (#24)
    (Utilizador Info) http://crodrigues.webhop.net
    Como designer, acho-o mesmo bom, mas temos de entrar no estilo de pensamento do GTK, do boxing e tal.

    O problema não é entrar no estilo de pensamento do GTK, o problema é que esse estilo só se adequa ao código, um editor visual de interfaces tem de seguir um esquema diferente. O estilo de pensamento do QT é exactamente igual e eles não o aplicaram ao designer.

    Agora quanto à libglade. É muito interessante a ideia do GUI todo estar descrito num ficheiro XML que é loadado em runtime, e basta invocar uma função para criar um widget a partir do ficheiro: cria o widget, connect()a os signals, etc. Isto permite alterar o GUI com o programa a correr, não é preciso recompilar para testar GUIs diferentes, e permite também ao programa desenhar widgets que não sabe como são.

    É verdade, na realidade não conheço nenhuma implementação de uma coisa deste género anterior à libglade pelo que acredito que foi pioneira (pelo menos em uso generalizado). Hoje em dia já se vêem coisas dessas em muitas situações (em coisas do tipo da applet do IRS).

    wikipedia. É incrível começar por ir procurar qualquer definição que vi num sítio qualquer e acabar por ler cenas sobre tudo e mais alguma coisa ainda já sem nada a ver com o tema original.

    A wikipedia tem esse efeito, especialmente porque é escrita de uma forma pouco convencional (por comparação com as enciclopédias tradicionais) e de leitura agradável. A wikipedia é o exemplo paradigmático da intenção do hipertexto.

    -- Carlos Rodrigues
    Re:Pff (Pontos:2, Informativo)
    por Antonio Manuel Dias em 13-04-04 10:53 GMT (#18)
    (Utilizador Info) http://maracuja.homeip.net

    Também podes usar Qt em Python, através do PyQt. Já li algures que este toolkit é ainda mais fácil de usar em Python que em C++ :)

    Em relação ao licenciamento do Qt (e do PyQt): se vais desenvolver uma aplicação proprietária, pela qual serás óbviamente pago, não te deves logicamente importar de pagar as respectivas licenças proprietárias do software que irás usar. Se desejas usar ferramentas livres para desenvolvimento, então o que desenvolves deve também, por um caso de justiça, ser livre.

    A minha opinião neste assuntos é simples: a LGPL é uma boa licença para tentar "vender" uma plataforma livre a empresas que desde sempre se habituaram a fazer software proprietário; no entanto, a GPL é uma licença muito mais justa, precisamente por requerer que todo o desenvolvimento e evolução obtido à custa de software desenvolvido sob esta licença seja devolvido à comunidade sob a mesma licença.

    Cumps.


    "mudem de rumo, já lá vem outro carreiro"
    Re:Pff (Pontos:2)
    por CrLf em 13-04-04 15:13 GMT (#25)
    (Utilizador Info) http://crodrigues.webhop.net
    Também podes usar Qt em Python, através do PyQt. Já li algures que este toolkit é ainda mais fácil de usar em Python que em C++ :)

    Também já andei a brincar com isso mas aqui sou obrigado a dizer que em Python o GTK2 é superior ao QT (é mais fácil de usar).

    Em relação ao licenciamento do Qt (e do PyQt): se vais desenvolver uma aplicação proprietária, pela qual serás óbviamente pago, não te deves logicamente importar de pagar as respectivas licenças proprietárias do software que irás usar.

    O problema não é esse, o problema é que não podes começar a desenvolver com a versão free do QT. Qualquer programa que tenha uma hipótese remota de vir a ser comercial tem de ser desenvolvido com o QT pago desde o início (o que é bastante chato).

    Se desejas usar ferramentas livres para desenvolvimento, então o que desenvolves deve também, por um caso de justiça, ser livre.

    A minha opinião neste assuntos é simples: a LGPL é uma boa licença para tentar "vender" uma plataforma livre a empresas que desde sempre se habituaram a fazer software proprietário; no entanto, a GPL é uma licença muito mais justa, precisamente por requerer que todo o desenvolvimento e evolução obtido à custa de software desenvolvido sob esta licença seja devolvido à comunidade sob a mesma licença.


    Essa é a opinião da FSF mas não é a minha. Eu não concordo com o uso da GPL como um vírus pelo que prefiro a LGPL para bibliotecas. O objectivo da GPL (no meu entender) deve ser o de impedir a apropriação e posterior proprietarização do software e não contaminar código que por acaso se linka com ela.

    -- Carlos Rodrigues
    Re:Pff (Pontos:1)
    por Antonio Manuel Dias em 13-04-04 15:54 GMT (#26)
    (Utilizador Info) http://maracuja.homeip.net

    o problema é que não podes começar a desenvolver com a versão free do QT. Qualquer programa que tenha uma hipótese remota de vir a ser comercial tem de ser desenvolvido com o QT pago desde o início

    Como autor, podes alterar a licença do teu software quando desejares e podes até manter duas licenças para o mesmo software (como faz a Trolltech com o Qt). É claro que todas as cópias já distribuídas com a GPL poderão continuar a ser copiadas livremente, mas não as novas versões se adoptares uma licença mais restritiva. Assim, podes bem começar a desenvolver usando GPL e, quando quiseres passar a uma licença proprietária, comprar a licença comercial do Qt e passar a distribuir com essa licença o novo software.

    O objectivo da GPL (no meu entender) deve ser o de impedir a apropriação e posterior proprietarização do software e não contaminar código que por acaso se linka com ela.

    O código que se liga a uma biblioteca é um produto derivado. E, na minha opinião, é apenas justo que, ao aproveitar-me do trabalho e engenho de outros, outros possam também beneficiar do meu trabalho e engenho. Se todos comemos do mesmo panelão de sopa, é justo que todos o ajudemos a encher, não achas?

    Cumps.


    "mudem de rumo, já lá vem outro carreiro"
    Re:Pff (Pontos:2)
    por CrLf em 13-04-04 20:46 GMT (#29)
    (Utilizador Info) http://crodrigues.webhop.net
    É claro que todas as cópias já distribuídas com a GPL poderão continuar a ser copiadas livremente, mas não as novas versões se adoptares uma licença mais restritiva. Assim, podes bem começar a desenvolver usando GPL e, quando quiseres passar a uma licença proprietária, comprar a licença comercial do Qt e passar a distribuir com essa licença o novo software.

    Não é bem assim. Código que foi desenvolvido com a versão Free do QT não pode mais ser fechado, mesmo que compres uma licença. Podes é manter as secções antigas de código sob GPL e as novas fechadas, se isso for possível.

    O código que se liga a uma biblioteca é um produto derivado.

    Essa é a posição da FSF mas é altamente discutível, se estás apenas a usar uma API não estás a extender a funcionalidade da biblioteca e logo não é um produto derivado, é um produto que usa a biblioteca (se, como autor, a defines como uma biblioteca estás a pressupor o seu uso por outro software).

    E, na minha opinião, é apenas justo que, ao aproveitar-me do trabalho e engenho de outros, outros possam também beneficiar do meu trabalho e engenho. Se todos comemos do mesmo panelão de sopa, é justo que todos o ajudemos a encher, não achas?

    Se estás a fazer uma biblioteca para ser usada, faz sentido evitares que outros se apropriem do teu código e o tomem como seu, fechando-o (possível com a licença BSD). Já não faz grande sentido obrigar todos os seus potenciais utilizadores a seguirem o mesmo esquema de licenciamento que tu (com a GPL). O facto deles usarem a tua biblioteca não a faz menos livre. A minha opinião é coincidente com a da OSI e a tua é coincidente com a da GNU/FSF. Ora acontece que eu acho a posição da FSF (anti-software proprietário) perniciosa e contra-producente.
    As bibliotecas GPL são liminarmente rejeitadas pelo software proprietário evitando que ganhem importância, as LGPL não, podem ser usadas em software proprietário e livre, fazendo com que ganhem relevância e o seu uso se generalize, potenciando mais aplicações potencialmente (passe o pleonasmo) mais interoperáveis (ou standardizadas, como queiras), atraindo mais desenvolvimento para as plataformas livres e quiçá até permitindo a alguns projectos proprietários absorverem as vantagens do opensource e tornar-se livres. Eu encaro a GPL como uma arma de defesa, usá-la como arma de ataque só reforça os argumentos daqueles que a apontam como um cancro.

    -- Carlos Rodrigues
    Re:Pff (Pontos:1)
    por Antonio Manuel Dias em 13-04-04 22:35 GMT (#32)
    (Utilizador Info) http://maracuja.homeip.net

    Código que foi desenvolvido com a versão Free do QT não pode mais ser fechado

    Claro, se já foi licenciado por GPL (e se foi desenvolvido com versão GPL do Qt e distribuído, tem de ser GPL) será sempre livre. Apenas o novo código pode ser efectivamente fechado (mesmo sendo derivado de código livre, já que és tu o detentor dos direitos de cópia). Estávamos a dizer o mesmo por palavras diferentes.

    As bibliotecas GPL são liminarmente rejeitadas pelo software proprietário evitando que ganhem importância

    Por isso algumas empresas estão a optar pelo duplo licenciamento do mesmo software, o que possibilita que o software se torne popular, por ser livre, que possa também ser usado para desenvolver software proprietário, usando a sua licença proprietária e que ainda dê lucro à empresa criadora do software, através da venda de licenças. A Trolltech e a MySQL AB são dois exemplos que me lembro agora. É engraçado que se ouça falar mais vezes do problema de licenciamento do Qt que do MySQL...

    Eu encaro a GPL como uma arma de defesa, usá-la como arma de ataque só reforça os argumentos daqueles que a apontam como um cancro.

    GPL é apenas uma licensa entre muitas, cabendo sempre ao criador do software escolher a licença sob a qual o quer publicar. A sua vantagem, para mim, é a garantia que o software derivado de software livre será, também ele, livre, perpetuando assim a partilha do conhecimento.

    Cumps.


    "mudem de rumo, já lá vem outro carreiro"
    Re:Pff (Pontos:2)
    por CrLf em 13-04-04 23:37 GMT (#34)
    (Utilizador Info) http://crodrigues.webhop.net
    É engraçado que se ouça falar mais vezes do problema de licenciamento do Qt que do MySQL...

    Isto porque a licença do MySQL permite o seu uso para fins comerciais gratuitamente desde que o MySQL possa ser substituido por outro motor de bases de dados facilmente (i.e. se não se usar as suas bibliotecas mas sim qualquer coisa como o ODBC).

    -- Carlos Rodrigues
    Re:Pff (Pontos:1)
    por edsonmedina em 14-04-04 1:54 GMT (#36)
    (Utilizador Info)
    até porque me permite ignorar toda aquela horrorosidade que é a STL

    horrorosidade porquê?

    tenho impressão que não conheço nenhuma outra lib tão consistente e agradável de usar.
    troll tech (Pontos:2)
    por ruben dig em 12-04-04 23:47 GMT (#5)
    (Utilizador Info) http://www.floppy.com.pt
    eu uso Qt e estou maravilhado :)
    Qt Designer é muito bom, abre uma consola para fazer o make e correr o teu binario e o qt assistant para veres os tutorias e leres a documentacao das classes e a partir dai tudo o que seja fazer forms é canja ...

    O que me conquistou foi além da facilidade de programar uma aplicacao com >100 forms rapidamnete e a possibilidade de compilar um binario em windows.
    As classes disponiveis estão muito completas e muito bem documentadas coisa que deriva do facto da trolltech ter cerca de 100 funcionarios ...
    A mailing list qt-interest para tirar duvidas tem um trafego de cerca de 100 mensagens por dia e é util para quando se tem um problema ocasional.
    Além disso C++ ainda está aí para as curvas ...
    Re:troll tech (Pontos:2)
    por CrLf em 12-04-04 23:58 GMT (#6)
    (Utilizador Info) http://crodrigues.webhop.net
    deriva do facto da trolltech ter cerca de 100 funcionarios

    76, dos quais uns 30 e tal são vendas e marketing...

    -- Carlos Rodrigues
    Re:troll tech (Pontos:1, Despropositado)
    por racme em 13-04-04 0:24 GMT (#7)
    (Utilizador Info) http://tinyurl.com/2tjh2
    depois vem me falar em os ponto e os bicicreta... que eu doute o meu cartao BP pra ires buscar o teu premio



    make world && !war;
    Re:troll tech (Pontos:2)
    por CrLf em 13-04-04 0:33 GMT (#10)
    (Utilizador Info) http://crodrigues.webhop.net
    Larga a droga, só te faz mal.

    -- Carlos Rodrigues
    Re:troll tech (Pontos:1)
    por racme em 13-04-04 18:38 GMT (#28)
    (Utilizador Info) http://tinyurl.com/2tjh2
    deixa de ser snob



    make world && !war;
    Re:troll tech (Pontos:2)
    por CrLf em 13-04-04 20:49 GMT (#30)
    (Utilizador Info) http://crodrigues.webhop.net
    Conheço-te de algum lado?

    -- Carlos Rodrigues
    Re:troll tech (Pontos:2)
    por racme em 13-04-04 23:31 GMT (#33)
    (Utilizador Info) http://tinyurl.com/2tjh2
    Conheço-te de algum lado?

    pelas tuas afirmacoes devemos estar os 2 a fazer o mesmo tratamento de metadona



    make world && !war;
    Re:troll tech (Pontos:2)
    por higuita em 14-04-04 14:21 GMT (#38)
    (Utilizador Info)
    LOL

    Voces os dois estao a precisar de ferias estao!! 8)

    Higuita
    Re:troll tech (Pontos:2)
    por ruben dig em 13-04-04 20:57 GMT (#31)
    (Utilizador Info) http://www.floppy.com.pt
    sinceramente ao certo não sei quantos são ...
    mas esses valores a que te referes são mencionados numa entrevista no dot.kde.org que foi realizada em Agosto de 2003, mas só foi publicada recentemente
    http://dot.kde.org/1081772638/,
    daí o meu calculo de cerca de 100, é optimista mas não deve estar longe ...
    wxwidgets (ex wxwindows) (Pontos:2)
    por mpinho em 13-04-04 0:26 GMT (#8)
    (Utilizador Info)
    Uma sugestão interessante se quiseres um programa multiplataforma:

    http://www.wxwindows.org/

    Nunca programei com ela mas pelas aplicações que uso feitas com ela, como o xmule e amule, diria que possui muitos recursos e rápida.

    No linux ela usa o GTK+, ou seja, terás a vantagem de programar em C++ como o Qt ou GTKmm e não terás que pagar licenças, sem contar que o código ficará realmente portável (o GTK+ para windows é instável ainda).
    Re:wxwidgets (ex wxwindows) (Pontos:1)
    por cyborgas em 13-04-04 10:10 GMT (#15)
    (Utilizador Info) http://www.justoweb.com
    Alguém conhece algum designer tipo qt-designer, mas para wxwidgets?

    --------------
    Be a good person, adopt a tux!!
    Re:wxwidgets (ex wxwindows) (Pontos:1)
    por Pedro Gato em 13-04-04 10:53 GMT (#17)
    (Utilizador Info)
    Tens vários:
    wxDesigner
    wxGlade
    xrcedit
    mas de todos os que já exprimentei o melhor é sem dúvida o Dialog Blocks
    Foi desenvolvido pelo criador do wxWidgets (Julian Smart) e apesar de ser a pagantes (tens uma versão Evaluation) vale bem os +/- 50 ¤ que custa. IMHO
    Re:wxwidgets (ex wxwindows) (Pontos:1)
    por Antonio Manuel Dias em 13-04-04 10:59 GMT (#19)
    (Utilizador Info) http://maracuja.homeip.net

    Em Python, usando wxPython, podes usar um IDE completo: o Boa constructor.


    "mudem de rumo, já lá vem outro carreiro"
    FOX (Pontos:2)
    por mpinho em 13-04-04 0:29 GMT (#9)
    (Utilizador Info)
    Outra sugestão (mas creio que inferior ao wxwidget):

    http://www.fox-toolkit.org/

    A aparência dos programas feitos com ela é muito boa (veja o link screenshots).


    PyGTK (Pontos:1)
    por gc em 13-04-04 10:29 GMT (#16)
    (Utilizador Info)
    www.pygtk.org
    Java? (Pontos:2)
    por 4Gr em 13-04-04 11:32 GMT (#20)
    (Utilizador Info) http://www.fe.up.pt/freefeup
    Aproveito a questão dos GUI para lançar uma questão à cerca dos GUI designers para Java.

    Actualmente tenho eu de, à la pata, escolher o LayoutManager e trabalhar arduamente com o Content. Resumindo, tenho de desenhar "à mão" o GUI.

    Pelas alternativas que tenho visto, nenhuma é plenamente satisfatória. O Sun ONE Studio (CE) e NetBeans têm um GUI designer mas, das duas uma, ou eu não explorei o suficiente, ou é bastante incompleto. O Eclipse não tem um GUI designer oficialmente suportado e, não faço a menor ideia quanto à qualidade dele. O IDEA ainda não explorei muito, mas gostaria de francamente evitar, dado ser software proprietário (abro uma excepção se for assim tão bom ;-).

    Ou seja, o que eu peço aqui aos entendidos de Java é que me dêm as vossas recomendações para um GUI designer que evite a maçada de ter de escrever o código do GUI manualmente e, já agora, a recomendação de um bom IDE, seja ele proprietário ou livre mas, preferencialmente, livre (tenho usado Eclipse e o SUN Studio, mas infelizmente em termos de GUI, não são espingardas..)

    Dominus vobiscum
    Re:Java? (Pontos:1)
    por SmokeScreen em 13-04-04 13:40 GMT (#23)
    (Utilizador Info)
    Correndo o risco de me repetir: JBuilder.
    IMHO ainda é o melhor IDE para java.. seja ou não para fazer GUI design..
    Já experimentei vários (Incluindo o Eclipse, de que também gosto muito) mas o JBuilder é, para mim, o mais completo.
    Tens é de a) pagar ou b) sacar a versão Foundation que não traz as classes da borland, mas traz a maioria das funcionalidades (não tenho a certeza acerca do refactoring)

    Espero ter ajudado..
    --
    RMO
    Re:Java? (Pontos:1)
    por m16e em 13-04-04 18:34 GMT (#27)
    (Utilizador Info) http://www.m16e.com

    Para resolver esse mesmo problema, criei um pacote de classes que controlam as janelas através de layouts previamente definidos em XML. Podes ver alguns exemplos aqui, numa aplicação que usa extensivamente esse processo (no fim da página há um exemplo do tipo de ecrãs que se podem desenhar).

    Apresenta como grande vantagem não ser necessário recompilar o código de cada vez que se altera a interface. A grande desvantagem é que o código XML (ainda) tem de ser feito à pata, se bem que já esteja automatizado no caso de se pretender reproduzir o conteúdo de una tabela. Outra desvantagem é que (ainda) não está documentado, mas isso pode-se resolver ;-)

    Outra grande vantagem: está publicado sob licença GPL!

    A mesma ideia deverá ser aplicável a código produzido noutras linguagens.


    Re:Java? (Pontos:2, Informativo)
    por Programador em 14-04-04 15:07 GMT (#39)
    (Utilizador Info)
    Em termos de GUI aconselho-te o JDeveloper da Oracle.
    The GUI Toolkit, Framework Page (Pontos:1)
    por bilu em 13-04-04 12:32 GMT (#21)
    (Utilizador Info)
    Podes achar útil: http://www.atai.org/guitool/ Bruno
    Re:The GUI Toolkit, Framework Page (Pontos:1)
    por bilu em 13-04-04 12:33 GMT (#22)
    (Utilizador Info)
    http://www.atai.org/guitool/ o resto era assinatura :P
    GTK vs QT (Pontos:1)
    por henrique em 14-04-04 1:54 GMT (#35)
    (Utilizador Info)
    Se queres melhor espelho do fosso que separa o QT do GTK2, abre uma dialog box de abertura de ficheiros GTKs e compara-a, em aspecto e funcionalidades, com a QT e com QT + extensões KDE.

    Só recentemente os tipos do Gnome têm andado a propôr melhorias para aquele pedaço de esterco que é a dialog box de abertura de ficheiros. É caso para perguntar: só acordaram agora?

    Re:GTK vs QT (Pontos:2)
    por fhc em 14-04-04 9:55 GMT (#37)
    (Utilizador Info)

    Que simpático és! Os teus pais devem estar orgulhosos da tua educação.

    Adiante: o projecto GTK+ esteve envolvido, não com a tua ajuda, na construção de bibliotecas não visíveis, como o gconf, o devhelp, o glib, o bonobo. São bibliotecas de suporte que dão muito jeito ao programador em C e muitas dores de cabeça ao de outras linguagens.

    Só no fim é que se pensou mudar. Que sentido teria construir um belo widget se o paradigma de desktop ainda não estava bem firmado?

    Podemos opinar que o KDE apesar de tudo teve mais sucesso com o seu modelo (agora vejo, amanhã decido).

    Francisco Colaço


    Re:GTK vs QT (Pontos:2)
    por CrLf em 14-04-04 15:50 GMT (#41)
    (Utilizador Info) http://crodrigues.webhop.net
    Só no fim é que se pensou mudar. Que sentido teria construir um belo widget se o paradigma de desktop ainda não estava bem firmado?

    Pode até dizer-se que agora o fileselector do GTK 2.4 é um passo à frente do QT pois permite ser extendido como o programador quiser, podendo até alterar-se o backend do filesystem para poder ter a transparência rede/disco que existe no KDE sem ter de ter um fileselector separado para os dois.

    -- Carlos Rodrigues
    Re:GTK vs QT (Pontos:2)
    por CrLf em 14-04-04 15:44 GMT (#40)
    (Utilizador Info) http://crodrigues.webhop.net
    Eu nunca tive problemas com o dialog de ficheiros do GTK, mas há muita gente que sim, provavelmente por que qualquer coisa que não seja igual ao do Windows não presta... Mas vai buscar o GTK 2.4 e vê.

    -- Carlos Rodrigues
    Re:GTK vs QT (Pontos:1)
    por henrique em 14-04-04 21:38 GMT (#42)
    (Utilizador Info)
    Não é uma questão de ter problemas. É que aquilo é simplesmente primitivo em funcionalidades, e feio, feio, feio.
    O que o GtkFileChooser do GTK 2.4 traz de novo não é mais do que o KDE já tem há anos. E isto ilustra bem o atraso com que o Gnome/GTK ainda vai em relação ao KDE/Qt na maioria das áreas.
    Light vs. Bloat (Pontos:2)
    por CrLf em 14-04-04 22:47 GMT (#43)
    (Utilizador Info) http://crodrigues.webhop.net
    O que o GtkFileChooser do GTK 2.4 traz de novo não é mais do que o KDE já tem há anos.

    No entanto não podes fazer uma simples aplicação em QT que o use sem trazer atrás todo o KDE.

    E isto ilustra bem o atraso com que o Gnome/GTK ainda vai em relação ao KDE/Qt na maioria das áreas.

    Por outro lado o GNOME está à frente do KDE em algumas áreas importantes, especialmente a da usabilidade e da acessibilidade (razão suficiente para excluir o KDE de qualquer uso governamental nos EUA). Em alguns casos o GNOME já lá tem a infraestrutura para fazer algumas das coisas interessantes que o KDE faz (transparência de rede com o gnome-vfs), só não estão generalizadas.

    Mas para mim a maior vantagem que o GNOME tem (e que é a razão da minha última frase) é a sua sociabilidade com o resto do sistema, tentando que as aplicações que usam as suas APIs corram bem noutros DEs/WMs e evitando o bloat em aplicações que queiram apenas usar parte da funcionalidade disponibilizada pela plataforma GNOME. O KDE sofre terrívelmente em ambos os casos; por um lado qualquer aplicação arrancada fora do KDE traz consigo toda uma carrada de tralha (uma coisa tão simples como o kprinter demora um século a arrancar e consome quantidades obscenas de memória) e por outro é impossível usar qualquer API mínima sem ficarmos com dependências de todas as libs do KDE. Isto é uma fantástica vantagem do GNOME, dado que eu posso correr o Fluxbox ou o Window Maker e usar aplicações do GNOME de uma forma normal, ao mesmo tempo que agora uso GNOME e evito como a peste as aplicações do KDE.
    O KDE sofre do síndrome "Not Invented Here" e isso é um handicap tremendo.

    A verdade é esta, tanto o GTK2 como o QT são excelentes toolkits e tanto o GNOME como o KDE são excelentes DEs, mas também é verdade que as aplicações GTK (com peças GNOME) abundam enquanto as aplicações QT praticamente se resumem ao KDE (excluindo as comerciais). A minha explicação é o meu último parágrafo, nada mais.

    -- Carlos Rodrigues

     

     

    [ Topo | FAQ | Editores | Contacto ]