| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Sinceramente, o que falta fazer é criar uma uniformização entre Gtk e Qt. (E quem diz estes, diz Tcl/Tk, Motif...).
Não sei quanto a vocês, mas a mim irrita-me abrir vários programas e cada um deles apresentar um layout diferente. Talvez não fosse ao nível de cada um, mas ao nível da distribuição, uma abstracção que sobrepusesse aos widgets de cada uma das APIs gráficas. Não sei até que ponto isto seria exequível, mas um pouco mais de uniformidade (dando, sempre, a possibilidade de alterar isto) era desejável.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| | | | | | | Sinceramente, o que falta fazer é criar uma uniformização entre Gtk e Qt. O grande mal começou com a criação do Gnome. O Linux e outros Unix não beneficiaram nada com o surgimento do Gnome. Antes pelo contrário. O Gnome serviu apenas para fragmentar o desktop em Linux, sabotando aquele que tinha sido o objectivo principal de Matthias Ettrich, o criador do KDE: a construção de um desktop environment em que os utilizadores poderiam esperar que os programas tivessem um aspecto e um comportamento consistente. Era trazer a consistência e interoperabilidade que há anos já existia em Windows e MacOS para o mundo do Unix. O Gnome surgiu da cabeça de alguns talibans da GNU que, ao invés de procurarem negociar com a Trolltech um modelo de licenciamento GPL (licença que a empresa viria a adoptar pouco depois), criaram um projecto à parte, fragmentando assim o desktop do Linux, contribuindo para a popularização do GTK (um toolkit em tudo inferior ao Qt), e abrindo o caminho para o nascimento de um desktop environment que tem andado sempre atrás do KDE em praticamente todos os aspectos. Há quem argumente que o surgimento do Gnome foi positivo pois introduziu o factor competição e, desta forma, estimulou o KDE a evoluir. Isto é uma falácia. O KDE não precisa nem nunca precisou do Gnome para evoluir. As grande referências do KDE, os seus grandes concorrentes, são o Windows e o MacOS X (o Aqua, mais precisamente). Já imaginaram o avanço que hoje teríamos se os esforços dos developers do Gnome, GTK e respectivas aplicações, estivessem concentrados no KDE e Qt? Não só o KDE e o Qt estariam mais avançados, como os utilizadores não seriam confrontados com as actuais inconsistências e reduzida interoperabilidade das aplicações feitas para Gnome e para KDE, colocando o Linux em muito melhores condições para constituir uma alternativa ao Windows no desktop. É uma pena mas tal como estão as coisas, porém, nem daqui a 10 anos o Linux tornar-se-á uma alternativa ao Windows.
|
| | | | (NOTA: vou 'colar' aqui um boa parte dos textos para facilitar a compreensão de quão disparatada é a tua tão veemente argumentação contra o Projecto Gnome)
O Gnome surgiu da cabeça de alguns talibans da GNU que, ao invés de procurarem negociar com a Trolltech um modelo de licenciamento GPL (licença que a empresa viria a adoptar pouco depois), criaram um projecto à parte"(...)
Há quem argumente que o surgimento do Gnome foi positivo pois introduziu o factor competição Isso não é verdade.
Richard Stallman on KDE (Sat, 13 Sep 1997 10:45:34 -0400)
But you are right that this is a big job. That is why it is useful to have a GNU desktop project too. What free operating systems really need is to have *a* good desktop--which desktop is less important. If programmers get interested in forking on a free Qt, then free operating systems get a desktop; if the GNU desktop project is
successful at inspiring programmers, free operating systems also get a desktop.
Miguel de Icaza on KDE (10 Nov 1997 18:25:22 GMT)
Have I mentioned that some of the KDE code is very well done? I really hope we can use as much code as possible from KDE.
The GNOME project definetly would like to be interoperable with KDE, so in every aspect where we can stay compatible, we will try to be compatible with them.
Both KDE and GNOME are good for pushing Linux into the desktop. Right now KDE is the best tool we have to increase the Linux market share, and thus it is very important.
Miguel de Icaza : The Story of the GNOME Project
At this point the Kool Desktop Environment project (KDE) was showing a lot of promise: a team of programmers started an effort to bring Unix to the desktop using the C++ based GUI toolkit. I mailed my friend Erik Troan suggesting him to include that code into the Red Hat distribution and I mailed Richard Stallman to let him know that this interesting project existed. KDE was licensed under the terms of the GNU GPL. I got a reply back from both Erik and Richard pointing out that KDE dependency on Qt resulted in a piece of non-free software. Qt did not end users the right to modify, redistribute nor distribute modifed copies of the code and violated the terms of the GNU GPL.
Being a free software entusiast, I contacted Troll Tech, the authors of Qt to propose an alternate licensing scheme for Qt that would still allow them to build a company while empowering users but got no reply. The Troll Tech FAQ at the time also contained significant errors regarding the GPL and ignored dual-licensing schemes. After a time out period, we decided to do something about this problem. Also discouraging was the fact that the KDE developers were not interested in resolving those issues as pointed out in their FAQ document and their mailing list policies.
We evaluated writing a free Qt replacement, but reimplementing an API would most likely result in less efficient software and would have taken too long to implement. GNUstep, Wine and LessTif were other projects that had attempted to reimplement a proprietary API and just had a limited success after a long development history.
Trolltech offers a choice in licensing with the addition of GPL licensing for the upcoming release of Qt ( Oslo, Norway - September 04 2000)
The K Desktop Environment (KDE), one of the largest open source projects based on voluntary work from all over the world, will benefit greatly from the new licensing. In the past, KDE has received some criticism for choosing Qt as its basis. "While Qt was without a doubt the best technical choice, some members of the free software community didn't agree with Qt's licensing," explains Matthias Ettrich, founder of the KDE project and Trolltech employee. "Thanks to Trolltech's new licensing scheme, the upcoming KDE-2.0 will receive full acceptance throughout the community."
Em minha opnião, a aplicação das melhores vontades e esforços na construção e melhoria de software livre é sempre bem-vinda (mesmo que seja para 'reinventar a roda'... até porque as rodas não são todas iguais ;-)). Sou frontalmente contra as vias únicas e definitivas, seja onde for.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | Podes instalar um tema de gtk que usa o qt para desenhar as janaelas:
http://packages.debian.org/unstable/kde/gtk2-engines-gtk-qt
Nao e a solucao ideial, mas pelo menos fica mais bonito.
## I should be working... |
| | | | Também é o ideal, se quiseres ter os programas GTK constantemente a rebentar.
--
Carlos Rodrigues
|
| | | | A coisa não é assim tão má, eu uso e até agora só tive problemas com a janela de configuração do eclipse.
De facto não é a solução ideal, mas à falta de melhor...
|
| | | | | Estás-te a referir ao aspecto das widgets, nos diferentes sabores que referiste, ou às escolhas que os programadores usam quando constroem as suas interfaces? É que num aspecto funcional, o que chateia a sério é, para N aplicações diferentes, estar a encontrar as mesmas opções em locais distintos. De valor mesmo era isto mas generalizado ao universo do software livre e não livre que vai parar ao desktop.
Is this desire? |
| | | | Concordo com o que dizes, mas no windows passa-se o mesmo. Actualmente tens programas com o look normal, o look do XP, e os idiotas que teimam em inventar a roda e criar um look diferente em tudo o que existe fazem. Ver Roxio Easy CD Creator.
I live the way I type; fast, with a lot of mistakes. |
| | | | Nesse conjunto de idiotas também se encontra a Microsoft. O look de aplicações como o Windows Media Player, Microsoft Office 2003 e MSN Messenger nada tem a ver uns com os outros, nem com o próprio Windows XP. Ainda bem que não tenho de usar esses bichos.
|
| | | | | Ah pois é... tens o privilégio de usar os softwares livres que andam por aí que têm os Look&Feels completamente padronizados...
Is this desire? |
| | | | Ahh pois é! Não duvides...
Agora, graças à ximian, até o OpenOffice.org tem o mesmo look que as restantes aplicações GNOME (ou KDE). Muito melhor...
E como eu não uso aplicações KDE (apesar do K3B me fazer uma certa falta) tenho o desktop com um look completamente uniforme.
Se bem que não me faz diferença usar uma ou outra aplicação com um look um pouco fora de contexto. E isso por acaso até acontece com algumas aplicações que uso raramente.
"As you know, these are open forums, you're able to come and listen to what I have to say."
--George W. Bush |
| | | | O OpenOffice.org ira' adaptar-se a' framework que estiver a ser utilizada. Como no windows ficará a utilizar widgets do Windows (Native System Theme Integration (Native Widget Rendering)), mas nao me recordo de ver isso como contributo da Ximian. Estarias a falar dum trabalho que eles fizeram _exclusivamente_ para ximian? mudar icones e afins?
Quem usar KDE, tera' tambe'm um ambiente de trabalho uniforme e onde ja' esta' incluido o k3b!
Aproveito para deixar votos de bom ano novo.
Cheers.
^S^ |
| | | | Li não sei onde que foi um tipo da Novell que implementou isso. Suponho que ele pertença à Ximian, porque no outro dia instalei o openoffice-ximian numa box gentoo e reparei que já fica com o look do GNOME. :-)
Quem usar KDE, tera' tambe'm um ambiente de trabalho uniforme e onde ja' esta' incluido o k3b!
Claro, mas para teres esse ambiente uniforme tens que trocar o firefox pelo konqueror e o evolution pelo kmail. ;-)
Em relação ao K3B, sinto um pouco a falta porque estava habituado a ele, mas o nautilus-cd-burner faz tudo que é preciso, ou seja, grava imagens ISO e backups de ficheiros. Só não grava MP3, mas como o Tuaregue indicou mais abaixo, para isso existe o graveman, em GTK2! :-)
"As you know, these are open forums, you're able to come and listen to what I have to say."
--George W. Bush |
| | | | Porque raio terias de trocar o firefox pelo konqueror? Também trocas o firefox pelo epiphany em GNOME?
Depois de ter usado o Evolution durante algum tempo, e ter usado o Kontact, acabei a usar este último. Faz tudo o que quero, e ainda melhor que o anterior, e' imediata a ligacao ao Kolab tambem, ja' agora.
^S^ |
| | | | Porque o firefox usa a biblioteca GTK2, e fica melhor integrado em GNOME.
Ainda me faltou referir o GIMP e o Dia.
Eu gosto do KDE e usei-o durante muito tempo mas, na minha opinião, está demasiado bloated, e neste momento prefiro a simplicidade do GNOME.
E ainda por cima, apesar de o KDE ter aplicações excelentes (como o Kate, K3b, Kdevelop, Konqueror, etc) não há nenhuma que me seja realmente essencial.
E como não é possivel misturar pacificamente aplicações dos dois ambientes só uso GNOME.
"As you know, these are open forums, you're able to come and listen to what I have to say."
--George W. Bush |
| | | | Como eu digo sempre, o KDE poderia esmagar o GNOME se ao menos decidissem limpar aquela pocilga a que chamam interface. Será que ainda não perceberam que milhares de opções e interfaces com demasiada funcionalidade exposta são contra-producentes?
--
Carlos Rodrigues
|
| | | | "(...) o KDE poderia esmagar o GNOME (...)"
E qual é o interesse disso? quem é que ficava a ganhar? quem é que perdia?
Sempre as mesmas lenga-lengas acerca do KDE vs Gnome... Cada um usa o que quer... ou nenhum (como eu). Que felicidade o *nix ter vários DM (e uma vasta colecção de WM) impecáveis e que funcionam! O Windows só tem um e tem os problemas que sabemos (e os que ainda não sabemos) :-P
Uso o Slackware e preocupa-me que The Man pense em remover o Gnome:
! Dropline Gnome is about to become VERY important. !
Anyway, suffice to say the jury is still out. Since GNOME 1.4 I've felt
that GNOME is going in a direction that doesn't fit well with Slackware's
goals, and for at least as long I've considered removing it completely and
taking whatever flames I get for that decision. Right now, I think
removing it would be the best thing for Slackware as it's become a
maintainance nightmare (unlike nearly every other ./configure'ed source,
GNOME doesn't build into packages easily with DESTDIR).
Ele tem muita razão. Mas não incluir o Gnome numa distribuição Linux é quase o mesmo que dizer que 'aquilo não presta'. A ver vamos.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | You missed my point...
O que acontece hoje é que não temos um DE realmente de qualidade:
- O KDE tem uma excelente tecnologia por baixo (apesar de sofrerem gravemente do síndrome Not Invented Here e reinventarem a roda constantemente), é rápido q.b. mas a interface da maioria dos programas é desenhada pela técnica "amontoado de widgets", cujo único objectivo é conseguir ter o máximo de funcionalidade por cm^2. Faz-lhes muita falta umas Human Interface Guidelines a sério, como tem o GNOME, que permita chegar a software com funcionalidade mas elegante e usável em simultâneo.
- O GNOME tem uma interface bastante mais elegante e simples (não simplista, apesar de em alguns casos isto acontecer) mas tem uma base tecnológica mais pobre do que o KDE, mas com as suas vantagens (o uso de componentes discretos e ortogonais ao GNOME permite fazer aplicações "GNOME" que não dependem deste, mas apenas desta ou daquela biblioteca que se pode instalar em separado). É também um bocado mais lento e as funcionalidades que tem nem sempre funcionam como deve ser (o suporte SMB do Nautilus é de fugir e quebra versão sim, versão não).
Logo, eu não quero que exista um DE unificado, mas sim que ambos sejam rápidos, elegantes e robustos.
A escolha deveria basear-se na subjectividade do estilo de cada um dos ambientes, e não quais problemas e "irritâncias" estamos dispostos a aturar.
É por isto que eu ando a usar o XFCE (4.0.6): tem pouca funcionalidade mas eu gosto de usar a CLI e assim sempre evito as frustrações associadas a ambientes que funcionam mal e porcamente ou t~em tantas opções que fazer qualquer coisa simples se torna uma aventura. É que nem sempre estou no meu estado "geek", às vezes só quero que as coisas funcionem como deviam.
É uma pena que a mítica estabilidade e robustez e elegância do Linux no servidor seja completamente virada do avesso no desktop.
--
Carlos Rodrigues
|
| | | | Yep, I missed your point.
"É uma pena que a mítica estabilidade e robustez e elegância do Linux no servidor seja completamente virada do avesso no desktop."
Eu uso FVWM. Só tenho uma queixa: Não posso ter os cantos das janelas redondos :-(
De resto, só tenho a dizer bem. Não uso Gnome nem KDE. Nem tão pouco os instalo. Não me fazem falta.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | Talvez queiras ver este: Graveman é um front-end para várias aplicações de shell, porquê enventar a roda toda torta quando se pode fazer ter uma roda a funcionar. Isto deve responder ao teu desabafo sobre K3B.
------------------------------------------------------------
Todas as coisas mudam, e nós mudamos com elas. |
| | | | A única parte má é que o Graveman não suporta gravação de DVD's :( Aliás, não me lembro de ver uma aplicação para o gnome que o faça...
---
Este espaço pode ser seu... |
| | | | Podes sempre usar o growisofs na consola :D
Characteristic of life style... |
| | | | | Não só o layout devia ser uniformizado, mas tambem o open/save dialog, e outras caixas de dialogo que tais.
|
| | | | Isso nunca vai acontecer. As diferenças vêm de visões diferentes e nenhuma das partes vai ceder.
--
Carlos Rodrigues
|
| | | | Já agora esqueci-me (só a nível de curiosidade) de incluir o link do macosx para as guidelines de interface homem-máquina: Introduction to the Apple Human Interface Guidelines
"You have to know, not fear, that someday you are going to die. Until you know that and embrace that, you are useless."
Tyler Durden |
| | | | Isso é um bocado impossível, apesar de já existirem regras(ou linhas de orientação) na interacção homem-máquina de senso comum, existem as que são criadas por empresas(ou organizações) para um determinado produto ou para uma determinada plataforma.
Já agora, à pouco tempo andei a pesquisar umas coisas sobre linhas de orientação sobre interacção homem-máquina para web(ou páginas de internet) e deparei-me com pouca informação acerca do mesmo. Provavelmente porque envolve a criatividade no meio(para o design gráfico) e porque é uma plataforma relativamente recente.
Os toolkits que já experimentei se calhar de uma forma superficial foram GTK, QT e wxWindows, sendo o QT no meu entender o que tem a API mais "limpinha". Acho que o uso do C++ nos toolkits tem as suas vantagens e desvantagens. Eu pessoalmente gosto mais de plataformas/linguagens com memória gerida(caso do C# do .NET e java), para me concentrar em pontos mais importantes da minha aplicação. Pena é que não existe uma linguagem(para além do java) desse género que seja de facto multi-plataforma(leia-se diversos SO e que seja estável). O caso no mono só na versão 2.0 quando possuir os winforms.
Cumps,
"You have to know, not fear, that someday you are going to die. Until you know that and embrace that, you are useless."
Tyler Durden |
| | | | | Creio que tens de ler novamente o que escrevi...
"You have to know, not fear, that someday you are going to die. Until you know that and embrace that, you are useless."
Tyler Durden |
| | | | Isso é um bocado impossível, apesar de já existirem regras(ou linhas de orientação) na interacção homem-máquina de senso comum, existem as que são criadas por empresas(ou organizações) para um determinado produto ou para uma determinada plataforma.
isso estuda-se e o termo correcto em portugues europeu e' interfaces homem-maquina
Já agora, à pouco tempo andei a pesquisar umas coisas sobre linhas de orientação sobre interacção homem-máquina para web(ou páginas de internet) e deparei-me com pouca informação acerca do mesmo. Provavelmente porque envolve a criatividade no meio(para o design gráfico) e porque é uma plataforma relativamente recente.
usa essa ferramenta de trabalho que da pelo nome de google, pesquisa por "usability internet", suas variantes ou o termo da frase anterior.
btw o w3c e' um bom ponto de partida
se virem o pai natal digam-lhe que a mae natal dormiu ca em casa.
2.6.10 #1 Sat Dec 25 13:30:34 WET 2004 |
| | | | É o que tu quiseres, no meu curso portugues de Portugal (não sei se da europa - is a joke) a disciplina chama-se Interacção Homem-Máquina. Já agora fica o link (http://www3.dei.isep.ipp.pt/compsistd.html).
Hasta,
"You have to know, not fear, that someday you are going to die. Until you know that and embrace that, you are useless."
Tyler Durden |
| | | | "Já agora, à pouco tempo andei a pesquisar umas coisas sobre linhas de orientação sobre interacção homem-máquina para web(ou páginas de internet) e deparei-me com pouca informação acerca do mesmo."
Andaste a pesquisar no sítio errado...
www.usabilidade.org
www.usabilidade.com
Google 10.400 resultados para Internet usability
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | err... podes usar, hoje, o gtk#. olhar para o winforms dá-me um bocado de vómitos... layout automático é para se me apetecer, não percebi muito bem como fazer coisas básicas. vou ver se leio um livro sobre o c#.
claro, o problema do gtk é a falta de documentação (so they say)...
-----
You can't take the sky from me... |
| | | | Pois o que eu acho é que devia haver uma uniformização entre o GTK, o QT, o Tcl/tk, o motif, o aqua e o Win32...
Que cavalo de batalha mais... idiota.
São toolkits diferentes, usados para ambientes diferentes.
Queres tudo em GTK, usa um ambiente estritamente GTK! Se as aplicações que usas , são feitas com o QT ou outro qualquer, "don't bitch"! Faz o port! Mais ainda, chega-te à frente e faz com que partam o projecto em 2:um engine que seja comum a qualquer parte gráfica.
Ou então cria themes que sejam semelhantes em todos os ambientes...
---
Este espaço pode ser seu... |
| | | | E que tal o http://www.wxwidgets.org :-)
Characteristic of life style... |
| | | | | Já tive a oportunidade de programar com a QT e achei que era uma óptima API. Porém, fico um pouco desiludido, porque esperava que a QT se formasse como uma alternativa ao M$ Avalon, de forma a termos para Linux e Cª uma API mais moderna e virada para o futuro. boas festas
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | | | "M$ Avalon, de forma a termos para Linux e Cª uma API mais moderna e virada para o futuro."
Por que raio é que o QT (que existe e tem provas dadas) deveria ser uma alternativa ao avalon (que não existe nem se sabe ao certo quando virá a existir, apesar do lançamento estar previsto para 2006...)?
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | A Microsoft pratica muito "fogo de cobertura". Anuncia tecnologias com anos de antecedência e, muitas vezes, não as lança nos prazos esperados nem com as features anunciadas. Com isto vai entretendo papalvos e evitando que eles optem por tecnologias concorrentes.
É uma estratégia que a Microsoft pratica há anos. E, pelos vistos, com algum sucesso...
|
| | | | Porque a galinha da vizinha põe sempre mais ovos que a nossa... começo a pensar que com tanto "flash&bang" das tecnologias MS o pessoal se esquece do quão boas são as tecnologias que existem hoje para Linux.
O QT é óptimo! O GTK é óptimo! Não sabem C ou C++? No problemo! Aqui tá o binding para perl/php/python/bash/whatever!
Do QT não sei, mas o GTK, através do Glade, leva à abstracção quase total daquilo que é o UI com o que é o código... MVC at it's best para quem gosta do chavão.
Ainda há o XUL! Peguem no browser e façam aplicações web realmente dinâmicas para os utilizadores... Porra percam algum tempo a olhar para o que já existe e pensem como é que se podem integrar as coisas se houver necessidade disso!
Desculpa bebâdo :) O desabafo nada tem a ver com a tua resposta/pergunta... tenho de cortar no analgésico que me está a dar cabo do humor.
---
Este espaço pode ser seu... |
| | | | | ... e não perder o barco. O Avalon/XAML são projectos bastante interessantes que trazem ideias inovadoras que prometem revolucionar os gui's e respectivas api's. E se neste momento termos boas opções como: QT, GTK, etc, mas isso não quer dizer que no futuro isso seja assim !! Criar gui's ainda é uma tarefa bastante xata , mesmo utilizando Qt designers, Glades, o processo continua moroso e muitas vx complexo. Tendo em conta, que actualmente o que está a dar são as Web app e o html/dhtml/js/etc já não chegam para as encomendas, prevêm-se grandes desenvolvimentos nestes campos. Falando em GTK, dá uma vista de olhos no blog do Miguel de Icaza
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | Então, olhando para o futuro, olha para o XUL! É aquilo que queres e é multiplataforma!
Pareces um tipo com quem eu trabalhei, que precisava de uma aplicação para um quiosk web-based. O homem queria ter de fazer uma aplicação VB com o componente do IE para restringir N coisas e dar N opções... falei-lhe no XUL e nem pensou no assunto. Lá devem ter continuado com o VB+IE.
WTF, é assim que ficam agarrados pelos tomates.
Honestamente, já me ando a c*gar um bocado para que o Miguel de Icaza diz, só tenho a agradecer-lhe duas coisas: o Gnome e o Midnight Commander... certamente que iniciou/participou em milhentos outros projectos, mas não me agrada em nada a confusão que ele anda a gerar com o mono.
---
Este espaço pode ser seu... |
| | | | Honestamente, já me ando a c*gar um bocado para que o Miguel de Icaza diz, só tenho a agradecer-lhe duas coisas: o Gnome e o Midnight Commander... certamente que iniciou/participou em milhentos outros projectos, mas não me agrada em nada a confusão que ele anda a gerar com o mono.
O Miguel de Icaza é basicamente um cheira-rabos da Microsoft. Muito do que ele faz é correr atrás de uma tecnologia qualquer inventada lá em Redmond, e com menos sucesso do que aparenta. Dois exemplos:
- Bonobo - a tentativa de criar uma espécie de COM/OLE baseada em CORBA. Desde o início que o facto de ser baseado em CORBA (um sistema de objectos desenhado por comité e, como tal, monstruosamente complexo) não lhe augurava nada de bom. Resultado: fracasso. Pesquisem um bocado e vão chegar à conclusão que quase nada o usa, apenas o Nautilus e o Evolution o estão a usar de alguma forma relevante. Pesquisem um bocado mais e vão ver movimentos claros para tornar o Bonobo num componente de terceira-apanha no GNOME (um dos esforços actuais é a redução das dependências e eliminação da gordura, e o Bonobo está mesmo lá no meio).
De valor são as KParts. Neste aspecto o KDE ganha em grande (só é pena que a qualidade técnica das suas APIs só seja igualada pelo descontrolo e anti-usabilidade da interface). - Mono - O Mono é puro hype; fala-se muito dele mas vê-se pouco sumo. Mas é natural, actualmente é apenas uma forma de fingir que o .NET não é uma tecnologia de lock-in. Mas eu não vou seguir por este caminho, já falei tanto disto aqui que já estou cansado...
Ele fazia melhor se implementasse as suas próprias ideias, em vez de andar a tentar copiar as dos outros. Claramente é um tipo inteligente, mas de vistas curtas.
--
Carlos Rodrigues
|
| | | | O Avalon/XAML são projectos bastante interessantes que trazem ideias inovadoras que prometem revolucionar os gui's e respectivas api's.
O Avalon e o XAML não trazem nada de inovador. O XAML copia o XUL e o Laszlo, que já existem há vários anos e o Avalon copia o que já existe no Qt, GTK, Swing, SWT e todo e qualquer toolkit moderno já tem há anos largos. Só quem nunca viu nada para além do Win32 pode dizer que são inovações.
--
Carlos Rodrigues
|
| | | | Bem, no outro dia estive a experimentar uma "aplicação", se é assim que se pode chamar, baseada nesse lazlo, o dashboard e fiquei impressionadíssimo!
Só tenho uma dúvida, aquilo usa Flash ou é impressão minha? Não li muito sobre a tecnologia, daí a pergunta.
---
Este espaço pode ser seu... |
| | | | Aquilo usa Flash sim.
O OpenLaszlo, de uma forma simples, é um Application Server em Java que compila aplicações programadas numa espécie de XUL para Flash. Não fica tão rápido nem tão integrado quanto o Firefox/Mozila + XUL, mas pelo menos funciona em todo o lado onde haja Flash (que na prática é em todo o lado mesmo).
--
Carlos Rodrigues
|
| | | | | A ultima vez que programei em QT,GTK ou Swing não vi interfaces descritas em XML em lado nenhum !?? Devo andar muito distraido !! Na QT os forms e os respectivos componentes são descritos em XML mas tem que ser feito um pré-processamento para gerar código a partir dessa decrição !! (Em relação ao Swing aquilo é um crancrozinho :// ) Pelo que entendi a estratégia da M$ é usar o XAML para windows applications para tornar o desenvolvimento destas tão facil como as web app !! O que é algo verdadeiramente interessante. Cumps
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | | Em primeiro lugar, acho que tudo isto parte de ainda não teres percebido o que é o XUL, porque o XAML é a mesma coisa, mas ligeiramente diferente e com a marca da Microsoft. O XUL é um toolkit, como o XAML é um toolkit.
O Firefox corre XUL, mas ele próprio é feito em XUL. Não precisas de correr aplicações XUL dentro do Firefox ou do Mozilla, podes corrê-las independentemente. Isto é igual ao XAML: podes fazer aplicações para correrem dentro do IE ou fora dele.
Repara, um IDE feito em XUL, e que não precisa do Firefox/Mozilla instalado: Komodo.
Por baixo do Firefox/Mozilla está um runtime completo, assim como o Java/Python/etc., e é esse runtime que interpreta o XUL. O que acontece é que actualmente não existe um pacote com o runtime em separado, as aplicações como o Komodo trazem-no embebido, portanto a melhor forma de o ter é com a instalação do Firefox. Mas isto vai ser alterado em breve, o XULRunner vai tornar-se um pacote stand-alone, com mais umas funcionalidades interessantes acrescidas (o Ben Goodger anda com a ideia de criar um mecanismo de instalação para aplicações XUL semelhante ao do MacOS X, em que se arrasta um zip para uma pasta e aquilo é automaticamente instalado).
Quanto ao XML nos toolkits tradicionais, é algo completamente diferente do que estamos a falar. E algo que o GTK tem há vários anos com a libglade e o Qt também.
No caso do QT, existe um compilador que gera código a partir dos XML gerados pelo QT Designer (como tu disseste e bem), mas também podem carregar-se dinâmicamente, em run-time. Não me lembro exactamente como se faz, mas existe, até porque é exactamente assim que funcionam as KParts: a aplicação tem a interface definida em XML, a KPart também, e ambos são "merged" no acto do carregamento da KPart.
--
Carlos Rodrigues
|
| | | | | e aquando eu vejo .. quote "Quanto ao XML nos toolkits tradicionais, é algo completamente diferente do que estamos a falar." A ultima vez que pensei/olhei sobre/para isso os tipos da M$ queriam mudar esse completamente diferente para o completamente igual. That's my point !!! não é muito dificil de entender pois não !!!
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | Ok, eles querem uniformizar os formatos usados para ambas as coisas. Mas achas que isso realmente é relevante ou inovador? No fundo os tipos não têm actualmente nem uma coisa nem outra e querem usar o mesmo formato para as duas.
Se quiseres elucidar-me com situações reais em que usar o mesmo ficheiro XAML para as duas coisas se pode revelar interessante, está à vontade.
--
Carlos Rodrigues
|
| | | | eu olho para aquilo, e n entendo. para que interessa fazer as interfaces em XML?
-----
You can't take the sky from me... |
| | | | Em relação ao Swing aquilo é um crancrozinho ://
Não sei qual é o teu problema com o Swing. Pode não ser o toolkit mais rápido à face da Terra, mas é completamente portável, e com uma API moderna.
Além do mais, pode ter exactamente o mesmo look em qualquer plataforma, o que é muito importante.
E também pode carregar interfaces via-XML. Há uma data de classes por aí que fazem isto, e aplicações a usarem-nas, como a applet de declaração do IRS.
Apesar de existir o SWT, que tem as suas vantagens, isso não significa que o Swing é mau.
--
Carlos Rodrigues
|
| | | | | Apenas por curiosidade um dos developers desse applet trabalha comigo :). Nos projectos que fiz em Swing fiquei sempre com a opinião que aquilo devia ser melhorado. Dou apenas 3 exemplos: as opções de look&feel (o metal salta á vista), os escasso numero de componentes e a api especialmente ao nivel do controlo de enventos. EOD - End of discussion
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | Bom, como já estão a mexer na minha dama ;-)
O nr de componentes é bastante bom, prefiro uma textbox explícita a ter uma textbox, uma textbox que só aceita numeros, uma textbox que só aceita cartões de crédito, uma textbox que pisca vermelho.
Não sei se é a isto que te referes, mas os controlos do SWING são os mesmos de qualquer outra aplicação: textbox, radios, combos, listas, tables, trees, labels, rich-text editor.
Há algum controlo em especial que se queira e que não esteja aqui?
As opções de look&feel são bastante boas: tens o Windows L&F, o Metal (default), Motif e o Mac (apesar de nunca ter visto como é que é este).
Desde o JRE 1.4.2 que também há suporte para o GTK que é o que uso "as I write this".
Sei que agora existem mais dois mas também não lhes pus a vista em cima.
Para terminar, o tratamento de eventos não tem grande mal: queres qualquer coisa, acrescenta um listener que és notificado. É suposto fazer mais alguma coisa?
---
Este espaço pode ser seu... |
| | | | Devias pesquisar um pouco mais antes de tirares conclusões.
Em primeiro lugar, o Avalon é uma forma da parte gráfica do Win32 alcançar o que já se faz noutros toolkits em termos de containers e layout de widgets. Neste aspecto o Qt não precisa do Avalon para nada (nem o GTK, e nem qualquer outro toolkit moderno).
Por outro lado, há a parte mais baixo-nível (que não sei se realmente faz parte do Avalon) que também não é mais que uma forma de alcançar o que já se faz no MacOS X com o Quartz/Quartz Extreme. E como o Longhorn ainda está um pouco distante, pela altura do seu lançamento já deveremos ter um Cairo/Glitz estável. Considerando que o pessoal do GTK e da Trolltech já manifestaram intenções de suportar o Cairo como API gráfica de baixo-nível (em substituição da Xlib), não estamos nada mal.
Quanto ao resto, também temos o XUL (exemplo), que está a aumentar a sua base instalada com o aumento da popularidade do Firefox.
Portanto, o Linux não está com problemas em termos de APIs ou capacidades tecnológicas. O problema real é a malta que não sabe criar aplicações GUI com o mesmo nível de estabilidade e qualidade que as aplicações não-GUI/servidor.
--
Carlos Rodrigues
|
| | | | e segundo consta, a documentação...
-----
You can't take the sky from me... |
| | | | | não é muita, faltam exemplos, não é exaustiva.
não que tenha pessoalmente pesquisado nos últimos tempos, mas ainda no outro dia vi umas quantas pessoas a queixarem-se quer do XUL quer do GTK...
-----
You can't take the sky from me... |
| | | | Neste ponto tenho de discordar. A documentação de APIs é, em geral, bastante boa. Não está concentrada, é verdade, mas pesquisas simples no Google dão bastantes resultados (em qualidade, não em quantidade).
Os livros que existem sobre muitas delas são também de boa qualidade, ao contrário de alguns para outras plataformas que não valem o papel em que estão impressos. Alguns estão disponíveis onlin, inclusivamente.
Quem se queixa da falta de documentação de APIs em Linux, sofre normalmente de uma coisa chamada "preguiça".
Mas há ovelhas negras, o OpenSSL é um caso gritante de falta de documentação (e não, ".h" não são documentação).
O que há é muita gente habituada à documentação MSDN, que parece farta e rica, mas que eu acho normalmente pouco concisa e circular. Das coisas que fiz em Windows, usando APIs da Microsoft, 90% das vezes andei ás voltas com documentação que documentava o óbvio e apontava para mais detalhes em mais documentação óbvia, que depois acabava por voltar ao início (isto no Win32).
Mas pronto, há quem critique a documentação do Java, que eu sempre achei excelente e útil.
--
Carlos Rodrigues
|
| | | | o que leio a +5 no slashdot é q, especificamente, a documentação do GTK e do XUL n é tão boa como devia ser. eu vou procurar um bocado, até porque vou querer dar uma vista de olhos a sério. diz-se q n é mto exaustiva ou fácil, nomeadamente o XUL. há o tal livro da O'reilly na net, desactualizadito...
MSDN sucks, really! pesquisar alguma coisa foi um bocado um martírio, cheio de documentação point & click. tipo, parece q n acreditam q alguém n venere a bosta (IMHO) do Visual Studio e n queira fazer tudo na One True Microsoft Way (TM).
-----
You can't take the sky from me... |
| | | | ok, o último tópico no slashdot sobre XUL trouxe-me muitos links e documentação, aconselha-se. muitos livros em edição online grátis, é aproveitar.
n deixa de ser um pouco confuso, no entanto.
houve uns posts q me deixaram parvo... um gajo q estava a implementar uma parte do XUL (?) em js porque a versão do Gecko é instável e lenta, e os exemplos insistem no XML e RDF mesmo quando n traz vantagem nenhuma.
oh well... se ficar melhor a gente usa, so, who cares? :)
-----
You can't take the sky from me... |
| | | | Posso dizer que as minhas opções para desenvolvimeto em Linux são Tcl/Tk e QT.
Argumento que o multiplatforma é um argumento de peso, mas se há linguagem que eu acho intragável é Java. Tem uma sintaxe horrível, aquele modelo de objectos dá-me vómitos e a sua lentidão é melhor nem falar .... por isso QT é que é.
Ao nível do scripting Perl é uma linguagem desenvolvida por um linguista, logo se vê a confusão do código que é possível escrever naquilo (ao haver muitas maneiras de fazer a mesma coisa) e o seu principal propósito é manipulação de texto Tcl/Tk é uma linguagem generalista, tem API para a programar em C, tem uma extensibilidade (tanto em C como em Tcl)praticamente infinita (existem extensões para o paradigma orientado a objectos), o código é limpinho (sintaxe consistente), está mais bem preparada para o Unicode que o Perl, permite criar subinterpretadores, o TkPerl não implementa todas as funcionalidades do verdadeiro Tk, seguro em aplicação multithread, embutível am muitos contextos.
Sérgio |
| |
|
