Ahora que la liberación de la versión 3.4 está próxima, muchos nos preguntamos qué será lo próximo que venga tras esta nueva versión. Llevamos mucho tiempo oyendo hablar sobre Qt 4, y las nuevas tecnologías que se van a implementar en el futuro KDE 4. Sin embargo, leyendo la lista de correo de kde-core-devel, la discusión sobre el futuro desarrollo de KDE está muy activa.

Stephan Kulow, el coordinador principal de KDE, ha dado una serie de pistas sobre lo que vendrá este año:


Cambiar el gestor de versiones de CVS a Subversion.

Portar KDE a Qt 4.

Portar KDE a Windows.

Cambios en el sistema de construcción (en parte por lo dicho anteriormente).

Cambio al estándar gettext.

Cambios en DCOP (DBUS ya fue discutido).

Cambio de la capa del sistema de sonido.

Limpieza a fondo del API.


La cuestión es cómo acometer todas estas novedades. Stephan dice: "esto puede sonar a mucho, y efectivamente así es. Ninguno querría tener KDE4 a finales de 2006, sino lo más pronto posible. Y aunque no haya una versión estable para los usuarios, nos gustaría tener una versión que funcione lo suficientemente bien para nuestro uso diario. Y por encima de todo, no todo el mundo quiere deshacerse de KDE3 y empezar a trabajar en KDE4, sino que preferirían liberar un KDE 3.5 (lo que retrasaría KDE4 aún más debido a la división de los desarrolladores)."

Muchos de los cambios no son críticos en el tiempo, aunque otros sí. Stephan propone el siguiente calendario:


KDE 3.4 es liberado.

Migramos a Subversion (esto requerirá un tiempo sin poder desarrollar cada módulo mientras se hace el traspaso).

Creamos un montón de ramas:
[**]KDE_3_5_BRANCH : para la futura liberación de KDE 3.5. Cuando esté claro que el desarrollo ahí esté parado en tanto que la gente esté satisfecha o aburrida con él y gaste su tiempo con Qt4, se hará una liberación en un tiempo corto (por ejemplo dos mese después de estar de acuerdo en la liberación), y como muy tarde en navidades de 2005.
[**] new_build_system_branch : en tanto en cuanto nada compile, me gustaría tenerlo en una rama.
[**] Qt4_branch : para módulos junto a kdelibs. HEAD de kdelibs será Qt4, pero todos los otros módulos deben estar fuera del port de Qt4 mientras no sean resueltos.
[**] DBUS_branch/noarts_branch/lo_que_sea : Mientras estén en su primer desarrollo, deben estar fuera de HEAD. De esta forma tendríamos al menos medio camino trabajado en HEAD todas las veces.

Recordaremos una buena regla del pasado: cambios incompatibles en HEAD (por ejemplo, cambios experimentales) sólo se harán entre lunes y miércoles. Con subversion estamos suponiendo tener mucho mejor control sobre las ramas, por lo que haremos uso de ellas siempre que lo necesitemos.

Liberaremos una versión alpha1 siempre que una de las cosas de mi lista esté finalizada y los fuentes compilen. Haremos esto cada 6 semanas tras la primera alpha1.


"Por todo esto imagino que terminaremos el paso inicial a Qt4 al mismo tiempo que se libera KDE 3.5, por lo que todo casa perfectamente".

Cornelius Schumacher hace un importante inciso:
"Hacer un desarrollo basado en kdelibs 3 en paralelo a la portabilidad a Qt4 y el desarrollo en kdelibs 4 suena como una pesadilla, por estas razones:


Escasez de recursos. Dudo que haya mucha gente capaz de trabajar tanto en la rama kdelibs 3 como en la basada en kdelibs 4.

Un infierno de integraciones. Integrar características basadas en Qt 3 en código también portado a Qt 4 puede ser terrible. Clases y funciones renombradas, cambios en el API de Qt y nuevos conceptos como el modelo de vista de clases o los nuevos iteradores pueden hacer esto muy difícil, propenso a errores y muy costoso.

El desarrollo de la biblioteca no puede realizarse de forma teórica. Necesitamos aplicaciones usando las bibliotecas para tomar las decisiones correctas acerca del API y la implementación del mismo, las necesitamos para los casos de prueba, etc.


"Un problema adicional es que Qt 4 todavía no está terminado. Trolltech indica que no liberará Qt 4 antes de Junio, dentro de 4 meses. He probado las previews y la beta y mi experiencia fue que está bien para pruebas y jugar un poco con ello, pero no para un desarrollo serio".

Esta es la propuesta que hace Cornelius:
"La próxima versión será la 3.5. Usaremos los 4 meses hasta la liberación de Qt 4 para implementar las nuevas características y mejoras de usabilidad, integrar nuevo artwork, mejorar la documentación, completar traducciones, mover a subversion, experimentar con el nuevo sistema de construcción, pero sin hacer todavía ningún traslado a Qt 4.

El día que Trolltech libere la versión final de Qt 4.0 hacemos una rama y congelamos el CVS (o el subversion) para la versión 3.5 y comenzamos a portar la rama HEAD a Qt4. Luego procedemos con el esquema de liberaciones alpha que propuso Stephan hasta tener KDE 4".

Stephan respondió:

"No, necesitamos hacer una portabilidad mayor a Qt4 "antes" de que el API sea final. Así se hizo con Qt2 y Qt3. Tú dices que necesitas aplicaciones que usen la biblioteca para diseñar una buena biblioteca y dos párrafos más adelante que no debemos usar Qt4 antes de que esté completo ¿no ves la ironía?

Nadie dice que no hagamos ningún tipo de nueva característica junto al artwork para KDE 3.5; y sí, KDE 3.5 no será la versión en la que pongamos más empeño. Pero así está bien".

Como veis, muchas discusiones, pero que dan una idea de por dónde se va a mover en los próximos meses la evolución de nuestro escritorio favorito.

Fuente: KDE-Hispano