gildot

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


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

 
A fundação X.org anunciou o X11 v6.8.0
Contribuído por scorpio em 10-09-04 9:11
do departamento X-marks-the-spot
X Kmos escreve "Esta nova versão 6.8.0 do X11, traz novidades como janelas sombreadas e translúcidas, havendo a possibilidade de se colocar diferentes valores para cada uma delas. O XDamage, é um novo sistema que faz com que apenas desenhe as partes da janela que foram danificadas, poupando agora mais processamento. O XComposite ainda está numa versão experimental, mas parece que já funciona minimamente bem.. Podes ver screenshots aqui. "

Conferência - Software Aberto | Especificações do OpenGL 2.0 cá fora!  >

 

gildot Login
Login:

Password:

Referências
  • Kmos
  • 6.8.0
  • aqui
  • Mais acerca X
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Belo... (Pontos:1)
    por falso em 10-09-04 9:38 GMT (#1)
    (Utilizador Info) http://rdk.homeip.net
    Bela cena, emerging :->

    Aquele engate das sombrinhas das janelas ta memo do bufo.

    ----------------------------
    if it bleeds, we can kill it
    Re:Belo... (Pontos:3, Esclarecedor)
    por fhc em 10-09-04 11:43 GMT (#2)
    (Utilizador Info)

    O melhor do X.org não é o X11R6.8, mas a nova dinâmica impressa ao X. O XFree86 estava estagnado e já podres andavas as águas. Os poucos patch que eram aceites normalmente eram roubados. Basta dizer que fui eu que fiz o ficheiro de teclado para o X e não aparece lá o meu nome. Por outro lado, este apareceu de prontamente no da consola.

    Com o Cairo, que já tive o prazer de programar, o X tem finalmente algo de rápido para desenho com translucência em modo imediato. Estou a pensar criar uma biblioteca sobre Cairo em modo estruturado, já que me facilitaria muito a vida naquilo que quero fazer.

    O Xdamage e o Composite não são eye candy. São necessidades nos sistemas gráficos actuais.

    Francisco Colaço


    Deus dê saúde aos meus inimigos para que assistam de pé à minha vitória.

    Lema inscrito num barco bandeirante.

    Re:Belo... (Pontos:1)
    por rnbc em 10-09-04 17:14 GMT (#4)
    (Utilizador Info)
    Impressa? que tal imprimida/dada/transmitida hein? :)

    Cof... eu fiz o ficheiro para o teclado tuga do X (pelos idos 1994 e posteriormente para o XKB extension) e também não aparece lá o meu nome... se calhar houve umas dúzias de gajos a fazê-lo.

    O windows não tem própriamente Xdamage... e eu acho que com as placas actuais a terem 256M de memória o X fazia melhor figura de usasse backing-store para tudo.

    Foram os meus 2 centimos...
    Re:Belo... (Pontos:2)
    por fhc em 11-09-04 18:41 GMT (#22)
    (Utilizador Info)

    Eu fiz o actual teclado em 98. Sabes então o que é apanágio da casa. Por mim, que viva o X.org.

    Francisco Colaço


    Deus dê saúde aos meus inimigos para que assistam de pé à minha vitória.

    Lema inscrito num barco bandeirante.

    Re:Belo... (Pontos:2)
    por fhc em 12-09-04 11:04 GMT (#26)
    (Utilizador Info)

    E quanto ao impressa, muito bem visto, penitencio-me aqui. Foi distração.

    Quanto ao XDamage, esse será muito útil aquando da transmissão em rede. Nomeadamente, se apenas uma parte de uma janela em raster for invalidada, apenas essa parte deve ser redesenhada, especialmente se a rede for o gargalo. É claro que uma biblioteca de desenho estruturado poderia invalidar apenas um objecto ou um widget, mas isso tem de ser criado. E, para tal, a API do Cairo tem de estabilizar.

    Francisco Colaço


    Deus dê saúde aos meus inimigos para que assistam de pé à minha vitória.

    Lema inscrito num barco bandeirante.

    expose (Pontos:2)
    por ruben dig em 10-09-04 12:24 GMT (#3)
    (Utilizador Info) http://www.floppy.com.pt
    ainda sem ter as mesmas funcionalidades do mac os X apareceu um programa chamado kompose que é mais uma coisa bonita no kde ...

    http://kompose.berlios.de/

    Re:expose (Pontos:2)
    por blacksheep em 10-09-04 18:40 GMT (#5)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Nem de propósito, este artigo recente fala um pouco do Kompose e ainda conta com algumas screenshots.

    Segundo comentários no dot.kde.org, a próxima versão do Kompose irá fazer uso do XCompose.
    Re:expose (Pontos:2)
    por The CodeMaker em 10-09-04 19:52 GMT (#6)
    (Utilizador Info)
    Já estou a usar isso e estou a gostar. Não funciona perfeitamente mas o suficiente para não prejudicar o meu trabalho. Gostava era de ter uma tecla associada em vez de ter que clicar com o rato no icon do sys tray.

    --
    CodeMaker
    Re:expose (Pontos:2)
    por [Cliff] em 10-09-04 20:25 GMT (#8)
    (Utilizador Info) http://www.yimports.com
    Aquilo tem um global shortcut que podes usar... De qualquer das maneiras, aquilo que ninguém diz é que funciona com o Gnome/Metacity também :)
    Outra coisa que também ninguém diz é que o Exposé, por aquilo que já tive oportunidade de ver, não funciona com screenshots... aquilo redimensiona *mesmo* as janelas e as ditas janelas estão "vivas".
    Ainda assim, o Komposé é giro e tal, mas é melhor usado o alt-tab c/ recurso aos virtual desktops...

    ---
    MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug.
    Re:expose (Pontos:2)
    por blacksheep em 10-09-04 21:46 GMT (#9)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Outra coisa que também ninguém diz é que o Exposé, por aquilo que já tive oportunidade de ver, não funciona com screenshots... aquilo redimensiona *mesmo* as janelas e as ditas janelas estão "vivas".

    Segundo um comentário no dot.kde.org, parece que o Komposé CVS junto com o XCompose também não permite a tiragem de screenshots:
    Although Hans gave that impression, I now think (looking at the blog) that he's currently got it detecting and using XComposite when available, otherwise working old-style.

    The old-style screenshotting is needed in the code anyhow, due to unforeseen limitations of XComposite (see his blog).

    Re:expose (Pontos:2)
    por [Cliff] em 10-09-04 22:05 GMT (#11)
    (Utilizador Info) http://www.yimports.com
    hmmm vai então replicar o comportamento do MacOS X? Se sim, isso não são boas notícias, são excelentes(!) notícias!

    ---
    MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug.
    Re:expose (Pontos:2)
    por blacksheep em 11-09-04 9:47 GMT (#15)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    hmmm vai então replicar o comportamento do MacOS X?

    Uh? O que aquele comentário diz é que não será possível tirar screenshots quando usado o Komposé juntamente com o XCompose.
    O comportamento do Komposé deve permanecer o mesmo. Eu nunca experimentei o Komposé, mas tu dizes nountro comentário que o experimentaste, então diz me tu: é uma replica do Exposé?
    Re:expose (Pontos:2)
    por [Cliff] em 11-09-04 17:04 GMT (#20)
    (Utilizador Info) http://www.yimports.com
    Nope... tenta fazer o mesmo serviço mas está bastante àquem tanto em qualidade como performance.

    ---
    MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug.
    Re:expose (Pontos:2)
    por The CodeMaker em 10-09-04 23:12 GMT (#12)
    (Utilizador Info)
    Ah! Com o keyboard shortcut fica bastante mais usável. Mesmo assim nada que se compare à usabilidade do exposé. Talvez mais tarde.

    --
    CodeMaker
    Re:expose (Pontos:2)
    por Castanheiro em 11-09-04 0:09 GMT (#13)
    (Utilizador Info) http://mozilla.shopizzy.com
    Tive a dar uma olhada, e num athlon 2200 o kompose ainda demora uns 4 segundos a desenhar as janelas todas (4 ou 5 janelas), o que o torna muito engraçado mas impróprio para uso comum...
    Re:expose (Pontos:2)
    por The CodeMaker em 11-09-04 8:11 GMT (#14)
    (Utilizador Info)
    Athlon XP 2600, ATI Radeon 9200, demora menos de 1 segundo mas mesmo assim acho demais.

    --
    CodeMaker
    Re:expose (Pontos:2)
    por Kmos em 11-09-04 12:27 GMT (#18)
    (Utilizador Info) http://Kmos.TondelaOnline.com
    Também ainda está em desenvolvimento, é preciso ir com calma... "O XComposite ainda está numa versão experimental, mas parece que já funciona minimamente bem.."

    I'm a Lost Soul in this Lost World...
    Re:expose (Pontos:2)
    por blacksheep em 11-09-04 13:16 GMT (#19)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Ele estava a referir-se ao Komposé, não ao XCompose!
    A última versão do Komposé ainda não usa o XCompose.
    Re:expose (Pontos:2)
    por blacksheep em 11-09-04 9:48 GMT (#16)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Velocidade sem fazer uso do XCompose, certo?
    Mesmo que fizesse uso do XCompose, se não tiveres aceleração gráfica, julgo que não irá adiantar de muito...
    Re:expose (Pontos:2)
    por Castanheiro em 11-09-04 17:19 GMT (#21)
    (Utilizador Info) http://mozilla.shopizzy.com
    Certo! Sem XCompose, com uma resolução de 1280x1024 a 32bits com meia duzia de janelas abertas.
    nada q nao se faca com um bom x|term (Pontos:2)
    por racme em 10-09-04 20:16 GMT (#7)
    (Utilizador Info) http://tinyurl.com/2zvku





    Santanás: The power to serve!
    Re:nada q nao se faca com um bom x|term (Pontos:3, Informativo)
    por blacksheep em 10-09-04 21:53 GMT (#10)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Não sei a que te referes, mas se for em relação a transparências, o que as consolas gráficas fazem é apenas um truque muito pouco elegante e lento.
    Recolhem o pedaço de background que está por detrás da consola e metem-no como seu background, adicionando uma color mask preta para o efeito de transparência. Este processo é lento e provoca lagging quando a janela da consola é arrastada.
    O pior disto é que se estiver outra janela atrás, esta é cortada. Ou seja, esta pseudo-transparência serve apenas e exclusivamente como eye-candy e não tem qualquer usabilidade. Transparências a sério, para além do eye candy, podem mesmo ser úteis.
    Re:nada q nao se faca com um bom x|term (Pontos:2)
    por racme em 12-09-04 2:52 GMT (#25)
    (Utilizador Info) http://tinyurl.com/2zvku
    o que as consolas gráficas fazem é apenas um truque muito pouco elegante e lento.

    Ai os malandros... nao sei bem onde e' q um xor pode ser lento...

    E' um truque simples, eficaz e que nao consome recursos, obrigado!
    Dizeste bem pseudo-transparencia, e sabes que mais? Chega perfeitamente! Mais uma vez obrigado!





    Santanás: The power to serve!
    Re:nada q nao se faca com um bom x|term (Pontos:2)
    por blacksheep em 12-09-04 14:31 GMT (#29)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Ao referir lento e gastar recursos estava a referir-me a quando uma janela é movida.
    Por mais rápido que um blitting seja, tens que optar por: lagging ou consumo de recursos, quando movida a janela.

    Eu (e para mais umas quantas pessoas) este truque não é suficiente e, por isso, é que é agora suportado pelo X.org.
    XDamage? mesmo necessário? (Pontos:2)
    por blacksheep em 11-09-04 9:59 GMT (#17)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Quando programei em Qt era possível apenas redesenhar a parte da janela necessária. Cada widget recebe uma chamada da função QPaintEvent(), cada vez que é necessário um refresh, sendo alimentada com a área necessária de ser redesenhada.
    Pelo pouco que li sobre o GTK, este também funcionará de modo semelhante.
    Afinal, porque é necessário o XDamage? Será que esta técnica estava apenas a ser usada a nível de bibliotecas e não do X?

    Outra coisa, quando podemos esperar por uma biblioteca embutida no X que faça o desenho de widgets? E se podemos mesmo esperar por uma...
    Isto de cada biblioteca gráfica ter o seu próprio conjunto de desenho, não dá só mau aspecto ao utilizador, que tem que aturar com aplicações com looks totalmente distintos, como é mau para a biblioteca que se torna enorme, fazendo com que o sistema acabe por ficar com lento com tantos monstrinhos a chupar os recursos e não possibilita a lincagem estática de aplicações.
    Sim (Pontos:2)
    por CrLf em 11-09-04 21:17 GMT (#23)
    (Utilizador Info) http://crodrigues.webhop.net
    Afinal, porque é necessário o XDamage? Será que esta técnica estava apenas a ser usada a nível de bibliotecas e não do X?

    Os toolkits só redesenham as áreas afectadas, é verdade, mas também é verdade que a extensão XDamage não tem nada a ver com isto. O XDamage é uma forma dos clientes poderem monitorar zonas modificadas do ecrã, o que é útil para programas tipo VNC que precisam de saber o que foi modificado para enviarem apenas isso e não todo o ecrã, ou para um gestor de composição que precisa de saber o que vai sendo modificado para poder actualizar as composições. Ver texto.

    Outra coisa, quando podemos esperar por uma biblioteca embutida no X que faça o desenho de widgets?

    No dia de São Nunca, da parte da tarde. Por um lado não faz sentido uma biblioteca "embutida" pois não traz vantagem nenhuma (em termos de performance ou tamanho) "embutir" um toolkit num sistema gráfico. O mais que poderia acontecer era o X trazer um toolkit de origem, mas quem diria que esse toolkit seria aceite por toda a gente? Para além do mais, nem no Windows que é o que a gente sabe em termos de "embutimento" tem um toolkit nesses moldes...

    Isto de cada biblioteca gráfica ter o seu próprio conjunto de desenho, não dá só mau aspecto ao utilizador, que tem que aturar com aplicações com looks totalmente distintos, como é mau para a biblioteca que se torna enorme, fazendo com que o sistema acabe por ficar com lento com tantos monstrinhos a chupar os recursos e não possibilita a lincagem estática de aplicações.

    Estás aqui a fazer uma tremenda confusão, todas as bibliotecas usam o mesmo conjunto de desenho, o do X. E as bibliotecas não são enormes por nenhuma razão para além das suas próprias funcionalidades, além de que isso não chupa os recursos mais do que chuparia se fosse parte do X (lá por a biblioteca ter funcionalidades não quer dizer que todas estejam a ser usadas ao mesmo tempo). Por outro lado também não impede a linkagem estática das aplicações (nas raras instâncias onde tem interesse prático). Se queres um toolkit para linkar estaticamente sem aumentar consideravelmente o tamanho do binário, podes ver o fltk.

    Resumindo, se o X viesse de origem com um toolkit, seria apenas mais um, e se até hoje o GTK não venceu o Qt nem vice-versa quem diria que um toolkit abençoado pelo X o faria?

    PS: por acaso o X traz um toolkit, o Xaw.

    -- Carlos Rodrigues
    Re:Sim (Pontos:2)
    por blacksheep em 12-09-04 14:24 GMT (#28)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Obrigado pelo esclarecimento quanto ao XDamage.

    Mas quanto ao desenho de widgets pelo X.org, eu não me estava a referir mesmo a um toolkit, mas apenas a uma biblioteca que fosse usada pelos diversos toolkits e que fosse a responsável pelo desenho dos widgets (botões, combos/radio boxes, scrollbars, etc).
    Tal como acontece no Y Windowing System e julgo que no Mac OSX.

    O facto do Windows não fazer isto não quer dizer que o X também não o deva fazer, ou será que tudo em Linux deve andar de reboque da Microsoft?
    Re:Sim (Pontos:2)
    por CrLf em 12-09-04 18:22 GMT (#30)
    (Utilizador Info) http://crodrigues.webhop.net
    Mas quanto ao desenho de widgets pelo X.org, eu não me estava a referir mesmo a um toolkit, mas apenas a uma biblioteca que fosse usada pelos diversos toolkits e que fosse a responsável pelo desenho dos widgets (botões, combos/radio boxes, scrollbars, etc).

    A questão é que isso é o toolkit. Se tirarmos o desenho dos widgets ao GTK, não sobra nada.
    No caso do Y, os widgets estão embutidos para permitir que as suas estruturas de controlo estejam do lado do cliente e optimizar o protocolo, o que não acontece no X, em que tudo está do lado do servidor, no cliente estão apenas os pixmaps e o código de desenho de widgets é server-side.

    Eu compreendo a ideia, mas não concordo com ela, até porque o protocolo do X não é mau como o pintam, basta ver que no tempo da sua introdução as redes ethernet de 10Mbps eram uma miragem. O problema está muitas vezes no excesso de round-trips impostas pelo toolkit (apesar de que isto tem vindo sempre a ser resolvido, tanto no GTK como no Qt) e no uso excessivo de themes (basta ver que um dos protocolos mais rápido, o RDP, tem associado o desligar dos themes no Windows, e por outro lado aplicar compressão -- ssh, por exemplo -- a uma sessão X aumenta brutalmente a performance).

    Para mim o sistema gráfico deve fornecer as primitivas e o resto deve ser fornecido por uma camada acima. Esta separação tem pouco impacto na performance e um grande impacto na liberdade de evolução do sistema. Embutir tem vantagens duvidosas em troca de uma maior inflexibilidade. Se se embutisse o GTK no X (exemplo aleatório) isso aumentaria as barreiras à evolução do toolkit e as probabilidades de este ficar para trás e ser ignorado.

    No caso do MacOS X também não me parece que tenha um toolkit embutido, o que neste caso nem sequer faz algum sentido como no Y, pois o Quartz não tem transparência de rede. O que tem é um toolkit abençoado.

    O que eu posso entender do que estás a dizer é que, no MacOS X, coisas como o Qt usam o que podem desse toolkit abençoado para se parecerem o mais possível com o resto do sistema. Mas não esquecer que comparar o MacOS X ao X não é justo, pois o X é um sistema gráfico e o MacOS X é tudo. Podes pegar no X e enfiá-lo num sistema embebido (usando um toolkit com widgets radicalmente diferentes, por exemplo) e o MacOS X não. Talvez se pudesses pegar no Quartz isoladamente a comparação já se poderia fazer, mas como disse, AFAIK o toolkit do MacOS X também está acima do Quartz.

    -- Carlos Rodrigues
    Re:Sim (Pontos:2)
    por blacksheep em 13-09-04 11:58 GMT (#32)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    A questão é que isso é o toolkit.

    A meu ver, toolkit (do inglês conjunto de ferramentas) é constituído pela biblioteca, documentação, ferramentas para RAD, etc. Estou apenas a refirir-me à biblioteca.

    O que eu posso entender do que estás a dizer é que, no MacOS X, coisas como o Qt usam o que podem desse toolkit abençoado para se parecerem o mais possível com o resto do sistema.

    Exactamente. Uma biblioteca light embutida que fosse suficientemente high level para desenhar e gerir eventos para uma série de widgets.
    Biblioteca esta que seria depois utilizada pelas restantes. Tal como é feito actualmente com a Xlib, apenas sendo uma de mais alto nível.

    A Xlib poderia continuar lá para assegurar compatibilidade com aplicações antigas.
    Re:Sim (Pontos:2)
    por CrLf em 13-09-04 13:49 GMT (#33)
    (Utilizador Info) http://crodrigues.webhop.net
    A meu ver, toolkit (do inglês conjunto de ferramentas) é constituído pela biblioteca, documentação, ferramentas para RAD, etc. Estou apenas a refirir-me à biblioteca.

    A biblioteca é o toolkit, aquilo que permite desenhar widgets e tal, o resto são acessórios.

    Exactamente. Uma biblioteca light embutida que fosse suficientemente high level para desenhar e gerir eventos para uma série de widgets. Biblioteca esta que seria depois utilizada pelas restantes. Tal como é feito actualmente com a Xlib, apenas sendo uma de mais alto nível.

    Estás a confundir as coisas, a Xlib não é um toolkit, a Xlib é uma biblioteca gráfica. Fornece linhas, ovais, polígonos, drawables e afins, não desenha widgets.

    -- Carlos Rodrigues
    Re:Sim (Pontos:2)
    por CrLf em 13-09-04 13:51 GMT (#34)
    (Utilizador Info) http://crodrigues.webhop.net
    Hummm, esqueci-me de continuar.

    O que falas não seria diferente de o GTK passar a fazer parte do X. Isso não teria vantagem nenhuma, tal como já disse.

    -- Carlos Rodrigues
    Re:Sim (Pontos:2)
    por blacksheep em 13-09-04 15:06 GMT (#35)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Teria vantagem para o utilizador de desktop que não teria que aturar com aplicações de look'n feel totalmente distintas.
    Re:Sim (Pontos:2)
    por CrLf em 13-09-04 15:17 GMT (#36)
    (Utilizador Info) http://crodrigues.webhop.net
    Como é que ias convencer os programadores a usar o toolkit do X em vez de outro? Embutir no X seria o mesmo que abençoar um determinado toolkit, não garantiria que alguém lhe ligasse pevide. No limite podia abençoar-se o GTK e passar a incluí-lo no pacote do X, com os bindings para linguagens que não o C em pacotes externos, mas isso não iria fazer com que o KDE largasse o Qt, nem iria fazer com que alguém se lembrasse de implementar toda a interface (API) do Qt usando o GTK por baixo.

    -- Carlos Rodrigues
    Re:Sim (Pontos:2)
    por blacksheep em 13-09-04 17:22 GMT (#37)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    Como é que ias convencer os programadores a usar o toolkit do X em vez de outro?

    O que eu tentaria convencer era os diversos toolkits a desenharem os widgets através de chamadas a essa biblioteca (toolkit, como gostas de chamar) do X.

    No limite podia abençoar-se o GTK e passar a incluí-lo no pacote do X

    Com alguma limpeza do GTK para o tornar mais robusto e light, acho que seria uma excelente ideia.

    isso não iria fazer com que o KDE largasse o Qt, nem iria fazer com que alguém se lembrasse de implementar toda a interface (API) do Qt usando o GTK por baixo.

    Bem, já houve um gajo que fez o GTK a usar o Qt para o desenho dos widgets: GTK-Qt Theme Engine Does Cross-Desktop Styling
    Porque não o contrário?
    Re:Sim (Pontos:2)
    por CrLf em 13-09-04 20:11 GMT (#38)
    (Utilizador Info) http://crodrigues.webhop.net
    O que eu tentaria convencer era os diversos toolkits a desenharem os widgets através de chamadas a essa biblioteca (toolkit, como gostas de chamar) do X.

    O que estás a falar é de um "theme engine" comum aos toolkits, uma forma de definir que aparência básica deve ter qualquer coisa semelhante a um botão. Ora poderia haver um theme engine comum ao GTK e ao Qt, mas isso não faria dele candidato a ser incluido no X, simplesmente porque uma coisa dessas não é do domínio de um sistema gráfico como o X.

    Com alguma limpeza do GTK para o tornar mais robusto e light, acho que seria uma excelente ideia.

    Seria uma boa ideia se se quisesse ver toda a gente a fugir para outro toolkit menos light, mas com mais funcionalidade.

    Bem, já houve um gajo que fez o GTK a usar o Qt para o desenho dos widgets

    Pelo que sei isso não funciona particularmente bem do ponto de vista da estabilidade, nem sequer despertou grande interesse prático. Por outro lado é importante não esquecer que os toolkits têm designs internos diferentes e, portanto, "theme engines" também bastante diferentes. Tentar enfiar uma peça redonda num buraco quadrado não funciona.

    Quero finalizar com outra consideração. Empacotar um toolkit com o X seria comprometê-lo com esse toolkit, tornando muito dificil a sua evolução futura e obrigando a mantê-lo durante anos e anos após se ter tornado obsoleto. Não queremos repetir o caso do Xaw, que na altura pareceu inteligente incluir no X e hoje é uma peça de arqueologia que não podem remover, porque há sempre algum software irrelevante que ainda usa aquilo (e nem sequer o Xaw3d nem nada disso o salvou). O Xaw é um bom exemplo do que acontece quando se enfia um toolkit no X, imagine-se se o Motif tem lá caído também...

    -- Carlos Rodrigues
    Re:XDamage? mesmo necessário? (Pontos:1)
    por Perky_Goth em 11-09-04 23:37 GMT (#24)
    (Utilizador Info) http://www.fe.up.pt/freefeup
    em relação à ultima questão, o KDE e o Gnome têm um projecto para unificar o look n feel, deforma que mudando os settings num sítio, se mude em ambos os conjuntos de aplicações.
    nada a ver com o BlueCurve, portanto :P
    -----
    Microsoft has funded 13 studies over the past year comparing Linux with its own products. Guess what: All of them come out in favor of Microsoft.
    incompatibilidades (Pontos:1)
    por presidente em 12-09-04 12:20 GMT (#27)
    (Utilizador Info)
    Como cheguei a constar a Extenção 'Composite' que é a mesma que permite transparencias e sombras quebra alguns programas GTK e mais grave é mesmo o caso do fluxbox 0.9.9 ficar sem "slit" e aterm deixa de se puder usar com normalidade, neste caso só falta mesmo segfaultar.
    Re:incompatibilidades (Pontos:2)
    por CrLf em 12-09-04 18:24 GMT (#31)
    (Utilizador Info) http://crodrigues.webhop.net
    Isso com o X.org ou com o Xserver do freedesktop.org? Mas também por alguma razão o XComposite vem desactivado por omissão, porque tal como diz nas release-notes, ainda está em desenvolvimento e precisa de evoluir um bocado antes de estar pronto para consumo geral.

    -- Carlos Rodrigues
    Re:incompatibilidades (Pontos:1)
    por presidente em 16-09-04 16:40 GMT (#39)
    (Utilizador Info)
    Com o X.org xserver.

     

     

    [ Topo | FAQ | Editores | Contacto ]