Fiz questão de ser o primeiro a desflorar o My Little Place com o novo Browser do Google, o Chrome.

"92.250.3.218 - - [02/Sep/2008:20:16:59 +0100] "GET /gngs HTTP/1.1" 301 192 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13"

Até agora tenho gostado. Interface simples e intuitivo que para uma versão Beta parece bastante completo, incluído dicionário e com que "search" que me enche as medidas.
Tendo em conta que esta aplicação foi desenvolvida de raíz privilegiando as componentes da segurança e da performance tal como a usabilidade que a Web requer actualmente, faz-me ponderar se este não será o meu browser pré-definido no Windows. Para outros SO's teremos de esperar.

Update: Não perceber o motivo que leva o Google a lançar um browser próprio é não perceber o negócio do mesmo. Google precisa de flexibilidade e controlo sobre a aplicação que até agora permite o acesso às Web Apps.
Não perceber o porquê de um browser de raíz ao invés de um fork do FF quando o Google explicou o funcionamento interno do mesmo, é não perceber de arquitectura de Software.

É bastante positivo o motor do webkit ser cada vez mais uma alternativa de qualidade ao gecko. É também interessante como o KHTML acabou por ser o pai biológico deste motor, que suporta tanto o Safari como o Chrome. Por outro lado é pena que este facto seja muitas vezes esquecido e pouco referido no geral, porque nunca é demais reconhecer o mérito a quem o merece e, sobretudo, quando se trata de um projecto open source.

De todas as maneiras desejo boa sorte ao "Cromo", e que não esteja tanto tempo em beta [1] como alguns produtos da Google ;)

[1] http://computerworld.com/action/article....

Ài, o ppl do KDE está um pouco sentido ;)
Repara que na string de identificação do browser está lá o "KHTML". Na Wikipedia também é bem explicito a origem do Webkit.

O problema do KDE foi o tempo que levou a fazer o porte do konqueror para Windows, uma aplicação Desktop tem obrigatoriamente de correr nesta plataforma para ter sucesso. Repara que apesar do Chrome ser todo opensource, o Google preferiu lançá-lo primeiro no SO da Microsoft em deterioramento dos SO Abertos.

O problema do KDE foi o tempo que levou a fazer o porte do konqueror para Windows, uma aplicação Desktop tem obrigatoriamente de correr nesta plataforma para ter sucesso

Vou mais longe que tu e diria que hoje, para uma aplicação Desktop ter sucesso, tem obrigatoriamente que ser multi-plataforma, o que não parece ser o caso:

http://www.monroe.nu/archives/138-Not-Ho...

A resposta está nesse mesmo link:

"Internally in google, I have read a blog post clearly mentioning that cross platform is not their priority. They aren't going to reduce any features or anything like that just so that it is available on all platforms"

Usar UI toolkits diferentes e ter o melhor dos vários mundos, não parece ser má estratégia.

Usar toolkits diferentes parece-me um pesadelo, é como se ter que manter N aplicações/módulos diferentes, para as N plataformas suportadas. É como multiplicar a complexidade (bugs, novas funcionalidades, comportamentos distintos, desenvolvimento, etc) de uma aplicação pelo número de diferentes toolkits utilizados. É precisamente aquilo que as "novas" ferramentas de hoje tentam evitar: "develop once, run everywhere". De qualquer maneira, não encontro nenhuma justificação técnica plausível para esta abordagem...

Já agora alguem pode comentar a questão da EULA referida neste post:

http://blog.binaryhelix.net/2008/09/goog...

"Well, they wrote an abstract library called ChromeViews [5] which is virtually capable of (by supplying the required backends) to display the UI on other platforms"

"View system is not especially unportable, since most rendering is done using the cross-platform Skia library"

Eles têm certamente uma equipa dividida por responsabilidades, pelo que para ti é um pesadelo para eles é uma questão de delegação.

Yep, a EULA é muito "spooky", algo que terá de mudar muito em breve :)

Como seria de esperar, existe um layer que abstrai os diferentes toolkits, mas isso não muda nada do que eu disse, isto é, continuam a ter que gerir a complexidade de utilizar N componentes diferentes de software. É claro que uma companhia com a dimensão da Google pode delegar e ter mil equipas diferentes, mas isso não faz com que tenham menos custos de tempo, dinheiro e infraestrutura.
É possível que estes custos não tenham grande relevância e que prefiram ter os engenheiros motivados a brincar cada um com o seu toolkit favorito ;)

Agora despe a pele de programador e pensa como gestor de projecto.
Tens um projecto que pretende dar à empresa a independência necessária para que possas desenvolver um produto sem estares preso ao ritmo e sabores de uma só instituição, leia-se Mozilla Foundation.
Se usasses um só toolkit de certa forma o teu projecto estaria também dependente do ritmo, sabores, licença de uma só instituição, se tens orçamento e know-how crias um layer acima que satisfaça o requisito da independência.

Compreendo o que dizes e acho que realmente faz todo o sentido naquilo que é o core deles, ou seja, o browser. Agora, em tudo o resto, vão estar sempre dependentes de outros projectos, leia-se WebKit, Python, Subversion, Perl, libxslt, etc, etc. Ainda para mais, uma das vantagens das dependências/bibliotecas serem open source é a de que é sempre possível pegar no código e fazer um fork, caso haja necessidade disso (o que é muito raro).

Esqueceste-te de dizer que vão estar dependentes dos fabricantes de hardware para poderem desenvolver a aplicação nas suas workstations.

O layer não os deixa independentes, continuam a necessitar desses UI toolkits, podem é mudar entre esses ou outros no futuro mais facilmente.

BTW, a EULA já foi mudada.

O que queria dizer é que ficavam mais bem servidos com um layer para o motor de rendering do que com um layer para o UI toolkit, por exemplo; e que é impossível ter layers para todas as suas dependências.

Pois, começou tudo aí aos gritos :)