Desktop: Acho que estou viajando, mas o Linux já é melhor que o Xupeta como desktop. O problema são as aplicação e os codecs. Quer dizer não são um problema tão grande apenas esbarram em resistências legais e culturais.
Existem coisas que já existem no Linux faz muito tempo, que a M$$ vem se quebrando para implementer. Um exemplo é o supercaramba, que eles assim como a Apple, vão implementar no novo Windus Xifrudo e dizer que é a salvação da lavoura.

E não é só isso...: Já ouvi falar que o Windows virá com 4 interfaces gráficas (dependendo do micro, algo KDE, GNome, Xfce, ICewm :) ). E vi num screenshot do suposto Longhorn algo parecido com áreas de trabalho que existe no Linux quase do tempo da sua primeira interface gráfica, anos atrás.

Tradução Livre:
Como o titulo diz é tradução livre, não segui ao pé da letra
mas acho que mantive idéia original. Se acharem legal podem
copiar para outro lugar ( site, blog, etc ... ) se não
imprimam e usem como papel higiênico para demonstrar
a sua insatisfação : )

-----------------------------------------------------------


Quarta, 15 Junho, 2005

O Dektop Linux do Futuro - Parte 1

Categoria: Design Conceitual

Este artigo é parte de uma série de quatro que tem a intenção de prover algumas idéias em como um futuro Desktop Linux deve funcionar. Isto não tem a intenção de ser um ensaio abrangente, embora todos os conceitos apresentados aqui possam ser considerados "possíveis" pelo autor.

Parte 1: Linux e o Desktop Hoje
Parte 2: Aplicações
Parte 3: Gerenciamento de Arquivo
Parte 4: A Interface do Desktop

Parte 1: Linux e o Desktop Hoje

Apesar da constante previsão que "Este ano será o ano do Desktop Linux", tais previsões ainda tem que se tornar realidade. Apesar das razões para isto serem numerosas, elas tendem a reduzir o Linux a ser construído comum sistema operacional para servidores e estações de trabalho ao invés de um sistema desktop. Este artigo irá focar em como uma distribuição pode ser projetada não apenas para se tornar uma competitiva solução para desktop, mas direcioná-la a uma liderança no mercado de desktop.

Fraquezas do Linux

Através de uma rápida revisão das características do Linux, alguém
pode chegar a seguinte lista de itens que tornam o Linux uma escolha
pobre para o uso como desktop :

1. Instalação de Aplicações é complicada.
2. Estrutura de Diretórios pode ser confusa para navegar.
3. Interface é confusa e inconsistente.
4. Curva de aprendizado longa para entender as funções do sistema.

O primeiro ponto é um assunto complexo, mas na maioria das vezes deriva do uso dos gerenciadores de pacotes. Gerenciamento de Pacotes é um daqueles conceitos que parecem grandes na teoria, mas falham na prática. O caso é que cada pacote tem uma complexa cadeia de dependências únicas a ele. Para estar certo de que um pacote é compatível com toda a instalação, todas as combinações de pacotes instalados devem ser testadas ! Como não é provável que alguém terá tanta preocupação, as incompatibilidades entre pacotes se acumulam, e logo o sistema de pacotes estará rejeitando novas instalações.
E isso assumindo que um instalador gráfico exista !

Se um instalador gráfico não existe, então a vida se torna mais difícil para o usuário. Ao invés de executar uma GUI e selecionar as aplicações que deseja, o usuário deve abrir um terminal e iniciar a digitação de comandos ocultos nos quais ele não tem treinamento.

Muitos advogados do sistema de pacotes subestimam este assunto declarando que erros em pacotes não existem no sistema XYZ ( apesar de prova do contrário ), e que se o usuário está rodando Linux ele deveria ser "inteligente o bastante" para saber usar a linha de comando. Esta frase é tola. Usuários querem que o computador torne sua vida fácil. Qualquer obstáculo impedindo este objetivo apenas os direciona a uma plataforma diferente. Infelizmente, gerenciadores
de pacotes ainda guiam a maioria das distribuições Linux para desktop.


O segundo ponto é causado pela disposição aberta dos sistemas de arquivo do Linux. Esta disposição tem a intenção de facilitar o aspecto multi-usuário do sistema Unix. Infelizmente, complica bastante a visão que o usuário tem do sistema. Usuários experientes estão acostumados a ter um diretório raiz com alguns diretórios de sistema para se preocupar. Para usuários novos, mesmo um diretório de sistema pode ser um assunto de grande importância. ( Eu estou certo de que todos nós já vimos ou ouvimos sobre aquele cara que deletou seu diretório Windows e esperava que tudo funcionasse perfeitamente.) Esperar que esses usuários entendam o significado de diretórios "usr", "bin", e "etc" é um pouco demais. ( A ferramenta de procura ( Finder ) do Mac OS X na verdade os esconde.)

Os pontos 3 e 4 são causados particularmente por interessantes decisões na comunidade Open Source, permanente discussões sobre projeto de interface, e software de qualidade beta sendo empacotado nos lançamentos da distribuição. (Red Hat é particularmente culpada nesse último.) Por exemplo, existe um único, diretório não oculto no Windows onde Atalhos do Menu Iniciar são armazenados.
Este diretório pode ser acessado através de um clique com o botão direito no Menu Iniciar e selecionando "Abrir". Apesar do projeto do Windows ser uma interface confusa, no mínimo ela é consistente. No GNOME e KDE, o diretório do menu tem sido movido várias vezes, indo e voltando entre a estrutura GUI, Gerenciador de Arquivo, e menu Drag/Drop, e eles tem estado divididos se itens de menu específicos por usuário devem ser criados ou não. A maioria desses assuntos tem sido amenizados em algum grau, as não sem deixar os usuário completamente confusos.

Com estes problemas em mente, vamos propor algumas idéias sobre como
podemos consertá-los.

"Esperar que esses usuários: "Esperar que esses usuários entendam o significado de diretórios "usr", "bin", e "etc" é um pouco demais. ( A ferramenta de procura ( Finder ) do Mac OS X na verdade os esconde.)"

No Xandros a estrutura também é escondida, mas facilmente acessivel. Ficou até legal.

Mas a questão da instalação de novo software é um problema serio !

Compilar estaticamente onde possivel - e incluir as libs quando não - ajudaria muito, mas ninguem faz isso. Portage, apt-get e similares são ótimos para empresas, mas estão totalmente fora da realidade quando se fala em uso domestico de Linux.

Plasma (Novo projeto de ambie: Plasma (Novo projeto de ambiente do KDE 4) http://plasma.bddf.ca/
Quer dizer que ter ~ 17.000 pacotes binários em um repositório único com acesso a chaves de assinatura a um click do mouse não é bom para o usuário doméstico?
Concordo que os "programas" deveriam ter suas dependências armazenadas na sua própria pasta, por exemplo: /usr/Firefox/lib/bla bla bla 2.3.c.
Isso apenas se não existir um binário feito para tal versão.
Nós vemos os aplicativos se desenvolvendo rapidamente e se você notar o GNU/Linux é extremamente "bleeding end" do que outros sistemas.
Veja quanto tempo o Windows está ai sem atualizações, o que seria comparável ao Debian Stable (mas o debian stable é realmente stable).
Unificar o sistema de pacotes pode trazer problemas maiores como a dissiminação de vírus, o que obrigaria uma revisão na segurança do sistema.
Ainda sim não acho um problema esperar um pouco para ter pacotes confiáveis e com apenas uma dependência em comum a tornar o sistema um coleção interminável de dependências...
Pior ainda, manter um sistema que possui mais de um versão de uma biblioteca, atualização atrás de atualização.
Não sou a favor de compilação estática. Há programas que o fazem como o Blender, NVU, ktoon etc. Por causa disto eu vou mudar para o gentoo em breve, que na minha opinião, apresenta um sistema de pacotes mais desenvolvidos que os outros (apesar de o apt-get ser excelente e NUNCA ter dado UM ERRO se quer comigo).
Já ouvi relatos de pessoas que usaram SuSE durante 4 anos seguidos e NUNCA tiveram de compilar nada, preferiam esperar a próxima versão com os binários atualizados. No linux (e outros unix) o usuário sabe MUITO mais do seu sistema porque PODE saber, está lá pra todo mundo ver, não é opção. Mas ainda sim ele pode se restringir apenas ao básico (a seu interece). Por exemplo, eu não preciso saber como fazer o setup de servidor DHCP (porque não teria utilidade pra mim), mas saber como controlar os módulos do kernel, configurar o grub, refinar o xorg etc eu quero (apesar de não ser vital para minha experiência com Linux).

Que nome eles darão para ess: Que nome eles darão para essa nova "maravilha tecnológica" ""exclusiva"" da M$?

Super UAU?!?!?!?
Super Supimpa?!?!?!?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA

Acho que você tocou em um po: Acho que você tocou em um ponto importante, mas que passa despercebido por muitos: geralmente, os pacotes considerados estáveis são de versões considereadas "defasadas" com uma diferença de dois números para a versão mais recente.

O que acontece, a meu ver, é que os usuários "finais" têm a mania M$ de estar sempre com a última versão do programa em questão. O que no windows pode parecer a salvação da lavoura, no Linux pode esconder algumas armadilhas, pois nem sempre os programas mais recentes são os melhores, ou estão estáveis o suficiente para que sejam utilizados por todos. Por isso mesmo a maioria dos grupos de desenvolvedores (inclusive o grupo do kernel) avisa que tais programas são recomendados para os entusiastas ou os "testadores".

Não acredito que a abordagem dos gerenciadores de pacotes seja falha, com certeza ainda há um bom caminho a ser seguido para que seu uso seja fácil para aqueles que não conseguem lembrar de meia dúzia de comandos.

O artigo está muito bom, mas como lista de presentes. Realmente, para que atinga as massas a Interface gráfica do Linux, e a dos outros sistemas operacionais ainda têm que evoluir muito, mas junto com as mesmas algumas tecnologias têm que evoluir junto, por exemplo: reconhecimento de comandos por voz, e síntese da fala, biometria, a p?opria apresentação dos programas terá que mudar, talvez utilizando-se o papel digital, ou quem sabe projeção holográfica no ar, além da própria educação dos usuários para lidar com essas interfaces.

Acho que a tendência é que falemos com os computadores como falamos uns com os outros, mas até lá ainda tem muito chão pela frente.

E quem sabe do futuro afinal? Tem um tal de Dvorak que não dá uma dentro desde o século passado :P

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA

__Não acredito também que a: __Não acredito também que a questão de empacotamentos seja falha. A maioria das distros jás vêm com gerenciadores de pacote que simplificam a vida do usuário.O RPM Drake do Mandrake (mandrika).O Synaptic do Debian. FOra a vantagem enorme que o usuário tem de instalar dez programas de uma tacada só!Algué já viu por acaso o Klik do Knoppix??Não preciso falar dos ícones mágico do MOrimoto no Kurumin...VOcê instala tudo com um Clique de mouse na maioria das boas distribuições linux hoje em dia.Na pior das hipóteses terá que usar o Kpackage. . .

__O problema é que o usuário não tem os atalhos mentais do Windows.No Linux ele encontra OpenOffice, Kword, GImp,Inkscape, XIne.Que são programas desconhecidos dos usuários do sistema M$. Mas isso não pode ser culpa da comunidade!

-: Esse negócio das entradas de menu do GNOME/KDE são veridicos. A cada versão isso parece mais real ainda. Parece ser um problema tão crônico que a versão recente do GNOME foi introduzida sem um editor de menus (ok, instale o smeg separadamente), teria sido esquecimento ou eles estão esperando ambos se adequarem ao freedesktop ?
Na *minha opnião*, os aplicativos virem de forma uniciente, ou seja, com as bibliotecas (sejam links simbolicos ou reais) inclusas facilitaria o endendimento (instalação, atualização, configuração, segurança,...) desses programas.
O linux tá crescendo assustadoramente com muitos programas e se voce lista o /usr/lib tá lá tantas coisas que voce definitivamente nao sabe de quem é quem, então é melhor nem tentar mexer, por isso algumas aberrações como /usr/lib/mozilla que vem bibliotecas, binarios, icons, ...
Para mim se tem algo que é bom e é melhor nem mexer então deveria ficar escondido ou acessivel apenas por quem conhece. Mas realmente a estrutura do linux tá mudando, já estou vendo além dos instaladores do mozilla, outros programas usarem suas proprias pastas.

Partes 2 3 4:
P.S.

O Artigo é grande, as demais partes estarei
postando durante a semana.

Mas o Gobolinux que foi menci: Mas o Gobolinux que foi mencionado acima, tem umas ideias interessantes... na "teoria" parece ser um modo pratico de gerenciar programas e a hierarquia do sistema de arquivos... nunca utilizei o mesmo, e se alguem ja utilizou poderia fazer o favor de postar algum comentario sobre o Gobolinux... no meu ponto de vista achei que é uma boa ideia.

libs: "Compilar estaticamente onde possivel - e incluir as libs quando não"

isso é terrível! fico imaginando como o tal GoboLinux faz: cada aplicativo inclui as libs de que precisa? não há compartilhamento de código?? que horror!! espero que não seja o caso e eles mantenham algum cache de algum tipo, funcionando algo como os caches dos gerenciadores de pacotes?


senão, imagina:
/usr/Firefox/libs/libxml2.so
/usr/Gnome/libs/libxml2.so
/usr/Inkscape/libs/libxml2.so
/usr/Scribe/libs/libxml2.so
.
.
.

ugh... nesse caso, eu preferiria até que fosse compilado estaticamente...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Projeto livre: Não há necessidade de ficar imaginando como o GoboLinux faz, e aí criticá-lo a partir de hipóteses como esta. Trata-se de um projeto aberto, você pode ver como é a estratégia adotada. Na FAQ (http://www.gobolinux.org/index.php?lang=pt_BR&page=faq) tem um resumo sobre as consequências da estratégia adotada, do ponto de vista de seus desenvolvedores. Esta outra página (http://www.gobolinux.org/index.php?lang=en_US&page=doc/articles/clueless) também é leitura interessante para quem quer saber algo mais sobre o sistema.

Gobolinux: gostei!: Instalei essa distribuicão no início do ano em meu computador. Usei poucas vezes, mas ainda está instalado. Pelo que experimentei, é bom, estável e, principalmente, prático de usar e manter.

O projeto aproveita algumas particularidades dos sistemas de arquivos ext2 e ext3 para, a partir de uma modificacão no núcleo do sistema operacional, criar um sistema de links eficiente, em que há apenas um link para cada arquivo, em uma estrutura de diretórios intuitiva, simples e muito bem organizada.

Os pacotes dos códigos-fonte contêm scripts de instalacão que referem os arquivos e diretórios mais importantes através de variáveis, o que facilita a compilacão do programa não apenas no Gobolinux.

Pretendo voltar a usá-lo de forma efetiva a partir do próximo mês.

Pacotes de programas: Na minha experiência de usuário comum do GNU/Linux (sim, isso existe!), a gestão de instalar programas via pacotes tem um ponto forte:
controlar as dependências entre programas e bibliotecas
e tem um ponto fraco:
impôr dependências entre programas e bibliotecas.

Dependendo da distribuicão, bibliotecas que são opcionais para um determinado programa são vinculados, no momento da compilacão do programa, como obrigatórios. Já me vi obrigado a, ao instalar programas feitos em GTK com suporte *opcional* às bibliotecas do Gnome, instalar também as bibliotecas do Gnome porque o programa distribuído no pacote foi compilado para rodar *obrigatoriamente* sob o Gnome.

Isso me motiva a querer experimentar distribuicões que permitem a escolha das bibliotecas a usar, ao custo de ter que compilar todos programas.

Para quem não precisa se importar em ter uma profusão de arquivos no computador, os gestores de pacotes estão bastante aprimorados. Mas para quem necessita controlar a quantidade e o peso de rodar certos programas, principalmente em computadores não tão potentes, toda a vinculacão desnecessária é um luxo imperdoável.

Bibliotecas gráficas: Tenho uma queixa a fazer sobre as biblotecas em ambiente GNU/Linux: o exagero de bibliotecas gráficas diferentes.

Não é difícil acontecer de um conjunto programas usados por uma pessoa necessitar de diversas bibliotecas gráficas diferentes: alguns programas que rodam em OpenMotif, outros em Lesstif, outros em GTK, outros em GTK2, outros em QT, outros em FLTK, outros em FOX, outros em KDE (que dependem por sua vez do QT), outros em Gnome (que dependem por sua vez do GTK ou GTK2). Ainda tem outras bibliotecas, como Tcl/Tk, Xforms, xwWindows e as do WindowMaker. Sem falar em programas que usam bibliotecas gráficas próprias, como o OpenOffice.

Um pouco de padronizacão no uso de bibliotecas gráficas não seria uma má idéia.

O preço da escolha: Ah, mas isto é o preço pela liberdade: cada um faz o que quer dentro de um padrão de qualidade :) No fundo, não é muito diferente do Windows, onde todos os programas carregam suas próprias DLLs, geralmente repetidas. A diferença é que aqui nós o fazemos com mais inteligência - e, portanto, com mais sofisticação, o que tem seu lado ruim...

--
Adam Victor Nazareth Brandizzi
Estudante de Ciência da Computação - UnB
Jabber: brandizzi@jabber.org
"Real programmers don't use Pascal; just integer ones can do it."

Mais Inteligência?: Não sei porque, são duas coisas iguais, ter várias dependências ou ter várias Dlls. Pelo menos no Windows as Dlls são independentes e não requerem que seja instalado a versão 1.1.2.1.2.3.4.xxx.xx de tal dependência sendo que a mesma não funciona com outro programa que ja foi instalado.

Este assunto ja foi discutido várias vezes é o preço da liberdade, que todos querem ser o pai da criança e fazem várias libs gráficas com a mesma funcionalidade, fracionando o desenvolvimento e chegando a lugar nenhum.

É uma pena mais isso que trava o Linux no Desktop e continuara assim, até quem sabe um dia uma Apple da vida consiga migrar o seu ambiente gráfico para PCs e tome conta do mercado, ou o Windows de tanto errar acerte e mate de uma vez por todas o Linux no Desktop, deixando este ótimo SO apenas nos servidores onde hoje por ter um desenvolvimento mais centralizado (Kernel) mostra todo o poder da comunidade.

Ja a parte gráfica...

-: Existem aplicativos como os da serie mozilla que possuem instalador próprio que instalam bibliotecas, icones,... no próprio diretório de instalação, semelhante ao windows. Então é a liberdade que sugere o que deve ser feito. Se todos desejassem poderia ser igual ao windows, mas a maioria deles prefere um jeito diferente a-la-unices mesmo. A liberdade tem um custo.
A apple é um mal exemplo, porque exatamente como o linux tem tambem o jeito unices-like e tem o jeito mac-like arrastando uma pasta com todas as dependencias já supridas e ainda o jeito windows-like com next->next->finish.

Gentoo é o que vc precisa me: Gentoo é o que vc precisa meu caro! :)
Acho que é a única que permite vc escolher se vai ou não querer estas opções.

Como é horrível ser prático! (?): ¨A apple é um mau exemplo, porque exatamente como o linux tem tambem o jeito unices-like e tem o jeito mac-like arrastando uma pasta com todas as dependencias já supridas e ainda o jeito windows-like com next->next->finish.¨

Não tenho como concordar que a Apple é um mau exemplo por ser prática e consistente.

E liberdade implica em responsabilidade. Apostar em diversas bibliotecas gráficas ao mesmo tempo é pedir para complicar a manutencão do desempenho e da interoperacão do sistema. Basta observar que os aplicativos em modo texto não sofrem de tamanha síndrome de repeticão de funcionalidades. Cada componente faz um papel específico e bem-feito. O mesmo deveria ser observado no desenvolvimento de aplicacões em ambientes gráficos.

> Este assunto ja foi discuti: > Este assunto ja foi discutido várias vezes é o preço da liberdade, que todos querem ser o pai da criança e fazem várias libs gráficas com a mesma funcionalidade,

Dizer que "todos querem ser o pai da criança" é a explicação para a existência de n bibliotecas gráficas é no mínimo insensatez. De fato pode existir isso, assim como existem linguagens, programas, documentos e máquinas criados sob esta motivação banal. Contudo, é um erro tremendo partir para a generalização.

Outro equívoco é pensar que fornecem "a mesma funcionalidade". Embora os componentes gráficos parecem entre si (botões, abas, menus, etc.), internamente bibliotecas gráficas podem diferir e muito, mesmo em uma mesma linguagem. Essa diferença "não visível" pode traduzir por exemplo em menor esforço de programação, facilidade de depuração, clareza do código, melhor desempenho em tempo e espaço e, principalmente, maior estímulo do desenvolvedor.

> fracionando o desenvolvimento e chegando a lugar nenhum.

Fracionando o desenvolvimento de quê? Por exemplo, o K3B é um excelente aplicativo de gravação de mídias desenvolvido em Qt, enquanto o GIMP é um consolidado programa gráfico de manipulação de imagens desenvolvido em GTK. Uso ambos normalmente: esforço somado, não fragmentado.

> É uma pena mais isso que trava o Linux no Desktop e continuara assim

Pode explicar o porquê?

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

> Apostar em diversas bibliot: > Apostar em diversas bibliotecas gráficas ao mesmo tempo é pedir para complicar a manutencão do desempenho e da interoperacão do sistema. Basta observar que os aplicativos em modo texto não sofrem de tamanha síndrome de repeticão de funcionalidades. Cada componente faz um papel específico e bem-feito. O mesmo deveria ser observado no desenvolvimento de aplicacões em ambientes gráficos.

Você está misturando as coisas. Repetição de funcionalidade não tem a ver com a disponibilidade de bibliotecas gráficas, mas tão somente com a vontade do autor de "replicar" (seja lá qual a motivação) um aplicativo.

E você se engana de que no modo texto não existem "variações sobre o mesmo tema". Procure, por exemplo, pelas variantes do comando 'grep'; os inúmeros compactadores de arquivos, etc.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Variaões do mesmo tema: Em primeiro lugar, não falei que não há variacões de programas que fazem a mesma coisa em ambiente texto. Eu escrevi que o as variacões não são tantas.

Você cita os compactadores de arquivos. Os formatos mais usados por muitos são zip, tar.gz e tar.bz2. Os outros na prática são dispensáveis.

Por quê?: > > fracionando o desenvolvimento e chegando a lugar nenhum.

> Fracionando o desenvolvimento de quê? Por exemplo, o K3B é um excelente aplicativo de gravação de mídias desenvolvido em Qt, enquanto o GIMP é um consolidado programa gráfico de manipulação de imagens desenvolvido em GTK. Uso ambos normalmente: esforço somado, não fragmentado.

E por que sou obrigado a ter duas bibliotecas gráficas distintas para rodar esses programas? Para comer espaco em disco e entupir o gestor de pacotes da distribuicão com mais e mais dependências para poder instalar cada programa? No caso de não se querer ou poder usar sistemas de pacotess, é para gastar tempo com a compilacão de várias bibliotecas?

Liberdade requer responsabilidade. Problemas como esses não acontecem somente no GNU/Linux, mas a questão levantada ainda precisa passar por um bom polimento neste sistema operacional.

> > É uma pena mais isso que trava o Linux no Desktop e continuara assim

> Pode explicar o porquê?

Uma empresa resolve portar para GNU/Linux um programa escrito para MS Windows. Qual biblioteca gráfica ela escolherá, para que o usuário se sinta confortável com um visual já conhecido através de outros programas que usam a mesma interface gráfica?

Sera que preciso explicar: Não quero começar de novo uma briga sobre opiniões mais ja que tu perguntou.

O Linux não decola no Desktop porque não tem um ambiente gráfico padrão, para eu como desenvolvedor possa fazer um programa e saber que o mesmo vai rodar sem problemas na distribuição que o usuário usa, que a lib tal esta no diretório tal e assim vai, isso facilita o suporte, a funcionalidade e assim vai.

Como você citou no exemplo do K3B e do GIMP você tem os dois instalados ou seja QT, e GTK, com interfaces diferentes, com quase nenhuma integração entre os mesmos. Agora se estes dois excelentes programas usassem um ambiente gráfico padrão ai as coisas mudariam.

Os usuários Linux defendem as dependências, para não precisar recriar a roda, mais ao mesmo tempo tem vários ambientes gráficos, ou seja estão recriando a roda neste sentido. Porque o Kernel avança? Porque toda a comunidade esta em torno do mesmo objetivo, é isso que eu gostaria de ver no ambiente gráfico do Linux.

Como ja foi discutido isso aqui, sei que isso é o principio da liberdade, mais na minha opinião se existisse um padrão para o ambiente gráfico as coisas estariam em outro patamar. Também sei que para se tornar um padrão precisa haver um diversidade antes, ou seja vários projetos, mais o Linux esta ai a mais de 10 anos e a coisa continua a mesma.

> Não quero começar de novo: > Não quero começar de novo uma briga sobre opiniões mais ja que tu perguntou.

Se as opiniões forem embasadas e a discussão estiver progredindo, por que não continuar?

> O Linux não decola no Desktop porque não tem um ambiente gráfico padrão, para eu como desenvolvedor possa fazer um programa e saber que o mesmo vai rodar sem problemas na distribuição que o usuário usa, que a lib tal esta no diretório tal e assim vai, isso facilita o suporte, a funcionalidade e assim vai.

Para você fazer um programa gráfico no Linux (que funcione na maioria dos gerenciadores de janelas e desktops atuais) você precisa seguir algumas poucas especificações, como ICCCM e EWMH; isto caso seu toolkit gráfico não faça isso por você.

Quanto à localização das bibliotecas, em tese, se seu programa tem dependências externas (compilado de forma compartilhada), você não precisa conhecer o caminho completo (isto é tarefa do SO), apenas certificar-se de que existe a biblioteca e na versão requerida por seu programa.

> Como você citou no exemplo do K3B e do GIMP você tem os dois instalados ou seja QT, e GTK, com interfaces diferentes, com quase nenhuma integração entre os mesmos. Agora se estes dois excelentes programas usassem um ambiente gráfico padrão ai as coisas mudariam.

Mas que integração você queria entre o K3B e GIMP?!? E outra, programas em bibliotecas gráficas distintas não significa que não possam interagir/conversar. Por exemplo, respeitando-se o protocolo XDND, a maioria das aplicações escritas em diferentes bibliotecas (FLTK, FOX, Qt, GTK, wxWidgets, Java2, TOAD, etc.) interagirão perfeitamente via Drag'n'Drop.

> Os usuários Linux defendem as dependências, para não precisar recriar a roda, mais ao mesmo tempo tem vários ambientes gráficos, ou seja estão recriando a roda neste sentido.

O problema é que você está considerando que múltiplos ambientes/bibliotecas gráficas servem para o mesmo propósito e são escritos simplesmente para mostrar que o desenvolvedor é capaz. Não é assim. Com exceção de alguns casos, cada um atende um nicho particular, no nível do usuário e/ou desenvolvedor. Por exemplo, o KDE/Qt atende uma parcela de usuários, enquanto o GNOME/GTK outra parcela. Não adianta pegar o "melhor" de ambos e juntar porque são conceitos subjetivos, ficaria algo nem branco nem preto. Seria tão interessante quanto calcular a numeração média de calçados da população e gerar um número único, então pedir que qualquer um use esse número!

> Porque o Kernel avança? Porque toda a comunidade esta em torno do mesmo objetivo, é isso que eu gostaria de ver no ambiente gráfico do Linux.

E você acha que o "Linux Desktop" não tem avançado? Compare com o que tínhamos a dois anos atrás.

De qualquer forma, comparar com o kernel não é saudável porque o kernel é algo transparente ao usuário (e até mesmo para a maioria dos desenvolvedores), geralmente. Não obstante o kernel Linux é um projeto, é como se você dissesse "Por que o Qt avança? Porque toda a comunidade está em torno do mesmo objetivo", ou seja, a comunidade no caso é o próprio time de desenvolvedores. Ainda assim tem-se projetos para portarem outros kernels para rodar em conjunto com o GNU, como o GNU/Hurd, GNU/FreeBSD, etc. (veja os ports do projeto Debian).

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

> E por que sou obrigado a te: > E por que sou obrigado a ter duas bibliotecas gráficas distintas para rodar esses programas? Para comer espaco em disco e entupir o gestor de pacotes da distribuicão com mais e mais dependências para poder instalar cada programa? No caso de não se querer ou poder usar sistemas de pacotess, é para gastar tempo com a compilacão de várias bibliotecas?

Você *não* é obrigado, basta *não usar* o aplicativo gráfico que dependa da biblioteca. Por outro lado o desenvolvedor também não é obrigado a programar na biblioteca ou linguagem que você quer. Simples.

> Uma empresa resolve portar para GNU/Linux um programa escrito para MS Windows. Qual biblioteca gráfica ela escolherá, para que o usuário se sinta confortável com um visual já conhecido através de outros programas que usam a mesma interface gráfica?

Se a empresa for esperta ela vai desenvolver a aplicação do Windows já em uma biblioteca portável (FLTK, wxWidgets, FOX, Qt, GTK, etc.) e não nos "padrões" MFC, Windows.Forms (.NET) ou na API gráfica do Windows. Então basta compilar no GNU/Linux. Simples.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Direção:

mas o Linux esta aí há mais de 10 anos e a coisa continua a mesma.

Na verdade o Linux está aí há mais ou menos 14 anos, e a coisa não continua a mesma. De um início que não tinha nem suporte a TCP/IP, nem a algum modo gráfico, o sistema já avançou até uma plataforma bastante popular em servidores, tem seu nicho garantido nos clusters e em várias outras áreas específicas de aplicação.

O esforço em prol do Linux no desktop começou bem mais tarde, e avança devagar inclusive porque são muitos projetos diferentes: há navegadores, clientes de e-mail, comunicadores, suítes de escritório, ambientes gráficos e muito mais. O desenvolvimento dos aplicativos mais populares hoje só tomou embalo depois que a base dos ambientes gráficos estivesse madura o suficiente.

Para citar alguns exemplos, o KDE faz 10 anos no ano que vem (claro que há desktops gráficos anteriores a ele). O GNOME é pouco mais jovem. O OpenOffice.org surgiu como um projeto livre em 2000, e está prestes a lançar sua versão 2.0. A Mozilla Organization surgiu em 1998, e embora tenha lançado muitos produtos antes, só recentemente lançou a versão 1.0 do Firefox e do Thunderbird, revolucionários na visibilidade que obtiveram junto ao público que não acompanha a cena do software livre.

Apesar de o avanço não ser tão rápido quanto você desejaria (mesmo se considerasse como positivas até mesmo as medidas que não têm como conseqüencia direta a unificação no desktop), no que diz respeito ao desktop a "coisa" também não "continua a mesma". Basta comparar recursos, ou mesmo screenshots, com o que tínhamos há 10 anos, ou mesmo há 5 anos. O avanço já obtido foi fenomenal, é contínuo, e já há uns 2 anos que o uso real em desktops corporativos (embora em geral demandando grande esforço de configuração da distribuição, e abrindo mão de diversas funcionalidades que não são típicas do ambiente corporativo) começou.

Estamos ainda muito longe do nirvana, e longe inclusive do desktop doméstico genérico. Particularmente, ainda não atingimos um ponto em que seja fácil fazer surgir oferta para suprir a demanda das pequenas aplicações comerciais "genéricas". O avanço é contínuo, mas ele não é tão rápido quanto você espera, e ainda não nos levou ao ponto em que chegaremos. Na questão que você aponta, hoje já há um começo de tendência à consolidação, à uniformização de padrões e à interoperabilidade. É possível que o dia em que teremos um ambiente operacional desktop considerado por todos como "o padrão" chegará, mas isto não vai acontecer antes que andemos todo o caminho que nos separa deste ponto, e superemos todos os obstáculos nesta direção, como superamos as barreiras anteriores.

Mas para chegar a este ponto atual foi necessário avançar todos os passos anteriores, e é irreal imaginar que o desenvolvedor interessado em contribuir (como voluntário ou não - várias empresas contribuíram e contribuem para o avanço do KDE e do GNOME, por exemplo) para um projeto livre possa ser convencido a abandonar o seu sistema e passar a colaborar com outro, ainda que em prol do que você considera como um pré-requisito para o bem comum.

Da mesma forma, neste ponto é irreal imaginar que poderíamos convencer os desenvolvedores de aplicações a concentrarem seus esforços em um único ambiente, ou até mesmo a portarem seus softwares para um ambiente específico.

Ainda assim, eu já ofereci antes, e torno a oferecer ajuda para o caso de você querer deixar de se restringir a repetir este argumento em debates e decidir tomar alguma atitude positiva para a resolução da situação que você percebe. Se desejar saber o endereço de e-mail de algum desenvolvedor ao qual você queira dirigir seu apelo para que ele passe a desenvolver outro projeto, ou a desenvolver seu projeto de outra forma, posso ajudar a procurar.

Embora a velocidade dos avanços em cada uma das áreas seja diferente, é preciso perceber que a natureza e a complexidade das tarefas são muito diferentes. Dizer que o kernel avança mas os ambientes gráficos não é um efeito de ter requisitos diferentes para o que constitui avanço em cada uma destas áreas.

Contexto...: "mas o Linux esta aí há mais de 10 anos e a coisa continua a mesma."

A frase que você citou esta no contexto do Desktop Doméstico e não sobre o Linux em si, que como citei acima é um ótimo SO, se não o melhor.

A evolução de aplicativos é notória podemos fazer qualquer coisa no ambiente gráfico do Linux, o que é difícil é não existir um padrão. Programas usam lib gráficas diferentes, que necessitam de n/dependências e usam interfaces diferentes. Se o QT resolve o problema porque usar o GTK e vice-versa, acho que nenhuma distribuição consegue fugir a essas libs gráficas por causa dos aplicativos o resto das libs gráficas ainda são precárias e ajudam a dividir mais os desenvolvedores.

Estou falando em Desktop Doméstico que o usuário quer usar um pouco de tudo, ja no Desktop Corporativo as coisas mudam porque eu como administrador posso fazer uma escolha que utilize como base apenas um ambiente gráfico.

Sei que é o poder da liberdade, não discuto isso, só gostaria de ter um padrão gráfico (estilo API do windows). Quanto ao visual, gerenciador de janelas, estilo, temas isso pode ficar por conta do usuário.

Em resumo quero desenvolver um programa que rode em qualquer distribuição Linux sem me preocupar com o ambiente gráfico que o usuário esta usando, e que o meu software não seja diferente do visual configurado pelo usuário.

Vocês vão me disser que estou pensando a la Windows, e realmente estou, na minha opinião o que fez os desenvolvedores migrarem seus programas para ele foi a facilidade que o mesmo dispõe, ou seja o mesmo software roda, em win95 até winXP sem alterações e ainda se adequando ao visual dos mesmos e com as facilidades das ferramentas desenvolvimento que estão bem maduras, Ex. Delphi.

Concordo com você brain sei que este processo é demorado mais se a comunidade se unisse em torno do mesmo ja teríamos isso a tempos, como temos o Kernel que é o padrão de todas as distribuições.

Quando volto a falar sobre este assunto é porque vejo vários relatos que o Linux não esta pronto para o Desktop Doméstico, e na minha opinião este é um dos motivos.

Sei que você ja ofereceu para me ajudar a entrar em contato com desenvolvedores, mais acho só posso dar a minha ajuda dando opiniões pois os meus conhecimentos técnicos são poucos, sou desenvolvedor de programas comerciais, trabalho hoje em uma rede de lojas de comércio de móveis e eletro que esta enfrentando várias dificuldades para migrar para o Linux, porque o Banco que temos uma parceria usa Windows de cima a baixo, a financeira o mesmo, o programa office corporativo do banco só funciona no Windows as fábricas que tem programas on-line de pedidos só rodam no Windows e assim vai...

Mais a discussão é sobre Desktop Doméstico, sobre o PC popular, sobre a inclusão digital e pelo visto neste ponto todos concordam que o Linux não esta pronto ainda, evoluiu mais não esta pronto para o usuário doméstico.

> A evolução de aplicativos: > A evolução de aplicativos é notória podemos fazer qualquer coisa no ambiente gráfico do Linux, o que é difícil é não existir um padrão. Programas usam lib gráficas diferentes, que necessitam de n/dependências e usam interfaces diferentes.

A biblioteca gráfica é apenas mais uma dependência de um aplicativo. Normalmente tem-se dezenas de outras, como biblioteca para ler arquivos xml, fontes freetype, acesso à base de dados, comunicação, subsistema de som, etc.

> Se o QT resolve o problema porque usar o GTK e vice-versa,

E quem disse que Qt (QT é QuickTime) resolve todas as necessidades no nível usuário-desenvolvedor a ponto de deixar a GTK+ obsoleta? Se a linguagem C (poderia trocar por assembly também) faz qualquer coisa, por que precisamos de C++, Ruby, Python, Perl, Java ou Pascal?

O Qt, assim como qualquer outro toolkit tem sua deficiência. Por exemplo, no nível do desenvolvedor, esbarra-se em questões de licença para produtos comerciais; ou então ainda no desenvolvedor, tem-se aquela compilação não convencional por meio de pré-processamento particular (MOC). Para o usuário pode haver questões de eficiência em tempo e espaço. O análogo serve para o GTK+ ou outro toolkit.

Não adianta pensar "óh, então vamos selecionar as melhores características deles e criaremos um novo padrão de toolkit gráfico" porque *muita* coisa --diria maioria-- é de caráter subjetivo, tanto para o desenvolvedor como usuário.

> acho que nenhuma distribuição consegue fugir a essas libs gráficas por causa dos aplicativos o resto das libs gráficas ainda são precárias e ajudam a dividir mais os desenvolvedores.

Como assim precárias?!? Fazem mal aquilo que se propõem? Não confunda menos popular com precário.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Comparar: Douglas comparar ambientes gráficos do Linux como linguagens é brincadeira, é o mesmo que comparar jogos, carros e outros aplicativos.

O MacOX da Apple tem um padrão gráfico.
O Windows tem um padrão gráfico.
O Linux/BSD não tem padrão gráfico.

Esta é uma comparação certa não acha? melhor ainda é uma constatação.

Eu como desenvolvedor de software comercial não posso me preocupar com certas coisas como:
- fazer um botão.
- abrir uma janela.
- mostrar um diálogo.
- fazer um menu.
- uma entrada de dados.
- ...

Eu quero uma ferramenta que faça isso automaticamente. Eu tenho que me preocupar com o funcionamento do sistema que eu estou desenvolvendo, a integridade dos dados e assim vai.

Não quero que só usem QT ou GTK quero apenas informar para a ferramenta que eu desenvolvo que ela faça um botão na posição tal e escrever o código do procedimento quando o mesmo for acionado, só isso. Se o ambiente Linux tivesse isso (como a API do Windows) o programa rodaria em qualquer distribuição Linux sem problemas, independente do ambiente gráfico usado.

Mais o que acontece hoje tenho que escolher uma linguagem (não gosto de linguagem interpretadas, java, python... acho que as mesmas são úteis mais não para desenvolvimento desktop, com banco de dados), uma toolkit gráfica que vai funcionar de forma diferente dependendo do ambiente gráfico do cliente, um banco de dados, aprender a integrar tudo isso, e ainda saber como funciona o sistema da empresa.

O que faço hoje? uso Delphi e Firebird e não me preocupo com mais nada, é isso que o desenvolvedor quer. Sei que existe vários projetos que tentam fazer isso no Linux, mais são incompletos, usam QT ou GTK no fundo, são lentos, dependem de várias dependências e não funcionam em qualquer distribuição.

Sei que estou pensando como desenvolvedor Windows mais é a maneira mais eficiente hoje, tenho tudo que preciso com duas ferramentas, e ainda funciona do win95 ao XP sem problemas e com o visual do sistema.

Gostaria de ver isso no Linux, mais acho que pelos comentários do pessoal mais envolvido é mais fácil eu mudar de mentalidade, quem sabe ? Mais mesmo assim estou desenvolvendo um sistema de gestão em Linux, mais claro em modo texto, porque este sim funciona em qualquer distribuição, em BSD e até em Windows.

Sou um usuário de nível médio para baixo, uso os meus conhecimentos para aprender mais, e tento fugir dos produtos da Microsoft, só que neste momento isso não é possível, quem sabe no futuro.

padrões: "O MacOX da Apple tem um padrão gráfico.
O Windows tem um padrão gráfico.
O Linux/BSD não tem padrão gráfico."

Graças a Deus! Software livre é sobre escolhas. Escolha a que se adequar mais as suas necessidades, seja distribuição, seja biblioteca gráfica, seja linguagem, seja ambiente de desktop, navegador ou editor de textos...

Graças a Deus não há uma entidade comercial única por trás do forçando _sua_ solução para um problema particular garganta abaixo dos usuários.

"Eu como desenvolvedor de software comercial não posso me preocupar com certas coisas como:
- fazer um botão.
- abrir uma janela.
- mostrar um diálogo.
- fazer um menu.
- uma entrada de dados."

Pq vc se preocuparia com isso, seja com Gtk ou QT? Há ferramentas ( projetos separados graças a Deus ) que cuidam da criação do layout gráfico de telas. Glade para Gtk e QTDesigner para Qt.

"Se o ambiente Linux tivesse isso (como a API do Windows) o programa rodaria em qualquer distribuição Linux sem problemas, independente do ambiente gráfico usado."

Que eu saiba, aplicativos Gtk e Qt rodam em qualquer distribuição Linux sem qualquer problemas. E até mesmo no Windows, tmb.

"Mais o que acontece hoje tenho que escolher uma linguagem"

escolhas, escolhas, graças a Deus! Não estamos em um mundinho VB...

"(não gosto de linguagem interpretadas, java, python... acho que as mesmas são úteis mais não para desenvolvimento desktop, com banco de dados),"

Pq? Pelo contrário, se está sugerindo que elas são melhores para programas web no servidor, acho que sua própria natureza interpretada sugeriria que a performance seria melhor como linguagens para aplicativos desktop de um só usuário, ao invés de lidar com várias requisições de usuários no servidor...

"O que faço hoje? uso Delphi e Firebird e não me preocupo com mais nada, é isso que o desenvolvedor quer."

E pode me dizer exatamente no que isso é diferente de tudo o que vc falou até agora sobre Gtk ou Qt? Vc ainda está escolhendo uma linguagem ( ObjectPascal ), uma biblioteca gráfica ( A VCL Delphi ) e ainda está se restringindo a um SGBDs em particular. Não entendi o motivo de tanta reclamação e no final fazer exatamente o mesmo que vc faria caso tivesse escolhido Gtk ou Qt, exceto pelo fato de que não estaria restrito a ObjectPascal como linguagem...

"não funcionam em qualquer distribuição."

conversa fiada!

"Sei que estou pensando como desenvolvedor Windows"

Com essa mentalidade limitada, fica realmente enxergar os arredores.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Gozado: nemesis isso é o preço da liberdade falta um padrão. Esta é a resposta do porque o Linux não é utilizado nos Desktops, e porque não existe desenvolvimento de softwares comercias para o mesmo, tanta liberdade que o meu software gráfico não funciona em determinadas distribuições, em determinados ambientes gráficos e assim vai.

Tu não quer um ambiente gráfico padrão e usa um Kernel padrão, quem se desenvolveu mais nestes ultimos 10 anos? Porque o Linux é usado na maioria dos Servidores, pelo seu ambiente gráfico, não e sim pelo seu Kernel. O que falta para o ambiente gráfico do Linux? um padrão.

Não estou discutindo QT, GTK e sim a transparência do software feito em Delphi que roda em qualquer Windows sem precisar instalar nada. Ja no Linux para rodar os aplicativos tenho que ter no mínimo 2 ambientes gráficos instalados para rodar os aplicativos que eu uso.

Eu luto pelo padrão gráfico e não por QT/GTK e assim vai.

Tu não é desenvolvedor, se fosse queria ver tu escolher entre as vários toolkit gráficas (limitadas) para desenvolver um sistema que vai demorar vários meses para ser desenvolvido e vai ser comercializado para várias empresas. Claro eu posso obrigar a empresa X a usar a distribuição Y porque a mesma é compatível com o mesmo. Com isso estou limitando a venda do meu produto. Falar é fácil.

"Pq? Pelo contrário, se está sugerindo que elas são melhores para programas web no servidor, acho que sua própria natureza interpretada sugeriria que a performance seria melhor como linguagens para aplicativos desktop de um só usuário, ao invés de lidar com várias requisições de usuários no servidor..."

Piada do ano, só porque é melhor para a Web deve ser melhor para o Desktop. Tu não sabe o que fala, faz um teste simples testa o programa do imposto de renda feito em Delphi completo e a versão limitada em Java e depois tu me responde qual é o melhor para o Desktop, pode comparar a versão para Linux também.

Depois dessa melhor nem comentar o resto.

Falácias: "nemesis isso é o preço da liberdade falta um padrão. Esta é a resposta do porque o Linux não é utilizado nos Desktops, e porque não existe desenvolvimento de softwares comercias para o mesmo,"

não. a resposta é que a absoluta maioria das pessoas depende do software criado por um monopólio americano.

"tanta liberdade que o meu software gráfico não funciona em "

imagino que vc, como bom desenvolvedor Delphi, esteja falando daquele Kylix hiper-desatualizado, não?

"Porque o Linux é usado na maioria dos Servidores, pelo seu ambiente gráfico, não e sim pelo seu Kernel."

Linux _é_ o kernel. E ele sempre foi utilizado até hoje principalmente como servidor pq é isso que se espera de um *nix: robustez e estabilidade como servidor. Não quer dizer que não tenha chances como estação de trabalho, no entanto.

"O que falta para o ambiente gráfico do Linux? um padrão."

Existem vários padrões: GTK, QT, FLTK, Tk, FOX... escolha o mais adequado. Vc nunca vai ver _a_ distribuição Linux. _O_ padrão. O que vc entende por Linux nada mais é um saudável amontoado de projetos de software livre com pouca coisa em comum exceto o desejo de ver boas idéias em software se propagarem e serem usadas...

"em Delphi que roda em qualquer Windows sem precisar instalar nada. Ja no Linux para rodar os aplicativos tenho que ter no mínimo 2 ambientes gráficos instalados para rodar os aplicativos que eu uso."

Roda em qualquer Windows pq vem com as bibliotecas que necessita ou foi compilado estaticamente com elas, sem precisar de DLLs.

Vc pode fazer exatamente o mesmo com GTK ou Qt.

Não entendi a queixa...

"Eu luto pelo padrão gráfico e não por QT/GTK e assim vai."

Vai ser uma luta inglória, vou logo avisando: o pessoal do software livre não tem os mesmos gostos, as mesmas crenças e nunca vão concordar sobre a melhor API para determinada situação. forks e mais forks...

"Tu não é desenvolvedor,"


No trabalho desenvolvo chatos aplicativos cliente-servidor Delphi. Mas sou só programador, não tenho cacife para sugerir alternativas. E pior de tudo: quando se fala em software livre por aqui, só se pensa em Java! Java!! :O


"se fosse queria ver tu escolher entre as vários toolkit gráficas (limitadas) para desenvolver um sistema que vai demorar vários meses para ser desenvolvido e vai ser comercializado para várias empresas.

"Claro eu posso obrigar a empresa X a usar a distribuição Y porque a mesma é compatível com o mesmo. Com isso estou limitando a venda do meu produto."

Compile seu binário com todas as bibliotecas necessárias estaticamente, como sugeri acima. A não ser que seja com Qt e vc esteja relutante em obter uma licensa comercial...

"Piada do ano, só porque é melhor para a Web deve ser melhor para o Desktop."

Eu não disse isso. Leia direito. O que disse é exatamente o contrário: que o fato de serem interpretadas faz da performance um problema para aplicaões servidor, na web. Por outro lado, no desktop, servindo a apenas um único usuário, apenas mostrando algumas telinhas e deixando o bruto do processamento no servidor, é bem mais tranquilo pra tais linguagens.

"Tu não sabe o que fala,"

Eu sei muito bem o que falo, mesmo quando batendo boca com um energúmeno que nem sabe ler.


"Delphi completo e a versão limitada em Java"

bom saber que até vc notou que o pessoal que desenvolveu a versão chinfrim em Java nada conhece da linguagem.


;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

> Douglas comparar ambientes: > Douglas comparar ambientes gráficos do Linux como linguagens é brincadeira, é o mesmo que comparar jogos, carros e outros aplicativos.

Não necessariamente. Cada linguagem tende a ter pelo menos uma biblioteca gráfica. É o caso do C++ (FLTK, Qt, FOX, etc.), C (GTK+), Java (Swing), por aí vai. A não ser que haja os chamados "binds", mas ainda assim configura uma biblioteca.

Poder-se-ia dizer que várias linguagens fragmentam o esforço de programadores (assim como foi posto aqui em relação às bibliotecas). Existe um fundo de verdade nisso, mas a grande diferença é que nem toda linguagem é para todo programador, seja no aspecto técnico, produtivo ou simplesmente no quesito "afeição".

De repente quantas pessoas não se viram estimuladas a aprender a programar (e assim contribuir) porque descobriram uma linguagem com o perfil delas?!? O mesmo vale para as bibliotegras gráficas. No mundo do software livre as coisas funcionam muito por este lado, o estímulo é muito importante. As pessoas do SL em geral não vivem trabalhando para uma empresa recebendo um salário e sendo assim sujeitas a trabalharem com ferramentas que não são exatamente as que gostariam.

> O MacOX da Apple tem um padrão gráfico.
O Windows tem um padrão gráfico.
O Linux/BSD não tem padrão gráfico.

Não sei como funciona a API gráfica baixo nível do Windows e MacOS X, se por exemplo fornecem os componentes básicos de desenho (quadrados, retângulos, etc.) já na forma homogênea ou se é mais relaxado como a API de baixo nível do X-Windows, que serve tão somente para se desenhar coisas, qualquer coisa.

A Microsoft Fundation Classes (MFC) assim como os Windows Forms do .NET e controles do Delphi são abstrações de mais alto nível para se desenhar componentes (widgets) no Windows. Contudo, outras bibliotecas fazendo essas abstrações também existem em Windows e MacOS X, como o próprio Qt, GTK+, FLTK e tantos outros toolkits portáveis.

Fornecer e "forçar" estruturas básicas para desenho --de forma a receber um mesmo tema-- produz sem dúvida um efeito homogêneo, mas prende o desenvolvedor àquele conjunto específico de widgets.

> Eu como desenvolvedor de software comercial não posso me preocupar com certas coisas como:
- fazer um botão.
- abrir uma janela.
- mostrar um diálogo.
- fazer um menu.
- uma entrada de dados.
- ...

Não entendi o que quis dizer. Em tese nenhum desenvolvedor (exceto os programadores de toolkits ou widgets) precisam se preocupar com isso. Na maioria dos toolkits existentes para Linux basta você colocar, por exemplo, um botão em seu lugar e redimensioná-lo se necessário.

> Não quero que só usem QT ou GTK quero apenas informar para a ferramenta que eu desenvolvo que ela faça um botão na posição tal e escrever o código do procedimento quando o mesmo for acionado, só isso. Se o ambiente Linux tivesse isso (como a API do Windows) o programa rodaria em qualquer distribuição Linux sem problemas, independente do ambiente gráfico usado.

Confesso que não entendi muito bem, novamente. Seja no Windows, MacOS X ou Linux isso será feito dependentemente do toolkit que estiver usando. No Delphi é de um jeito, no Visual C++ de outro. No Java idem. FLTK, GTK+ e Qt também diferem. Entretanto, alguns fornecem uma maneira mais prática (visual) de se fazer isso, inclusive a ligação entre o componente gráfico (widget) e a ação (callback).

> O que faço hoje? uso Delphi e Firebird e não me preocupo com mais nada, é isso que o desenvolvedor quer. Sei que existe vários projetos que tentam fazer isso no Linux, mais são incompletos, usam QT ou GTK no fundo, são lentos, dependem de várias dependências e não funcionam em qualquer distribuição.

Se você pretende fazer programas (mesmo comerciais) que sejam portáveis, esqueça o Delphi ou qualquer tecnologia específica para Windows, inclusive o .NET. Use o wxWidgets, Qt, FLTK, FOX, Java/swing, GTK+ ou qualquer outro toolkit gráfico portável. O FLTK, pela natureza enxuta, viabiliza que programas razoáveis sejam ligados estaticamente, sendo assim, não precisa de nenhuma biblioteca específica instalada! Por outro lado, se precisa de um framework, talvez o Qt ou wxWidgets seja uma melhor escolha.

Só para concluir, o que vejo no Linux é um maior afrouxo no que tange o aspecto visual, o que é diferente de "não integração". As aplicações na maioria dos GUI toolkits podem se comunicar perfeitamente, pois existem protocolos sólidos para isso. Contudo, há uma grande liberdade em se ter várias formas de controles gráficos, e como o X-Windows não é associado a nenhuma empresa de algum toolkit gráfico, nem mesmo tentou-se estipular um padrão visual. Na minha opinião isso é positivo, porque certamente uma "padronização" nesse nível restringiria o espectro de opções para usuário/desenvolvedor. O que surge diante disso são desktops com padrões visuais próprios, como o KDE e GNOME, que eventualmente até arriscam "vestir a mesma roupa" (vide Red Hat).

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Simplismo não é simplicidade: Simplismo não é simplicidade.

Se é necessário usar conjunto de programas em ambiente gráfico em que cada um deles foi desenvolvido sob bibliotecas gráficas diferentes, a pessoa *fica obrigada* a instalar várias bibliotecas gráficas. Isso não é simples de contornar.

Se a empresa já possui uma versão para MS Windows, uma das primeiras coisa que ela fará é querer estabelecer uma interface gráfica com a qual o usuário já se sinta mais à vontade por estar familiarizado. Ter um ferramental padronizado ajuda bastante. Mas como não há interesse nisso, as coisas acabam por ficar difíceis.

Aceitar o excesso de divergências por inércia, "por que é assim mesmo" é tão perigoso quanto aceitar padrões fechados por inércia.

.: Douglas tu tem razão no que tu comentas eu como a maioria dos desenvolvedores Windows (inclui-se ai os usuários) estamos acostumados com a praticidade do Windows para desenvolver soluções, tudo que foge a isso se torna um tormento.

Temos que mudar o pensamento, sei disso, mais é difícil principalmente para quem desenvolve softwares comerciais, porque além de desenvolver em Linux ainda temos que convencer os clientes a usa-lo, configurar e ensina-los a operar neste novo SO. Além de ter que apostar numa ferramenta, linguagem, biblioteca gráfica... pois existe várias no mercado.

Quis mostrar a visão de um desenvolvedor, e dar um motivo (opinião) do porque não existirem programas comerciais em Linux. Ja comentei isso aqui mais alguns dos participantes vem com agressões, com visões teóricas, com soluções que eles não utilizam e acham que são boas, mais na hora da produção só quem desenvolve sabe o trabalho que da.

Acho que esta lista a maioria dos participantes são administradores que tem no Linux uma ótima solução, não vejo comentários de desenvolvedores, até porque desenvolver para o Linux não é uma tarefa fácil.

Falar é fácil, qualquer um fala, mais fazer ainda é um problema.

Obs. O Windows tenta prender o desenvolvedor na sua plataforma dando facilidades para o mesmo, o que acaba acontecendo, ja no Linux a coisa é bem diferente.

Obrigado pelos comentários aprendi mais um pouco.

Também aprendi uma lição: Também aprendi uma lição aqui: não há real interesse em estabelecer padrões para *permitir* a adoção maciça do GNU/Linux em ambientes Desktop.

Primeiro, é preciso definir: Primeiro, é preciso definir que padrão é esse. Integração/comunicação? Visual? Controles gráficos?!? Até o momento me parece que a única crítica concisa é em relação à pluridade visual dos variados toolkits gráficos.

Segundo, é preciso provar que o estado atual de aparente orgia emperra o crescimento do Linux no desktop.

Terceiro e mais importante, é preciso saber se uma possível mudança rumo à padronização (seja qual for) ferirá algum princípio maior de liberdade de desenvolvimento e personalização. Porque se conflitar e, considerando-se que a comunidade software livre é bem mais democrática, geralmente independendo de qualquer empresa por trás, dificilmente abrirão mão de tamanha preciosidade para satisfazer a ânsia cosmética de usuários/desenvolvedores que caem de pára-quedas no Linux.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Prova...: Douglas
"é preciso provar que o estado atual de aparente orgia emperra o crescimento do Linux no desktop."

Em relação ao desenvolvimento de programas acho que a prova ja esta ai com a falta de softwares específicos para empresas.

Outra prova é o exemplo do PC Popular, a não indicação para uso como desktop doméstico, a não aceitação do mercado de jogos, aplicativos e outros programas feitos por empresas.

falta de argumentos...: kct! que prova mais ridícula!

Então, não se desenvolvem jogos pro Linux pq os desenvolvedores de jogos, acostumados que estão com C++, assembly e outras iguarias, têm medo da quantidade de opções para interface gráfica??!! Aliás, jogos tem interface gráfica própria e GTK, Qt ou outras teriam pouco uso.

E aplicativos não são desenvolvidos pro Linux pq desenvolvedores tmb ficam com medo das diversas opções disponíveis?? Pq obviamente desenvolvedores Delphi, Java, VB programam _a interface padrão do Windows_, MFC, na mão mesmo, né?? ah, agora vejo pq é importante ter uma interface padrão!...

kct, se não tem bons argumentos melhor ficar calado, mermão!

por fim, vou reiterar: é um problema do ovo e da galinha. Linux não tem aplicativos pq não é popular ou não é popular pq não tem aplicativos? Não sei a resposta, mas sei pq não tem aplicativos: pq os preguiçosos programadores Windows estão programando pra plataforma popular enquanto esperam o ovo chocar e se transformar em frango...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

> Em relação ao desenvolvim: > Em relação ao desenvolvimento de programas acho que a prova ja esta ai com a falta de softwares específicos para empresas.

Isso é uma falácia das grandes. Isso só confirma o fato de que não temos ainda tantos investimentos por empresas de softwares, por exemplo. Mas não fala absolutamente nada que a causa disso é a pluridade visual do Linux.

Pode ser até um fator de repulsão, mas nada é sabido sobre sua relevância diante de outros tantos fatores.

Pense por exemplo no MacOS X, com tamanha harmonia visual hoje tem menos usuários do que o próprio Linux. E atualmente investimentos modestos de softwares por empresas externas.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Velho dilema: Na minha opinião, a discussão sobre integracão, visual e controles gráficos não ocorre satisfatoriamente justamente por não haver ainda uma visão clara do que é necessário definir.

Uma coisa que temo especificamente sobre o GNU/Linux é a ojeriza a padronizacões. Princípios filosóficos abstratos não deveriam impedir o desenvolvimento de software. Impedir uma padronizacão porque magoará algumas pessoas ideólogas ou intransigentes que defendem uma liberdade desregrada é uma atitude equivocada e perigosa.

Quem sabe projetos como o Syllable, http://www.syllable.org , não ajudem a esclarecer quais os rumos que o GNU/Linux precisá adotar para não estagnar ou perder o rumo.

"ojeriza a padronizacões": 1. Linux é uma implementação do _padrão_ POSIX
2. Apache é uma implementação do _padrão_ HTTP e deversos outros
3. Mozilla implementa diversos _padrões_ da W3C tão fielmente quanto possível e de forma muito mais satisfatória do que o obsoleto IE
4. PostgreSQL tenta seguir o _padrão_ SQL ISO tanto quanto possível
5. Qt e GTK tentam seguir as HIGs tanto quanto possível. Além de _padrões_ para drag-and-drop e outros protocolos de GUIs

Portanto, não me venha com esse argumento sem base de que o movimento pelo software livre não se atém a padrões, quando é justamente o contrário: em geral, implementações open-source são mais fiéis aos padrões do que as contrapartidas proprietárias, que tendem sempre a oferecer "extensões" ou "bugs" que de alguma forma quebram os padrões para tentar manter os desenvolvedores sob suas rédeas...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

"ojeriza a padronizacões": /* duplicado */

Muito pelo contrário: "Pense por exemplo no MacOS X, com tamanha harmonia visual hoje tem menos usuários do que o próprio Linux. E atualmente investimentos modestos de softwares por empresas externas."

Esta tua afirmação esta totalmente errada o MaxOS tem menos usuários por questão de preço do hardware, e não por alternativas de software. No MacOS X tem programas da Microsoft, Adobe, ... sem falar nos programas para a área gráfica/vídeo (Corel, Photoshop...) e a maioria dos programas que rodam no Linux.

Se o Linux tivesse isto ja se tornaria um grande Desktop, não acha.

E porque o MacOS X que tem suas bases no unixes (BSD) tem estes programas e o Linux não tem, simples porque existe um ambiente gráfico padrão.

Fico surpreso com sua precis: Fico surpreso com sua precisão em diagnosticar qual é o exato problema da não massificação de um sistema/plataforma. No Linux é porque possui controles gráficos não padronizados, o MacOS X porque seu hardware é caro. :-)

Sem querer deixar a sensação de um ad hominem no parágrafo anterior, você ao desconsiderar todos os outros fatores (até mesmo as investidas da Microsoft contra o Linux), está incorrendo numa dedução apressada ao afirmar que o vilão do Linux é sua não identidade visual.

Diante disso, a questão é: por que esta pluridade visual repele pessoas/empresas a ponto de não levar definitivamente o Linux para o desktop?

Você, como desenvolvedor Windows, qual o medo em desenvolver para Linux (desconsiderando-se, naturalmente, uma possível ausência de público alvo)? Seria a falta de um ambiente consolidado como o Delphi?

Em que ponto essa não identidade visual do Linux te incomoda?

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Enfim: Enfim você chegou no ponto certo. Os padrões citados pro você em 1,2,3 e 4 não foram estabelecidos pelos criadores dos projetos, e no caso 5 a padronização ocorre em poucos pontos (ainda que muito importantes do ponto de vista de interoperação de programas).

O que pergunto é por que a falta de coragem dos projetos de criarem um padrão, em vez de apenas adotarem padrões de terceiros.

Esse cara viaja na maionese: Essa é mais uma daqueles artigos se intitulando a salvação do linux, e dizendo que tem todas as soluções para o "problema" que o linux tem, mas termina viajando demais e dando soluções que fariam esses problemas se tornarem pesadelos.
Por exemplo, ele fala que uma das soluções para o usuário não se perder no sistema de arquivos é ter um sistema de arquivos para o linux e outro para os documentos do usuário. Me respondam, esse conceito não existe há muito tempo?? Para que serve o diretório home?? O problema não é que o linux tem muitos diretórios, o real problema é que o usuário não quer salvar seus arquivos somente no home. Ele quer bisbilhotar pelo sistema e acaba se perdendo.
O cara ainda fala em usar um DBFS. Fala sério. Esse tipo de coisa me lembra uma discussão do pessoal do kde que falava que o problema dos programas de indexação (para procurar arquivos) não é a busca dos arquivos em si usando os metadados, e sim o usuário preencher os metadados para que posteriormente possa ser pesquisado. O futuro do armazenamento de arquivos não vai ser colocar tudo em um banco de dados, isso não funciona. Será o computador "automagicamente" conseguir preencher esses metadados pelo usuário, coisa que ele não fará. Como fará isso? Só Deus sabe.
É como aquelas pessoas que reclamam que o linux tem várias interfaces gráficas. "Eu fico perdido em escolher uma". Fala sério. Não escolha!! Use a primeira que encontrar. Pronto, acabou o problema. Querem transformar os pontos mais fortes do linux nos pontos mais fracos. Fala sério.

Menus: Adoro o KDE pelos softwares, mas odeio seu peso na máquina... como API, acho o GTK+ mais bonito, e portanto o gnome é mais bonito (na minha opinião), mas odeio sua instabilidade (ela ainda existe, é claro que sim). Algumas decisões da galera do gnome são extremamente contestáveis, como retirar a ótima ferramenta gnome-modem-lights e cruzá-la com gnome-system-tools, hal, dbus, etc. Em alguns sistemas, o hardware não é bem reconhecido e logo, um modem não pode ser utilizado satisfatoriamente. Além disso, criou-se um labirinto, que já discuti num canal de irc com o pessoal do garnome. Essa ferramenta p.ex. é propalada como independente de distribuição, mas como o cerne do gnome começa a avançar para as gnome-system-tools, estas tem relação direta com a distro, inclusive no seu site há a informação de quais são suportadas. Isso quer dizer que para se ter um gnome satisfatoriamente utilizável de acordo com o que os desenvolvedores desejavam, você deve rodar alguma das distribuições ali elencadas. Ou conviver com software que não pode ser utilizado em sua máquina. Estranho, né?

Sinceramente, quando à facilidade de uso, leveza (pô, apesar dos avanços, o X pesa muito no hardware, é inegável) e principalmente o jetio de ser da interfaces gráficas, muitos discordarão, mas o fluxbox é imbatível.

Acho que ele combina elementos e idéias interessantes para o usuário. Acho que não seria difícil implementar uma ferramenta de controle para ele (ou melhorar, e muito, o odioso fluxconf). Considero partilarmente importante o usuário final de um ambiente de desktop linux ter absolutamente qualquer comando do sistema ao alcance de dois cliques de mouse. O jeito de ele lidar com os menus, um simples arquivo de texto modificável, deveria ser considerado por muitos desenvolvedores, já que ele bate pesos-pesados como o gnome nesse sentido. É claro que há aquele software utilizado pelo pessoal do Ubuntu (de modificação do menu do gnome), mas ele sequer é instalado como padrão ou vem no CD da distro, só em apt-get nos repositórios da internet, vc consegue...

O que sei é que o desktop linux está avançando a passos largos e não deixa nada a desejar ao que existe no mundo do software proprietário ou no que ali existirá...

origens: Não é questão de falta de coragem. E não são "padrões de terceiros": são padrões abertos desenvolvidos por comitês envolvendo vários participantes da indústria.

Ocorre que aqueles grandes projetos de software livre se desenvolveram com um propósito bem específico em mente: precisamente implementar aqueles padrões!

Não quer dizer que outros projetos não tenham suas próprias APIs e maneiras constrastantes de se fazer a mesma coisa: GTK e QT são dois bons exemplos. Mas só o tempo dirá qual se tornará _o_ padrão de fato, se é que jamais acontecerá...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Desculpa: Acho que me expressei mal, este é um dos motivos (e é apenas a minha opinião).

Como falei em comentários anteriores a identidade do visual do Linux não me importa, isso tem que ficar a cargo do usuário. O usuário pode escolher temas, gerenciador de janelas, ícones, ... O que na minha visão atrapalha o desenvolvimento de soluções empresarias é a falta de um padrão, vou dar um exemplo, se eu desenvolver uma aplicação em modo texto para Linux, com certeza vai rodar em qualquer distribuição do Linux, BSD... agora se eu fazer isso em modo gráfico a distribuição deste programa vai depender e muito do ambiente gráfico que o usuário esta usando e dependendo do caso não vai funcionar sem sanar vários problemas que vão aparecer dependendo da distribuição.

Na minha opinião o que eu gostaria de ver no Linux é um padrão gráfico, talvés aqui eu esteja me expressando mal, não é um ambiente gráfico padrão e sim questões gráficas padrões com a API do Windows que os programas desenvolvidos para este SO usam e podem ser instalados em qualquer versão do mesmo. Componentes que estão implementados hoje QT ou no GTK deveriam estar no X. (desculpe se falei bobagem pois não tenho conhecimento técnico como isso funciona, mais é apenas um exemplo)

Vou dar um exemplo mais prático, sou músico e vou lançar um CD, vou usar a tecnologia padrão de mercado certo? que vai rodar em qualquer aparelho de som, ou vou usar uma tecnologia padrão da empresa X que só roda em aparelhos da empresa Y.

Isso ocorre hoje no Windows, porque o mesmo detem mais de 90% do mercado e é considerado um padrão para o desenvolvimento.

Se existisse uma ferramenta gráfica completa como o Delphi no Linux, isso muito longe do Kylix que usa como base o QT, o Linux com certeza atrairia um bom número de desenvolvedores, sei que existem vários projetos mais todos sem exceção ainda precisam melhorar e muito para atrair estes desenvolvedores.

Só para ressaltar gostaria de ver um padrão gráfico e não um ambiente gráfico padrão.

"ojeriza a replicações": /* triplicado */

:P

> O que na minha visão atrap: > O que na minha visão atrapalha o desenvolvimento de soluções empresarias é a falta de um padrão, vou dar um exemplo, se eu desenvolver uma aplicação em modo texto para Linux, com certeza vai rodar em qualquer distribuição do Linux, BSD...

Depende. Se ele for do tipo TUI (/Text User Interface/, à la MC, Mutt, etc.) certamente será necessário alguma biblioteca instalada, como a popular 'ncurses'.

Ainda, mesmo sendo um CLI básico o aplicativo pode requerer outras bibliotecas instaladas para seu funcionamento. Por exemplo, uma biblioteca que lida com sockets, acesso à base de dados, threading, som, etc.

> agora se eu fazer isso em modo gráfico a distribuição deste programa vai depender e muito do ambiente gráfico que o usuário esta usando e dependendo do caso não vai funcionar sem sanar vários problemas que vão aparecer dependendo da distribuição.

Provavelmente vai funcionar em qualquer distribuição/desktop que implemente o protocolo X (XFree, X.Org). Possivelmente precisará ter algumas dependências instaladas (bibliotecas gráficas), no entanto. Mas isto, como posto acima, é apenas um dos requerimentos que o aplicativo necessitará, e certamente figurará como *uma* das dependências.

> Componentes que estão implementados hoje QT ou no GTK deveriam estar no X. (desculpe se falei bobagem pois não tenho conhecimento técnico como isso funciona, mais é apenas um exemplo)

Eu considero o modelo atual bem mais modular. Isto é, o X é tão somente um backend de desenho, um dispositivo neutro e imparcial que aceita qualquer instrução de desenho, e não apenas supostos componentes (por exemplo widgets) previamente definidos.

Nesse sentido existem camadas intermediárias (bibliotecas), como o Cairo, que contam com um conjunto mais rico/especializado de funções de desenho. A grande vantagem é que é teoricamente possível usar outros backends além do X-Windows, como "desenhar" em PDFs, SVGs, PNGs, PS, OpenGL e até mesmo no Win32. Isso pode ser um grande aliado da portabilidade, à medida que uniformiza (padroniza) instruções de desenho. Naturalmente, criando instruções mais sofisticadas de desenho torna o meio otimizado para algum propósito (o do Cairo para "desenhos vetoriais"), o que já o qualificaria como "enviesado".

O FLTK (via --enable-cairo) e mais recentemente o GTK+ estão aptos a aceitarem instruções do Cairo.

> Vou dar um exemplo mais prático, sou músico e vou lançar um CD, vou usar a tecnologia padrão de mercado certo? que vai rodar em qualquer aparelho de som, ou vou usar uma tecnologia padrão da empresa X que só roda em aparelhos da empresa Y.

Mas o X-Window é padrão nos unices. Qualquer aplicativo feito visando o X-Window deverá rodar sem esforço em qualquer implementação do X, no máximo dependendo de sua biblioteca gráfica caso não tenha sido ligado de forma estática.

> Isso ocorre hoje no Windows, porque o mesmo detem mais de 90% do mercado e é considerado um padrão para o desenvolvimento.

Não entendi. Você queria que os aplicativos gráficos do Linux usagem a API do Windows?!? Provavelmente nem se quiséssemos, pois não são especificações abertas. É por isso que o projeto Mono está todo enrolado com o Windows Forms, dependendo de engenharia reversa para tentar emular as instruções gráficas Win32 do .NET.

> Se existisse uma ferramenta gráfica completa como o Delphi no Linux, isso muito longe do Kylix que usa como base o QT, o Linux com certeza atrairia um bom número de desenvolvedores, sei que existem vários projetos mais todos sem exceção ainda precisam melhorar e muito para atrair estes desenvolvedores.

Isso é verdade, uma IDE madura e completa como o Delphi facilitaria as coisas. Mas seria melhor se fosse portável (produzisse código compilável em outros sistemas/arquiteturas), pois o Delphi apesar de sua relevância amarra o desenvolvedor à API gráfica do Windows.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

__Concordo! É uma burrice di: __Concordo! É uma burrice dizer que o Desktop do Linux é um lixo e que o do WIndows é melhor...O desktop do Windows é horrível!Integrado ao Kernel do sistema, frequentemente derruba toda uma rede devido a uma falha de acesso na memória, ou de segmantação,coisa que no Linux se resolve com um Xkill, que já está no Menu K. E o Linux já isola o diretório do usuário do sistema, é o HOME, uma casinha altamente sugestiva que convida o usuário a salvar seus arquivos nela.É a similaridade com a vida!

__Quanto aos pacotes. . .Em três anos instalando quilos de programas usando Debian, só tive dois problemas com dependências.Com o Kurumin, você nem precisa saber o que é gerenciador de pacotes.Parece que realmente é um problema sério ter 20.0000 aplicativos gratuitos disponíveis...Possivelmente o "outro" é melhor já que nele se paga até pra ligar o computador.

__O artigo falha pois nivela o Linux por baixo.Parece que todos são iguais, todos têm dependências desencontradas, parece que o KDE é ruim, e não o sujeito que configura, empacota e pôe na distro, pois o Kde é ótimo , só que tem que configurar antes de jogar pro usuário.O autor simplesmente parece não saber da existência do KliK do Knoppix que joga todas as libs no mesmo diretório, acabando com as dependências...Ou seja, o Linux é ruim pra desktop, porque é robusto, pois acaba com a redundância de biblioteas em 500 diretórios diferentes triplicando o tamanho da instalação final, porque calcula todos os pacotes, instala-os e ainda cria um ícone no desktop...Quan do esse pessoal faz análise eles sempre consideram a distro mais díficil e mais hacker, como Slackware. Paciência!BOm é ser ruim como o Windows!

Finanlmente: // Duplicado //

Finalmente: Douglas
"Isso é verdade, uma IDE madura e completa como o Delphi facilitaria as coisas. Mas seria melhor se fosse portável (produzisse código compilável em outros sistemas/arquiteturas)"

Na minha opinião é isso ai, uma IDE completa e madura como o Delphi que produza código para qualquer sistema/arquitetura.

Com esta solução teríamos vários sistemas portados para o Linux, mais bem que a Borland tentou mais pelas noticias foi comprada pela Microsoft, até contratou o pai do Delphi para fazer o .NET, fazer o que, agora é esperar que alguma solução apareça ou alguma grande empresa queira comprar esta briga, com uma linguagem compilada e uma IDE para aplicações Desktop.

Finalmente duplicado: // Triplicado //

:P

-: No contexto, a Apple é um mal exemplo para comparar com linux porque usa todos os métodos distintos de instalação dum programa, oras BSD (./configure;make;make install), oras Windows (next->next->finish), oras arrastanto e soltando (.dmz) ao ínves de concentrar num único modelo de instalação, como no Windows que é um InstallShield sempre.

Meu comentário nada tem a ver com praticidade mas (novamente falando) com uma má comparação entre Apple e Linux no sistema de distribuição de programas, se fosse para falar do tema 'praticidade', para mim que já conheço, um apt-get install [programa] ou usar um synaptic para mim é mais prático do que escolher uma pasta para arrastar ou seguir longos next->next->finish (concordando com contratos que nem valem por aqui).

Por fim, voce não lê o contexto ou está afim de me sacanear. Muito mal.

-: "O MacOX da Apple tem um padrão gráfico.
O Windows tem um padrão gráfico.
O Linux/BSD não tem padrão gráfico."
- lê-se :
O MacOX da Apple tem 1 unico ambiente gráfico.
O Windows tem 1 unico ambiente gráfico.
O Linux/BSD tem muitos ambientes gráficos.

Acho que voces estão brigando com o vento, o alessandro prefere um unico ambiente grafico e o colega fica replicando com quem tá a fim de usar apenas um unico ambiente grafico e confude claramente ambiente grafico(=motor grafico) com bibliotecas graficas. Ou seja, ele está atrás do simplismo (nao confundir com simplicidade).
A MFC foi por anos a única (ok, generalizei) e depois a principal biblioteca no windows, é por isso a falsa sensação de padrão grafico. O delphi e VB usavam por frameworks (ou MFC) a win32api o que tornava esse "padrão" ainda maior. Agora que já tem GTK, Fox, QT,... para windows, começam a popular programas que nem deveriam existir no windows : gimp, evolution,... se todos os programas para linux com suas diversas bibliotecas fossem portados para windows, acaba com a idéia que no windows existe apenas uma biblioteca gráfica e os programas que o alessandro apontou no linux passam a ser do windows tambem. Ninguem deixaria de usar o K3B para Windows só porque teria que instalar o QT, até porque o k3b supera com vantagens no nero.

.: hamacker, mais ter várias bibliotecas gráficas rodando juntas QT, GTK, Fox,... não sobrecarrega a máquina pois todas tem o mesmo objetivo, sendo assim se vou usar aplicativos que utilizam bibliotecas diferentes ao mesmo tempo estarei carregando as mesmas, sobrecarregando a máquina. certo?

Como desenvolvedor quero simplicidade no ambiente gráfico, e hoje apenas os SO que possuem apenas um ambiente gráfico me proporcionam isso, pois sei exatamente o que o usuário esta usando. Com isso o suporte fica muito mais fácil. Sei que poderia "obrigar" os meus clientes a usarem uma distribuição e um ambiente gráfico mais com isso limitaria os meus clientes porque nem todos concordariam com isso. (dou razão a eles)

O ambiente gráfico do Linux vai contra a um ponto forte do Linux, as dependências, pois com as mesmas não precisamos reinventar a roda só que a cada dia que passa vão surgindo mais e mais bibliotecas gráficas que são independentes ou seja refazem todo o trabalho que ja tem pronto. Na minha opinião todos brigando para se tornar um padrão no Linux e não cooperando entre si (querem ser o pai da criança).

Fora de Tema: Augusto, por favor, crie urgente uma categoria chamada ping-pong ;)

Alexandre Martins
Visite www.nuca.org.br