(cc) por Luc Byhet

Ayer les comentamos sobre los planes de Nokia para el futuro de Maemo, uno de ellos es su alejamiento del toolkit Gtk+ para ser reemplazado por Qt en la plataforma base.

Se han publicado un par de videos en donde ya se puede ver cómo funciona Qt con Maemo en el Nokia N900.  En uno, que parece ser oficial de Nokia, se puede ver entre otras cosas el uso de aceleración gráfica con OpenGL ES, Widgets vectoriales a través de Scalable Vector Graphics (SVG), animaciones y el clásico mapa.

El otro video es de uno de los miembros de la comunidad de KDE, quien fue uno de los 300 malditos afortunados que recibieron de regalo un Nokia N900 en el reciente encuentro Maemo Summit realizado en Amsterdam.

En el video muestra el framework Plasma de KDE corriendo sobre el N900. Según el autor, sólo fue necesario cambiar unas 20 líneas de código para tener esta tecnología corriendo sobre Maemo.  El único problema fue la resolución, porque si bien Plasma está preparado para correr en dispositivos de pantallas pequeñas como netbooks, el N900 es más pequeño aún.

Por lo que se puede ver en ambos videos, el esfuerzo de cambiar un componente tan importante como el toolkit vale la pena, si éste permite crear el nivel de interfaces gráficas que se están viendo en Maemo.

Click here to view the embedded video.

Click here to view the embedded video.

Link: Free N900 (KDE.news)

(cc) by Tim Samoff

Mientras aún nos recuperamos de la impresión generada por el N900 de Nokia, ya se está mostrando el camino que seguirá la plataforma Maemo, que le da vida a este equipo.  En Ars Technica han publicado un contundente artículo de qué es lo que vendrá en Maemo 6.

La semana pasada se realizó el Maemo Summit en Amsterdam, en donde Nokia reveló sus planes para la próxima versión de su plataforma móvil basada en Linux. Bajo el nombre clave Harmattan, Maemo 6 promete mejorar radicalmente la interfaz de usuario y agregar algunas características que quedaron pendientes, como es el soporte de multitouch.

Si bien aún no se sabe cómo será el look&feel de Maemo 6, algunos desarrolladores presentes en el encuentro indicaron que tendrá una interfaz de usuario que se podrá desplazar en todas direcciones e incluirá varios widgets interactivos. Se mejorará la suavidad en que se cambia la interfaz de usuario cuando éste pone el dispositivo en posición vertical u horizontal y además de agregar el soporte de multitouch, se incluirá un sistema gestual más sofisticado.

Para aplicar estos cambios, Nokia dejará de usar GTK+ como tookit de interfaz de usuario, migrando completamente a Qt.  Éste es un camino que no es de sorprender debido a las mejoras realizadas en Qt después de que Nokia adquirió a Trolltech.  De todas formas, aún se podrán usar aplicaciones basadas en GTK+, pero las aplicaciones incluidas con la plataforma y otros componentes propios de ella usarán Qt.

Las aplicaciones en Maemo 6 no vivirán en ventanas, sino que funcionarán dentro de un QGraphicsView de Qt.  Esto quiere decir que los componentes gráficos como botones, listas, cajas de texto, etc, estarán incrustados en un área completamente gráfica.  Esto permite por ejemplo poder rotar la interfaz como un todo y no como componentes individuales, mejorando el uso de la aceleración gráfica por hardware y conviviendo nativamente con efectos visuales sobre OpenGL.

Otra ventaja que Nokia ve en Qt es su portabilidad, ya que podría simplificar el proceso de desarrollo de aplicaciones para Maemo. Con Qt, el core de Maemo podría correr nativamente en sistemas de escritorio por lo que no necesitarían algo adicional para probar en el ambiente de desarrollo antes de llevar el producto al hardware real.

Nokia también piensa agregar la posibilidad de distribuir contenido comercial en la plataforma.  Este aspecto es controversial ya que requeriría implementar políticas de DRM en todos los niveles de la plataforma, lo que complicaría el desarrollo de ROM’s modificadas por terceros.  Nokia se anticipa a este problema y cree que puede ser resuelto con un framework de seguridad en donde se concentre esta funcionalidad.

El uso de DRM y el acceso a contenido protegido estará disponible sólo para las ROMs originales.  Los usuarios aún podrán meter mano a sus dispositivos e instalar sus propias ROMs con la única limitación es que no podrán reproducir contenido protegido en ese caso, lo que es bastante aceptable.  Si bien aún no se ha especificado cómo funcionará esta dualidad, Nokia dice que los usuarios podrán intercambiar entre usar su propia ROM y usar otro modo con DRM.

Nokia ya lanzó un preview del SDK en Maemo Summit, y se espera que la versión Alpha este disponible a principios del 2010, la versión beta vendría en el segundo cuatrimestre.  En teoría el N900 también será compatible con Maemo 6, pero por los tiempos definidos en el plan de Maemo 6 algunos probablemente preferirán esperar.

Link: Next-gen Nokia Linux devices will get multitouch and Qt UI (Ars Technica)

(cc) por Luc Byhet

Una de las interrogantes que se crearon cuando Nokia adquirió a Trolltech, la empresa desarrolladora de Qt, fue el futuro de la plataforma Maemo, cuyos pilares están formados por componentes de GNOME y en especial, su toolkit gráfico Gtk+, competidor directo de Qt.

En el reciente Gran Canaria Desktop Summit, Nokia anunció que Maemo se migrará a Qt, dejando atrás a Gtk+.  En un principio esto podría parecer un duro golpe al proyecto GNOME, pero no lo es tanto ya que el resto de las tecnologías subyacentes seguirán siendo de GNOME: glib, dbus, gvfs, gstreamer, gconf, etc.

La noticia fue anunciada en el keynote de Quim Guil, y en su blog agrega:

Maemo Harmattan basará su framework de aplicaciones en Qt manteniendo su middleware basado en tecnologías de GNOME. El objetivo es ofrecer un sistema basado en Linux para móviles que sea abierto y eficiente, con QT como una API multiplataforma que también está siendo usada en Symbian y está disponible en otros sistemas operativos móviles y tradicionales.

El desarrollador Vincent Untz da su punto de vista desde la trinchera de GNOME:

Aunque migrar a Qt es un movimiento lógico de Nokia, es bueno ver que la compañía sigue firmemente comprometida con GNOME en el área móvil. Actualmente es alucinante ver que lo que hemos construido es atractivo para un gran participante de la industria como Nokia (y, bueno, otros también).

Los primeros dispositivos basados en la nueva encarnación de Maemo con Qt se esperan para más adelante, ya que el equipo esperado para este año (Nokia N900) estará basado en Gtk+.

Links:
- Maemo to switch to Qt (OS News)
- Maemo Harmattan keynote at GCDS (blog de Quim Guil)

Este release marca el resultado de más de 3 años de trabajo para portar KOffice a Qt4 y KDE4 y en cierta medida, reconstruir las aplicaciones que componen a KOffice.

En los últimos años, el equipo de KOffice ha reestructurado el framework en una base de código ágil y flexible.  La intención era incrementar la integración entre los componentes de KOffice y reducir la funcionalidad duplicada de tal forma de facilitar la mantención y el desarrollo de nuevas características.  Además, se han implementado nuevas formas de interactuar con el usuario para apoyar las nuevas características.

Según el equipo de KOffice, este release es el primer preview público de lo que se ha logrado y está destinado principalmente a desarrolladores o cualquiera que quiera probar esta nueva generación.  No está orientada al usuario final y recomiendan a las distribuciones no incluirl a KOffice como la suite de oficina por omisión por el momento.  Se espera que aun aparezcan bugs e incompatibilidades a medida que más personas vayan probando KOffice.

También hay que hacer notar que KOffice 2.0 no tiene todas las características que estaban en KOffice 1.6.  Éstas se integrarán en las versiones 2.1 y 2.2.  Además, no todas las aplicaciones que estaban en KOffice 1.6 están en KOffice 2.0 y también se integrarán en versiones posteriores.

Componentes

Estas son las aplicaciones que se encuentran suficientemente maduras para formar parte de KOffice 2.0:

• KWord – Procesador de texto
• KSpread – Planilla de cálculo
• KPresenter – Gestor de presentaciones
• KPlato – Administración de proyectos
• Karbon – Editor de gráficos vectoriales
• Krita – Editor de imágenes.

La aplicación que antes se conocía como KChart ahora es un plugin de formas que se puede utilizar en cualquier aplicación de KOffice.

La aplicación de base de datos Kexi y el editor de formulas vendrán en la versión 2.1, mientras que no se sabe cuando será incluido el editor de diagramas Kivio, ya que no hay un mantenedor oficial que se esté haciendo cargo.

Destacados de KOffice

KOffice 2 es una suite mucho más flexible que su generación anterior.  La integración entre componentes es mucho mas fuerte por medio del concepto de Flake Shapes.  Un Flake Shape puede ser tan simple como un cuadrado o un círculo o tan complejo como un diagrama o una partitura.  A ojos del usuario normal, se puede ver como un modelo de integración similar al que se ocupa en Windows a través de COM (Component Object Model).

Con Flake, las aplicaciones de KOffice pueden manejar cualquier forma.  Por ejemplo, Krita puede incrustar gráficos vectoriales o Karbon puede incrustar diagramas.  Esta flexibilidad no solo le da a KOffice una fuerte integración, sino que también permite que nuevas aplicaciones se creen fácilmente a partir de los componentes ya desarrollados.

En el lado de la interfaz de usuario, todas las aplicaciones de KOffice tienen un diseño que se ajusta mejor a las pantallas anchas que se usan hoy en día.  La interfaz consiste en un área de trabajo más una barra lateral en donde se alojan las herramientas.  Cualquier herramienta puede ser separada para aparecer en su propia ventana y posteriormente se puede volver a incrustar en el panel lateral.

KOffice 2 no sólo para Linux

La suite completa está disponible para Linux (KDE o GNOME), Windows y Macintosh.  Se espera que la versión para Solaris y otros Unix’es estén disponibles en poco tiempo.

Ya que KOffice está construido sobre las bibliotecas de Qt y KDE, todas las aplicaciones se integran bien con la plataforma en donde se ejecutan y adoptan el look and feel nativo.

Soporte nativo para OpenDocument

La adopción del formato standard de documentos OpenDocument Format (ODF) cada vez crece y crece con más fuerza, y KOffice lo usa como su formato nativo.

Esto garantizará interoperabilidad con muchas otras herramientas de oficina como OpenOffice.org y Microsoft Office (cuando lo implementen bien .  El equipo de KOffice tiene representantes en el comité que define ODF y ha sido un activo participante en el proceso de darle forma a ODF desde sus inicios.

Los binarios para Ubuntu, Gentoo y OpenSUSE ya se encuentran disponibles en el sitio de KOffice.  Se espera que los binarios para el resto de las plataformas estén disponibles dentro de poco, partiendo por las versiones de Windows y Macintosh.

Link : KOffice 2.0.0 released (koffice.org)

QT Creator IDE

Tal como les contábamos hace poco, desde que Nokia compró a Trolltech se han ido eliminando las trabas para que la tecnología Qt se transforme en un ciudadano de primer nivel en el ámbito del software libre.  Hoy se ha dado un paso importante y es que los repositorios en donde se administra el código de Qt se han abierto para recibir aportes de la comunidad.

Ahora cualquier persona puede ayudar en el desarrollo de QT contrbuyendo código, traducciones, ejemplos y otro material relacionado con Qt o los proyectos relacionados con este toolkit.  Junto a este movimiento también se ha publicado Qt Jambi bajo la licencia LGPL.  Esto quiere decir que se podrán desarrollar aplicaciones basadas en Qt usando el lenguaje de programación Java y éstas podrán ser de código cerrado, por ejemplo como las aplicaciones basadas en Eclipse que usan Java en combinación con GTK+.

El repositorio en donde se ha publicado Qt usa el sistema de control de versiones Git creado por Linus Torvalds, se trata de uno de los sistemas de administración de cambios distribuido más avanzado, y está tomando el dominio de los proyectos de código abierto a pasos agigantados.

En este sitio no solo se va a publicar Qt, sino que también otros proyectos y herramientas relacionadas con Qt, incluyendo Qt Creator IDE, Qt Jambi y varios proyectos de Qt Labs.

También se ha publicado el roadmap que da una idea de las características que están en pleno desarrollo y los proyectos de investigación en ejecución de tal forma de ayudar a entender la dirección futura de Qt.  Se ha publicado con el fin de que la comunidad también ayude a definir este camino a través del feedback y otras contribuciones.

Link : Qt now open for contributions (KDE News)

Mono

El fundador y líder del proyecto Miguel de Icaza, quien también es el fundador de GNOME, anuncia en su blog la disponibilidad simultánea de la versión 2.4 de Mono y la versión 2.0 de MonoDevelop, el entorno de desarrollo integrado libre basado en Mono.

Los cambios en Mono 2.4 se pueden ver en sus notas de lanzamiento y cubren areas de compatibilidad y rendimiento.  Entre otras mejoras, aquí destacamos:

• Mejoras en el soporte de SIMD : La máquina virtual de Mono permite acceder a operaciones SIMD desde un lenguaje de alto nivel como C#.  Las operaciones SIMD se utilizan para realizar calculos en paralelo dentro del procesador en un solo paso, su uso por excelencia es la manipulación de vectores y/o matrices, una de las funciones críticas de aplicaciones multimedia.  Este soporte fue agregado en Mono 2.2 y ha sido mejorado en esta nueva versión.  Con este tipo de funcionalidad Mono se transforma en una real alternativa para la programación de videojuegos.
• Mejoras en el manejo de hebras : Hasta hace poco se tenía que recargar el sistema mediante polling para implementar operaciones con hebras de una forma independiente de la plataforma.  Se ha cambiado por un nuevo diseño en donde esta técnica que consume recursos adicionales se ha eliminado.
• Mejoras en sistemas multi-core : Cuando se usa una máquina virtual como en .NET y Java, una de las operaciones costosas es la recolección de basura, que se encarga de eliminar de la memoria todos los objetos que ya no se estén usando.  Mono 2.4 habilita por omisión un mecanismo de recolección de basura que aprovecha la disponibilidad de multiples core’s en un procesador.
• Soporte de sitios web precompilados.  El Runtime de Mono ahora permite ejecutar sitios web que han sido precompilados por Visual Studio o la herramienta aspnet_compiler.  Esto abre la puerta a poder ejecutar sitios web que han sido programados con otros lenguajes o características que aun no están disponibles en Mono.

MonoDevelop 2.0

En forma simultánea se anuncia el lanzamiento oficial de MonoDevelop el entorno de desarrollo integrado o IDE basado en Mono.

Las mejoras en esta versión son numerosas y pueden verse en forma completa en sus notas de lanzamiento.  Aqui destacamos:

• Debugger integrado : El debugger de MonoDevelop tiene todas las características que se esperan en un IDE, pero no sólo se puede usar con aplicaciones Mono, sino que también soporta aplicaciones nativas a través de una integración con gdb (GNU Debugger).
• Soporte de autocompletado para C# 3.0
• Soporte de Vala : ahora el poder de MonoDevelop también puede ser disfrutado por los programadores de Vala.  Se trata de un lenguaje de programación de alto nivel que genera código en C, es una forma efectiva de utilizar todo ecosistema que hay para C pero sin tener que sufrir las limitaciones y dificultades de este lenguaje.
• Mejor soporte de ASP.NET : MonoDevelop 2.0 es compatible con proyectos creados en Visual Studio y Visual Web Developer 2008.  Además hay mejoras en el autocompletado del editor y un examinador del DOM (Document Object Model)
• Nuevo editor de texto : El editor GtkSourceView estándar de GNOME ha sido reemplazado por un nuevo editor escrito completamente en C#.  La idea es que este nuevo editor pueda ser desarrollado en forma más ágil y por más colaboradores en comparación al editor original escrito en C.

Bonus Track : Qyoto

Lo siguiente no tiene relación directa con este lanzamiento, pero si aún estás leyendo este artículo es mejor que vayas por un café, porque esto no te lo puedes perder.

Al ser Mono un proyecto muy cercano a GNOME, fue natural tener a GTK# como toolkit libre para implementar interfaces gráficas con Mono. En ese entonces, la alternativa de usar el toolkit Qt, componente fundamental de KDE, el competidor directo de GNOME en el area de escritorios libres para Linux, tenía el inconveniente de contar con un esquema de licenciamiento que dificultaba la creación de aplicaciones libres y comerciales con una teórica mezcla de C# y Qt.

Recientemente Trolltech, los creadores de Qt, fueron adquiridos por Nokia y en un movimiento que soprendió a muchos decidió cambiar la licencia de Qt a LGPL, una licencia más flexible que abre las puertas para poder combinar Qt con otros piezas de software que tengan otro tipo de licenciamiento, y de paso elimina cualquier restricción de crear aplicaciones libres y comerciales con Mono y Qt.

Qyoto es un binding para usar el toolkit Qt4 en aplicaciones Mono y ya han aparecido aplicaciones interesantes con esta mezcla, como es Synapse, una plataforma de mensajería instantánea avanzada, y por supuesto existe QyotoDevelop, una extensión para MonoDevelop creada por el mismo autor de Synapse para facilitar el desarrollo de aplicaciones Qt+Mono en MonoDevelop.

Synapse : una aplicación Qt en Mono

Links:
- MonoDevelop 2.0 and Mono 2.4 officially released (Ars Technica)
- Mono and .NET at Microsoft PDC 2008 (PDF en blog de Miguel de Icaza)
- Mono and Qt (Blog de Miguel de Icaza)

Entre las especulaciones que se hicieron estaba el alejamiento de Maemo, un cambio a un licenciamiento más restrictivo de Qt, lo que complicaría a KDE, etc.  Desde un principio Nokia trató de tranquilizar los animos y prometió comportarse bien con Qt y al parecer lo están cumpliendo.

La semana pasada Nokia liberó la versión 4.5 de Qt y los anuncios desmienten estos rumores y muestran un futuro prometedor para Qt y  otros proyectos en donde se han visto involucrados.

WebKit

La relación entre Qt y WebKit es una historia de amor y odio. Esta historia comienza cuando Apple buscaba un motor de HTML para utilizar en su navegador Safari, una alternativa era usar Gecko de Mozilla y la otra era usar KTHML, el motor de render de KDE creado por Lars Knolls, hoy vicepresidente de ingeniería de Trolltech.  Apple se la jugó por KHTML y en un principio no tuvieron una buena actitud con KDE porque los cambios que Apple hacía a KHTML no retornaban o no eran directamente aplicables a Qt/KDE. Después de varias discusiones, Apple publicó sus cambios en su propio repositorio bajo el nombre de WebKit y comenzaron a recibir cooperación de los desarrolladores de KHTML. El resto de la historia ya es conocida: Hoy WebKit es ampliamente usado tanto por los productos de Apple como en desarrollos abiertos, enfrentándose de igual a igual con Gecko y el motor de render de Internet Explorer.

El release de Qt 4.5 hecho por Nokia incluye a WebKit con el nuevo motor de JavaScript SquirrelFish.  Este motor mejora notablemente el rendimiento de JavaScript tal como lo está haciendo Google con V8 y Mozilla en SpiderMonkey.  SquirrelFish ya es utilizado por Safari 4 de Apple bajo el nombre de Nitro Engine.

Licenciamiento

El licenciamiento de Qt se ha ido abriendo con los años.  En un principio la licencia no era compatible con las definiciones de Open Source de Open Source Initiative (OSI) ni de Free Software de la Free Software Foundation (FSF), y esto hacía que el proyecto de escritorio KDE, al estar basado en Qt, tuviera el mismo problema.  Un efecto colateral de este esquema de licenciamiento fue que motivó la creación del proyecto GNOME como una alternativa completamente libre respecto a KDE.

Posteriomente Qt pasó a un licenciamiento dual, se podía usar Qt como GPL o bajo una licencia comercial.  Si se optaba por el licenciamiento GPL, entonces las aplicaciones tenían que tener un licenciamiento compatible con GPL, pero si se necesitaba usar Qt en aplicaciones con otro tipo de licenciamiento entonces se debía adquirir una licencia comercial para Qt.  Dando un ejemplo concreto, esto impedía que Qt se pudiera usar libremente para desarrollos con licencias propietarias.

Hoy en manos de Nokia, Qt 4.5  es licenciado bajo LGPL (Lesser General Public License).  En pocas palabras esto quiere decir que Qt entrega todas las libertades de la licencia GPL (General Public License), pero no exige que las aplicaciones que lo usan esten licenciadas como GPL compatibles.  Siguiendo el mismo ejemplo anterior, con LGPL ahora se puede usar Qt para desarrollar aplicaciones con licencias propietarias.

Hasta siempre Qtopia / Qt Extended

Dentro del ecosistema de Qt existía Qtopia, posterioremente conocido como Qt Extended.  La idea de este proyecto era tener un framework para dispositivos móviles, pero considerando que Nokia ya cuenta con Maemo y Symbian, no tiene mucho sentido tener un tercer componente que se encargue de los mismos temas.

Nokia anunció (literalmente) el último release de Qt Extended a principios de este mes.  El desarrollo de Qt Extended como un framework separado de Qt se ha detenido, pero seguirá teniendo soporte por un año. Los componentes de Qt Extended que son un aporte a la compañia pasaran a formar parte integral de Qt, potenciando aún más este popular toolkit.

Links:

- Qt gets the Nokia treatment (internetnews.com)
- Qt Software discontinues Qt Extended (qtsoftware.com)

La gran dificultad de contar con versiones para otros sistemas operativos que no sean de Microsoft es que el código original de Chrome estaba demasiado amarrado a Windows, se puede interpretar que la prioridad de Google no era sacar un producto diseñado con miras a futuro, sino que ser el primero en incorporar cambios radicales para competir de igual a igual frente a los dominantes Internet Explorer y Firefox en la plataforma que cuenta con la mayor cantidad de usuarios, el resto se podía atacar más tarde.

Esta actitud puede ser bastante criticada por los talibanes de la Ingeniería de Software, pero la historia demuestra que los diseños perfectos se pueden transformar en proyectos infinitos, en donde un release final puede tardar años, es cosa de recordar lo que costó llegar a la versión 1.0 de Mozilla (antes de Firefox).

Una de las decisiones a tomar por parte del equipo de Chrome era usar o no la misma versión de Windows para las otras plataformas por medio de Wine como ya lo habían hecho antes con Picasa.  El equipo de Chrome considera que su versión para Windows es suficientemente rápida incluso corriendo sobre Wine, ya había evidencia de que la versión actual se puede ejecutar sobre Linux en forma relativamente exitosa, y hasta existe CrossOver Chromium para los que le temen a la linea de comandos.

Pero la ruta más corta, no es necesariamente la mejor.

El uso de Wine quedó descartado debido a que el resto de los usuarios merece tener la mejor experiencia que Chrome le pueda entregar.  Otra alternativa que surgió, fue usar un toolkit que permitiera tener una sola versión multiplataforma, en este caso el candidato claro era QT que está disponible para las tres plataformas.  Sin embargo a la hora de entrar en detalles, el uso de un toolkit genérico hace que se tengan que sacrificar las características únicas de cada plataforma y que sólo se use un denominador común entre ellas, similar a lo que sucede con las aplicaciones construidas con Java Swing. Es también una ruta corta, a costa de sacrificar la integración de Chrome con cada sistema operativo. Como dicen Google, al final se termina hablando con el mismo lenguaje, pero con acento extranjero.

En el caso de Linux, QT puede ser bastante cercano a algo nativo cuando se usa el escritorio KDE, pero en el caso de MacOS X, los usuarios apuntan a una serie de inconsistencias entre una aplicación QT y una aplicación nativa en Cocoa.

El equipo de Chrome quiere que el navegador siga siendo un ciudadano distinguido entre los navegadores y al mismo tiempo que no sea mirado con malos ojos por los usuarios de cada plataforma.  En el caso de MacOS X  declaran explícitamente que la API es demasiado buena como para no aprovecharla.

Un clon la versión de Windows definitivamente no sería aceptable en MacOS X. Donde las APIs para el desarrollo de interfaces de usuario son altamente evolucionadas y tienen muchas características impresionantes.

En Linux el escenario no era tan claro ya que no existe un toolkit nativo que sea usado por la totalidad de los usuarios.  A ojos de Google existen al menos dos grande líderes : QT y GTK+, y entre ellos dos el que está más de acuerdo a sus objetivos es GTK+, lo que provocó una airada reacción de los que consideran que QT es técnicamente superior.

En palabras del lider del área de interfaz de usuario de Google, Ben Goodger:

Mi pensamiento inicial era que un clon de la versión de Windows sería aceptable en Linux dado que el rendimiento de la aplicación por si sola es impresionante, y también debido a  la resistencia de algunos miembros del equipo que trabaja para la versión de Linux respecto a la interfaz del usuario.  Pero se pusieron de pie y hicieron su esfuerzo hacia una interfaz GTK+, si leen las otras discusiones en esta lista, verán que ese es el camino que hemos decidido.

Dado que Chrome es de código abierto, siempre está la posibilidad de que se haga un desarrollo independiente con QT, en donde las voces críticas tendrán su oportunidad de demostrar la defendida superioridad de este toolkit.

Se espera que las versiones oficiales para MacOS X y Linux estén disponibles al público en Junio.

Links:

- Linux : the views situation (Chromium-dev)
- Linux version of Chrome to use GTK+ (OS News)
- Chrome gets Mac deadline (CNET)