Sem querer gerar um Flame,: Sem querer gerar um Flame, mas o LSB está cada vez pior, tentando padronizar coisas sem sentido, como 'obrigar' todos a usarem RPM e agora a 'QT'.

"Be realistic, ask for the impossible."
Leonardo Lopes Pereira

Muito bom!: Vi a mesma notícia em outro lugar, mas não deu tempo de postar aqui no BR-Linux.

Acho EXCENCIAL a padronização de desktops, pois nesse ponto sistemas como Windows e MacOS obtêm uma certa vantagem: uso das mesmas bibliotecas, ícones, themas, etc, tudo de forma que o desktop fique totalmente homogêneo, o que convenhamos, ainda falta no desktop Linux.

É MUITO chato rodar programas sob a GTK no KDE por exemplo, mas quem usa Gnome sofre ainda mais: rodar programas do KDE nesse ambiente significa carregar lotes de bibliotecas e contrastar com um tema completamente diferente!

Iniciativas como o projeto Tango, uma tentativa de unificar a biblioteca de ícones dos ambientes gráficos, é muito bem vinda, assim como a adoção de padrões oficiais como o respeitado LSB.

Muito boa iniciativa. Parabéns as grandes distros por demonstrarem interesse em adotarem!

----------------------------------------------------------------------------------
A Física é tão subjetiva quanto qualquer outra empresa humana.
Albert Einstein

Qt é opcional: Lembrando que o item que cita o QT faz parte de módulo adicional da especificação do LSB. Não faz parte do core.
http://www.freestandards.org/en/Download#LSB_Qt_4

Atualização:
Mentira... o opcional é o QT4.
O QT3 faz parte do módulo LSB-Desktop.

...: A kdelibs também esta inclusa? Pois são "muitos porém poucos" programas que usam apenas a Qt pura.

Alguém sabe listar as distros que suportam LSB por padrão?

Conheço muito pouco sobre o padrão, mas o pouco que conheço é o bastante para notar que a idéia é boa mas a sua concretização não foi a melhor possível.

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org

Não concordo!: SEI que é chato para quem usa outros empacotamentos, ou bibliotecas, mas a intenção é sempre a melhor!

Aqui utilizo Ubuntu, e nunca tive problemas sérios ao instalar programas comerciais empacotados no sistema RPM. Um exemplo é o programa LimeWire: basta fazer o download, e converter o pacote RPM para DEB, e instalar sem problemas!

Embora seja um pouco chato não ter SEMPRE tudo pronto e feito, creio que o padrão LSB tem objetivos sérios e não adotaria por exemplo o RPM, se não fosse simples e seguro transformar o pacote para outro formato, ou até descompactá-lo e instalar manualmente. Infelizmente não dá para agradar a todos, e os padrões vem para ajudar, e não atrapalhar.

----------------------------------------------------------------------------------
A Física é tão subjetiva quanto qualquer outra empresa humana.
Albert Einstein

contrastar com um tema: contrastar com um tema completamente diferente!

Aqui eu faço o GTK2 renderizar os widgets usando a engine de temas do Qt e, na boa, nao é possível diferenciar um tipo de aplicação de outro. No Debian, é um pacote chamado gtk2-engines-gtk-qt.

Exceto por um detalhe: as aplicações Qt geralmente são mais integradas com outras em drag & drop, cut&paste, etc.

Mas é evidente que a biblioteca Qt é um ambiente de desenvolvimento melhor que a concorrência.

...: O documento que especifica o LSB-QT ainda não foi disponibilizado publicamente, mas acredito que não contemplará as bibliotecas do KDE não.
Senão, seria LSB-KDELIBS ;-)

Essa padronização não se: Essa padronização não se trata de unificação das interfaces. O QT não será o unico toolkit usado nas distribuições que adotarem o LSB-QT. O que ocorre é que, quem optar por segui-la, se compromete a incluir o QT "de fábrica".

Isso se você usa KDE.. se: Isso se você usa KDE.. se você usa Gnome não tem como os aplicativos kde parecerem com o meu Ubuntulooks

Acho que o LSB ainda não nos ajudará no quesito padronização visual entre kde e gnome, apesar de já estarem avançando nesse sentido

"Mas é evidente que a biblioteca Qt é um ambiente de desenvolvimento melhor que a concorrência."

Sinto muito, mas isso já é um GRANDE exagero.

www.darwinawards.com
We salute the improvement of the human genome
by honoring those who remove themselves from it.

Sinto muito, mas isso já é: Sinto muito, mas isso já é um GRANDE exagero.

Elabore.

Mas é evidente que a:

Mas é evidente que a biblioteca Qt é um ambiente de desenvolvimento melhor que a concorrência.

Elabore... ;-)

Não é por nada, mas é: QT e GTK deveriam é ficar de fora, muito provavelmente vou ter no meu sistema qt-3.3 (LSB builtin) e qt-atual, gtk-lsb e gtk-atual... e o X11 como fica, vai entrar na LSB ?

Eu achei que a LSB ficaria responsável por estrutura de arquivos e padroes minimos, quem já configurou um debian, redhat, suse sabe do que eu estou falando, praticamente os tres se diferenciam de tudo. Num é /etc/network/interfaces, noutro é /etc/network-scripts/ifcfg, nunca ví tantos caminhos diferentes em cada distro para fazer a mesma coisa.

Num comentário rápido, sem querer trollar e matar gatinhos (vide http://planeta.ubuntubrasil.org/?author=5)
mas num redhat/conectiva/suse/... é muito dificil usar .rpm de um no outro, tudo bem se a intenção da LSB era apenas para escolher um formato de empacotamento, mas se a intenção foi interoperabilidade entre os sistemas foi um belo tiro no pé, porque passado vários anos, a menos que voce use .spec para recriar um .rpm é praticamente impossivel usar .rpm duma distro na outra. Cada um empacota e quebra os pacotes do seu jeito, até aí tudo bem se não fosse tambem mudar os nomes para complicar as dependencias.

Ainda não ví a LSB dizer a que veio, vamos ver se nessa versao as distros resolvem realmente mudar as coisas, eu acho que não, mas vamos esperar...

Perguntei primeiro!: Perguntei primeiro!

Elabore vc que elaboro eu depois.

LSB: Também acho que a padronização da árvore de diretório é muito mais importante do que definir os pacotes básicos que uma distro deve conter.
De qualquer forma, a intenção deles é garantir que se a pessoa tem uma distro certificada em LSB versão X, sua aplicação sabe que ela possui certos pacotes e não precisa se preocupar com dependencia deles. A idéia é tirar a dependencia dos pacotes e passar a usar a dependencia do LSB na versão específica, simplificando a instalação de produtos no Linux.

Exato!: Pelo menos para mim é assim que vejo a LSB: uma base de softwares + alguns outros padrões.

Um bom exemplo é o Mandriva: na hora da instalação vc pode escolher instalar a base LSB, ou não. Em outras distros como Debian/Ubuntu, RedHat/Fedora e SuSE o padrão LSB deve ser instalado automaticamente.

Ainda: sei que o padrão LSB não veio para unificar os desktops, mas ainda é um padrão. Isso "dita" de certa forma como devem ser os desktops, homogenizando-os.

----------------------------------------------------------------------------------
A Física é tão subjetiva quanto qualquer outra empresa humana.
Albert Einstein

O cara disse que a: O cara disse que a biblioteca QT é a mais completa para desenvolvimento de software???

O forte do QT é simplesmente a biblioteca gráfica deles. É extremamente limitada a variedade de componentes que ela usa.

Qt nem se compara ao mono e ao jdk em componentes, só pra citar os mais famosos, e quando se fala em biblioteca gráfica, o Gtk é muito mais consistente, mas isso já é questão de gosto pessoal.

Qt pode ser comparado ao Gtk, e os dois ficam tecnicamente empatados, eu diria assim. Mas querer dizer que o Qt é a biblioteca de desenvolvimento mais completa é uma insanidade!!

Não elaborei antes pois isso parecia óbvio demais!!

www.darwinawards.com
We salute the improvement of the human genome
by honoring those who remove themselves from it.

O forte do QT é: O forte do QT é simplesmente a biblioteca gráfica deles. É extremamente limitada a variedade de componentes que ela usa.

Que crack é esse q vc anda fumando, e pq nao divide com a gente???

Qt além dos widgets gráficos tem:

1 - uma implementação de canvas
2 - parsers XML (DOM e SAX)
3 - sockets
4 - um widget OpenGL q pode ser utilizado como qualquer outro widget
5 - um módulo para acesso a bancos de dados SQL com drivers plugáveis
6 - MDI verdadeiro com workspace próprio e janelas clientes dimensionáveis
7 - classes para manipular data e hora
8 - uma classe string com suporte nativo a Unicode e conversão a outros codesets
9 - diversas estruturas de dados legais: filas, pilhas, listas, maps, dicionários, etc.
10 - classes para manipular impressão
11 - implementações de FTP e HTTP
12 - expressões regulares
13 - threads independentes de plataforma
14 - look 'n feel independente de plataforma
15 - um framework de acesso a som e vídeo
16 - tratamento de mimetypes
17 - biblioteca de templates
18 - um widget com suporte a display de hipertexto
19 - navegador de documentação integrado, mais uma PUTA documentação completa bagaráleo
20 - um editor de diálogos MUITO completo, que gera diálogos em XML, que podem ser carregados sob demanda
21 - mais uma caralhada de coisas q nao lembro.

Tudo isso daí na instalação padrão.

Pra ter essa funcionalidade toda aí em Gtk, eu tenho que baixar quantas bibliotecas?

Em quê isso daí é diferente desses frameworks tipo Java e .NET? Não vem a mesma coisa neles também? Qual é a diferença? É ruim pq não é interpretado?

É tão superior em absolutamente tudo, é até covardia comparar.

Eu poderia elaborar mais e dizer que Python + Qt é a plataforma de desenvolvimento de software genérico definitiva , mas aí já é outro assunto.

LSB devia padronizar a: LSB devia padronizar a árvore de diretórios, e não os pacotes.

A única coisa obrigatória (que caracteriza um sistema Linux) é o kernel e o core-utils (utilitarios e shell GNU).

Qualquer outro programa decorrente de outros pacotes não deveria ser padronizado, sob pena de diminuir a liberdade de escolha.

Esse lance de incluir o Qt, por exemplo. Eu uso ubuntu, e não uso nenhum programa em Qt (uso XFCE + programas do gnome), e consigo fazer todas as minhas tarefas sem problema. Isso me deixa fora da LSB?

Quanto ao rpm. Isso é legal de padronizar sim, pois vai de encontro com a padronização da estrutura de diretórios. Assim, vc pode converter o pacote para .DEB para manter as dependências mantidas, e como o .RPM instalava na estrutura padrão, a instalação não ficaria prejudicada. E vice-versa.

Não concordo contigo que: Não concordo contigo que padrões vêm para ajudar. Acho que "vem para restringir" seria algo mais apropriado. Não o restringir no sentido bruto da palavra, mas talvez num sentido um pouco mais leve.

Quanto a pacotes e bibliotecas, acho que cada distro deveria usar aquilo que acha que é melhor para ela. Nada de ficar "impondo" restrições e limitando o uso de tal biblioteca, de tal sistema de pacotes, etc.

Tenho a opinião de que liberdade não se relaciona muito bem com padrões =)

QT x GPL de novo! :D ahauhua: 6 - MDI verdadeiro com workspace próprio e janelas clientes dimensionáveis

Lembrando que pra muitas pessoas isso é uma desvantagem, não uma vantagem. E a afirmação do tal "MDI verdadeiro" é controversa, pois MDI significa apenas multiple document interface e existem várias maneiras de conseguir isso. O tal workspace próprio até onde eu vi é considerado uma das maneiras menos elegantes de consegui-lo, geralmente.

E lembrando também que as bibliotecas do gnome, não só a gtk+, tem muitos (senão todos) os tipos de serviços/componentes/facilidades que você citou para a Qt, só que separados em diversas bibliotecas diferentes. Existem vantagens e desvantagens em ambas as abordagens.

Existe muita coisa na Qt também que a torna "não tão boa quanto aparece nos folhetos", como o pré-compilador próprio dela (o moc) e alguns outros detalhes.
--
Dicionário rápido para o br-linux:

• É exceção e não excessão.
• É licença e não licensa.
• É discussão e não discursão.
• É opinar e não opnar.

Cuidado, coisas que voce: Cuidado, coisas que voce citou vem da implementação do ambiente gráfico/programas e não da QT.

MDI tem ao estilo Gimp, tem no estilo Tabs, tem no estilo Agrupamento de Janelas, e tem no estilo a-la-msword. Eu gosto mais dos Tabs, muita gente que usa MDI no msword acha que esta apenas com um documento aberto quando na realidade esta com vários, eu acho esse estilo de MDI um saco, mas se tem gente que defende então é porque é agradável a alguns. Então MDI é uma implementação ao gosto do programador.

Biblioteca decentralizada ou centralizada, outro ponto de vista onde há margens para gosto do freguez. Para quem inicia no mundo da programação não há dúvidas de que tudo centralizado é bem melhor, mas para quem é rato de programação prefere que as bibliotecas sejam decentralizadas. O kdecore (kdelibs) é uma API bem completa que deixa a vontade programadores iniciantes, mas centralizadora. Se no KDE fosse tudo QT e não existisse kdelibs, ninguem reclamaria do 'k3b' no gnome. Aplicativos gtk (abiword, gimp,...) normalmente decentralizados não pesam no kde, mas o inverso é verdadeiro.

Comentários como o seu tentando apontar um melhor que o outro é no mínimo acender uma vela no meio duma floresta e rezar para que Deus conserve a natureza.

Cuidado, coisas que voce: Cuidado, coisas que voce citou vem da implementação do ambiente gráfico/programas e não da QT.

Não viaja cara, tu tá chapado também igual o figura ali de cima? TUDO que eu citei está na distribuição padrão da Qt. Tá tudo na documentação:

http://doc.trolltech.com/3.3/index.html

Procure qualquer coisa que eu citei que não esteja documentado aí.

Então MDI é uma implementação ao gosto do programador.

O simples fato da Qt implementar _todos_ os tipos de MDI, e o outro toolkit concorrente nao, já o torna melhor nesse quesito.

Para quem inicia no mundo da programação não há dúvidas de que tudo centralizado é bem melhor

Qualquer pessoa racional sabe que ter tudo centralizado numa API é melhor. Vc acha bom ter várias e várias bibliotecas separadas para funcoes minimas? E que na maioria das vezes tem pouca ou nenhuma documentação? E se, por exemplo, uma biblioteca que faz, sei lá, parsing de um formato de arquivo X, passar por uma revisão onde a API externa dela muda, e seu programa pára de funcionar? Como fica?

Pq nao ter tudo numa biblioteca só, como módulos plugáveis? Se nao precisa do módulo, simplesmente nao inclui. Qt faz isso.

É evidente que Qt é melhor.

E se, por exemplo, uma: E se, por exemplo, uma biblioteca que faz, sei lá, parsing de um formato de arquivo X, passar por uma revisão onde a API externa dela muda, e seu programa pára de funcionar? Como fica?
Esse argumento é seu pior inimigo, porque a API da QT vai mudar e tem de mudar de um jeito que não quebre a retrocompatibilidade, por isso o termo bloat ao kdelibs. Modelos decentralizados geram dependencias se necessario, ou carregam consigo as funcoes triviais de funcionamento, a idéia é ter menos dependencia possivel. Se usar o gimp, gftp, abiword vai reparar que o modelo decentralizado propriciou aplicativos crossplataform com muito pouca dependencia e que rodam bem em qualquer ambiente gráfico. A menos que o kdelibs seja portável a outro lugar, nenhum aplicativo o será.

Qualquer pessoa racional sabe que ter tudo centralizado numa API é melhor.

Então provavelmente muitos de nós não são racionais, como não sou racional não preciso discutir com voce.

Programadores deveriam ser seres com a mente mais aberta factivel com a inteligencia esperada, mas quando encontram a dita panacéia mitógica digital...estão presos. É como aquele peixe que vive no fundo do mar (esquecí o nome para variar) assim que encontram uma área segura e com bastante planctuns se encostam numa pedra, criam raizes e digerem seu próprio cerebro, porque ? porque não vão precisar utilizar novamente, já encontraram o que buscavam. O programador acima parece que encontrou a QT e não existe nenhuma outra hipotese melhor.

por isso o termo bloat ao: por isso o termo bloat ao kdelibs.

Qualquer pessoa que pare para comparar a enorme funcionalidade do KDE com a funcionalidade do Gnome, e fizer a relação entre o custo de processamento e memória dos dois, vai ver que quem é inchado (bloated) não é o KDE.

O programador acima parece que encontrou a QT e não existe nenhuma outra hipotese melhor.

E nao existe mesmo. Até que alguém mostre uma API com mais funcionalidade e modularidade q a Qt na mesma categoria, utilizando argumentos TECNICOS e LÓGICOS (nao achismos, que aqui já há um monte), ela continuará sendo a melhor.

O problema é q aqui no BR-Linux nego colocou na cabeça essa idéia ridícula de que nao existem softwares melhores do que os outros, provavelmente para ficar bem na fita com a tal da comunidade, que parece que está num surto coletivo de conduta politicamente correta.

Existem softwares melhores que os outros sim, e a Qt é.

Vantagens e desvantagens: O problema é q aqui no BR-Linux nego colocou na cabeça essa idéia ridícula de que nao existem softwares melhores do que os outros, provavelmente para ficar bem na fita com a tal da comunidade, que parece que está num surto coletivo de conduta politicamente correta.

Existem softwares melhores que os outros sim, e a Qt é.

Relativismo cultural é uma merda mesmo, assim como a idéia tosca de politicamente correto. Mas reconhecer que existem diferentes pontos de vista não é necessariamente a mesma coisa. Por exemplo, eu disse que existem vantagens e desvantagens no enfoque centralizado da qt+kdelibs e no enfoque descentralizado das bibliotecas Gnome. Acredito, no entanto, que um dos enfoques tenha mais vantagens, e vantagens mais abrangentes do que o outro; pra citar um caso simples, é óbvio que o enfoque de microkernel, em geral, é bem mais vantajoso que kernel monolítico. Só que o juízo de valor de cada vantagem é subjetivo e dependente da situação: em um processador sem multitasking e com uma arquitetura mínima, fazer um microkernel pode ser uma insanidade. Do mesmo jeito, embora eu ache que o KDE é em geral superior e as bibliotecas QT melhores para programar do que as Gnome, nunca farei uma advocacia adequada desta minha escolha se não reconhecer os pontos fortes da outra.

Outro ponto a se discutir é um ponto quase filosófico, na verdade; a idéia de que ter total liberdade, ou tudo à disposição, é melhor do que ter um conjunto restrito de coisas "corretas" a fazer. O Java, por exemplo, prende o desenvolvedor dentro de um conjunto de restrições da linguagem. O C++ segue outro caminho, sendo extremamente flexível nas possibilidades. Do mesmo jeito, a QT - ou, citando o exemplo mais conhecido, a MFC - pode estar dando muita corda para os desenvolvedores, a ponto de eles enforcarem os seus produtos; o modo MDI de janelas dentro de janelas é confuso, sim, e como está lá muito desenvolvedor acaba utilizando. Eu posso dizer que sou "adepto" do enfoque de limitações, pois na prático tenho visto esse enfoque funcionar melhor. Desenvolvedores não deveriam precisar ser peritos em psicologia de interfaces para escolher um modelo de MDI correto, e a existência de controles sintáticos/léxicos do código na linguagem Java acaba levando a código limpo e compreensível em programas escritos nela mesmo por amadores, muito mais do que em uma C++.
--
Dicionário rápido para o br-linux:

• É exceção e não excessão.
• É licença e não licensa.
• É discussão e não discursão.
• É opinar e não opnar.