> > Portanto, os desktops n�o s�o incompat�veis. Pelo contr�rio, voc� pode
rodar
> > aplicativos de um dentro do outro numa boa.
>
> Nao me referia a este tipo de imcompatibilidade, e sim coisas mais
simples... por
> exemplo, as cores das janelas... uma configura��o de cor ou tema qua fa�o
no meu
> WindowMaker, nao � mantida ao abrir o o Kmail por exemplo....
Olha, um colega da lista j� sugeriu que fosse feito um an�lago ao
COM/DCOM do Windows para resolver esse problema... N�o lembro quem era e nem
quero come�ar uma flame-war, s� colocar uma opini�o.
NMHO(IMHO em portugu�s ;)), fazer uma COM igual ao que a microsoft fez
seria um baita de um chuncho! Porque ao inv�s de padronizar todos os seus
produtos com um mesmo modelo de programa��o, ela lan�ou uma biblioteca nova
que "cola" todas as "partes soltas" do windows.
Ou seja, � a M$ pagando pelos seus pecados (de n�o seguir os padr�es do
mercado e nem entre seus pr�prios produtos). Ao fazermos uma biblioteca COM
para os diferentes ambientes gr�ficos do Linux, estar�amos caindo na mesma
onda da M$ de fazer produtos incompat�veis e algo pra colar tudo junto numa
s� coisa.
Se for pra fazer chuncho, a� � que a Microsoft vence o Linux pela
experi�ncia! ;) hehehe
Isso seria contra filosofia UNIX, n�o? Ali�s, de qu� adianta ter
c�digo-fonte aberto se eles n�o chegam a um consentimento comum sobre
caracter�sticas comuns como copiar-e-colar e temas?
> Nao concordo com isso!! J� tive muitas vezes problemas tentando copiar e
colar do netscape para o Kmail por exemplo, e vice versa.... no caso de
uma URL, eu acabava tendo que posicionar uma janela ao lado da outra para
poder copiar na m�o.
>
> E isso n�o se restringe apenas ao Copiar/Colar.... aos tipos MIME tbem...
uma associa��o que eu fazo no gnome (gmc) num vai funcionar no kde
(konqueror), e assim por diante...
O que eu imagino que seja uma solu��o boa seria fazer a �rea de
transfer�ncia e as configura��es de MIME como m�dulos separados e comuns,
para serem carregados por qualquer que seja ambiente que estiver rodando.
Isso quer dizer que o aplicativo sempre jogar� o que "copiar" para este
m�dulo de "�rea de transfer�ncia", e qualquer outro aplicativo/ambiente
poder� captur�-lo.
Padronizando os MIME tamb�m seguiria a mesma solu��o, com a diferen�a de
ser somente leitura creio eu...
> Ser� mesmo?? Nao seria uma boa o X gerenciar a �rea de Transferencia???
Para assim n�o termos mais problemas com o Cut e Paste...
>
> Eu acho q vc tah se esquecendo que n�o � simplesmente rodar um aplicativo
de um
> gerenc. dentro do outro que eh compativel, pq nao eh... nao adianta
apenas rodar,
> precisa compartilhar informa�oes, se introsar mais um com o outro...
Pelo jeito algu�m concorda sobre a �rea de transfer�ncia, mas acho que
deixar isso a cargo do X � desnecess�rio. N�o seria mais f�cil e pr�tico
criar um device block no /dev/ para fazer este servi�o? :) Cria-se um padr�o
para vir um cabe�alho antes dos dados especificando o tipo de dado que foi
copiado, e a aplica��o determinar� se ela � capaz de suport�-lo (para
evitar, por exemplo, que se copie uma imagem e tente col�-la numa caixa de
texto :P)
> Claro que os fontes estao abertos e tudo.... mas nada � tao simples
assim...todo mundo
> sabe disso.... vou te explicar melhor isso com exemplos bem "banais"...
o KDE tem a
> sua calculadora (kcalc) e o gnome a dele (gcalc). Sao dois aplicativos com
>EXATAMENTE a mesma fun��o! Entao por que o pessoal do KDE ao inv�s de
> desenver a sua calculador, simplesmente nao colocou a do gnome no KDE...
ou vice
>versa?? Pra que perder tempo escrevendo um codigo que ja esta escrito??
Que como vc
>mesmo disso, eh soh entrar no site do outro e pegar os fontes?? Eu sei que
aih tem
>aquelas historias que os aplicativos gnome dependem do gtk... e o KDE do
qt... e eh
>exatamente aih que tah mais um exemplo de "incompatiblidade"... ou falta de
>introsamento!!
Agora chega a quest�o dos temas. � claro que seria "meio dif�cil"(insmod
sarcasmo.o) de transformar um aplicativo escrito em QT para o modo de
exibi��o de temas do Sawfish ou do E.
Mas as toolkits poderiam ser capazes de "detectar o b�sico" de um tema
para us�-lo - a� j� n�o � mais quest�o de ambiente, mas dos desenvolvedores
do GTK e do QT.
Por exemplo, se voc� est� no Sawfish e roda o KCalc, o QT deveria
dinamicamente detectar o gerenciador que est� rodando (e isso � f�cil, fica
como vari�vel de ambiente) e, baseado nisso, ler o tema DELE em busca de
dados que ele possa suportar.
Assim, o KCalc que n�o suporta os temas avan�ados que mudam
completamente no Sawfish pode pegar pelo menos as cores b�sicas do tema para
aplic�-los na janela do KCalc...
> Se todos os grupos de desenvolvimento de gerenciadores de janelas se
junta-sem
>mesmo, colabora-sem um com os outros, ao inv�s de concorrer (que eh
exatamente o que
>acontece, KDE e Gnome estao "brigando" para conquistar mais usuarios" hoje
estariamos
>muito mais seguros a trabalhar no linux com desktop.
Um outro colega da lista j� mencionou que � importante a competi��o. Se
o pessoal do KDE ou do Gnome estiverem levando isso pro lado pessoal ou n�o,
� um problema mais filos�fico do que pr�tico - desde que a competi��o ocorra
justamente, sem apela��es.
Al�m do mais, eles est�o cientes de que v�rios usu�rios misturam seus
gerenciadores. N�o concordar com uma padroniza��o seria idiotice...
Jokka
Assinantes em 27/05/2001: 2294
Mensagens recebidas desde 07/01/1999: 115311
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
