Development/Tutorials/KDE4 Porting Guide (es): Difference between revisions

Revision as of 03:37, 5 December 2008

Development/Tutorials/KDE4_Porting_Guide

Introducción

Este es un tutorial con la intención de ayudar a los desarrolladores a migrar sus aplicaciones basadas en Qt3/KDE3 a Qt4/KDE4. Migrar una aplicación basada en KDE3 no tiene por qué ser un proceso complicado. Actualmente, hay muchos scripts y fuentes de documentación que pueden ayudar. Convenciones

Para las instrucciones en este tutorial se van a usar las siguientes convenciones:

programa se refiere a un programa ejecutable.
path se refiere a la ruta.
file se refiere a un fichero.
$SVN se refiere a la ruta completa donde está localizada su versión de KDE subversion.

CMake

A diferencia de KDE3, las aplicaciones de KDE4 serán construidas con la ayuda de CMake. La forma más fácil de migrar el sistema de autotools a CMake es con la ayuda del script am2cmake que puede ser encontrado en el directorio cmake/scripts de el módulo kdesdk. Este creará una serie de ficheros CMakeLists.txt al lado de sus archivos buildsystem anteriores.

Por ejemplo, si su código fuente está ubicado en /path/to/srv entonces:

% cd /path/to/src % $SVN/trunk/KDE/kdesdk/cmake/scripts/am2cmake --kde4

Ejecute am2cmake --help para revisar si necesita la opción --kde4.

También hay una herramienta para mirar por problemas potenciales en sus ficheros CMakeList.txt resultantes. Esta herramienta se llama cmakelint.pl. Y está ubicada en $SVN/trunk/kde/kdesdk/scripts. Se usa así:

% cd /path/to/src % $SVN/trunk/KDE/kdesdk/scripts/cmakelint.pl CMakeLists.txt

O para ejecutarla por todo el directorio de las fuentes, se hace:

% cd /path/to/src % find . -name CMakeLists.txt | \

xargs $SVN/trunk/KDE/kdesdk/scripts/cmakelint.pl

API de Qt4

Una descripción general de la transición de Qt3 a Qt4 puede ser encontrada en el documento "Moving from Qt 3 to Qt 4" de Trolltech. Este documento provee una excelente descripción de los mayores cambios en las funcionalidades en Qt4, es altamente recomendada su lectura.

La continuación, "Porting to Qt 4", nos da una muy buena descripción del proceso para migrar aplicaciones, acompañado además con una lista de los cambios en las clases y funciones.

Estos documentos describen una herramienta proveída por Trolltech llamada qt3to4 que nos puede ayudar en el proceso de migrar las partes Qt de nuestro código de Qt3 a Qt4, usando funciones de compatibilidad. Ejecute qt3to4 así:

% $SVN/trunk/qt-copy/bin/qt3to4 [options] <Infile>, [Infile], ...

Infile puede ser tanto un fichero fuente como un fichero de proyecto. Si se especifica un fichero de proyecto, terminado en '.pro' o '.pri', qt3to4 portará todos los ficheros especificados en ese proyecto.

Para más información ejecute qt3to4 con la opción "--help" o visite la página "qt3to4-The Qt 3 to 4 Porting Tool".

Adicionalmente, existe un programa llamado remove-qt3-support.pl en el módulo kdesdk que buscará y reemplazará por usted muchas cosas Qt3.

Simplemente ejecute este programa sin ninguna opción adicional en el directorio de fuentes así:

% $SVN/trunk/KDE/kdesdk/scripts/qt4/remove-qt3-support.pl

Probablemete quedarán aún algunas clases Qt3 en el código, así que asegúrese de que en su fichero CMakeLists.txt del nivel superior estén definidas las macros para las cabeceras Qt QT3_SUPPORT y QT3_SUPPORT_WARNINGS de esta forma:

add_definitions (-DQT3_SUPPORT -DQT3_SUPPORT_WARNINGS)

API de KDE4

Mucho del esfuerzo al portar las aplicaciones consiste en simplemente renombrar ficheros de clases y cabeceras. Como puede ser muy tedioso cambiar todo esto a mano, existe un script en el directorio scripts/qt4 de kdesdk llamado adapt-to-kde4-api.pl. Este actualizará todos sus ficheros y creará un diff para que así pueda ver qué cambios se realizaron.

Una vez que esta simple sustitución de código se haya hecho, usted deberá aún editar el código para mudarse, por ejemplo, al nuevo KAction API. La documentación sobre todos los cambios en la API puede encontrarse en el fichero KDE4PORTING.html que se encuentra en el módulo kdelibs.

Ficheros UI de Qt Designer

Los ficheros ".ui" de Qt designer creados usando Qt3 deben ser convertidos al nuevo formato de Qt4. Esto se puede hacer usando el programa uic3 disponible en su instalación de Qt4.

% $SVN/trunk/qt-copy/bin/uic3 -convert file.ui > foo.ui % mv foo.ui file.ui

O si prefiere una herramienta gráfica, puede usar el programa Qt4 designer. % $SVN/trunk/qt-copy/bin/designer file.ui

(se puede sobreescribir el fichero file.ui, o si se prefiere guardar como uno nuevo)

Warning

Cuidado, el proceso de conversión pierde cualquier slot hecho a medida, columnas de tablas, etc. Así que se deberán poner algunas cosas de nuevo a mano.

Además debería ejecutar el programa fixuifiles de el módulo kdesdk, este realizará rutinas de limpieza y pruebas de consistencia sobre el código: % $SVN/trunk/KDE/kdesdk/scripts/fixuifiles

D-Bus

En lugar de usar DCOP como KDE3, KDE4 ahora usa D-Bus para la comunicación entre sus procesos. La migración de DCOP a DBus es un tema que está ampliamente cubierto en detalle en el tutorial de migración a D-Bus tutorial de migración a D-Bus.

Para más información, por favor vea nuestros tutoriales sobre D-Bus.

Íconos

KDE4 usa la especificación de nombrado de íconos de freedesktop.org como base para nombrar sus íconos. Esto significa que tanto los íconos incluídos con KDE4 (Oxygen) como los componentes en las kdelibs que usan íconos, usan dicha especificación.

Portar su aplicación desde los nombres de ícono usados en KDE3 a los usados ahora en KDE4 es tan sencillo como ejecutar el script adapt-to-icon-spec.py ubicado en el directorio raíz de su proyecto y seguir las instrucciones en pantalla.

El script automáticamente convierte positivos confirmables (p.e. uso de KIcon o KIconLoader), evita negativos confirmables y pregunta sobre qué hacer con los posibles positivos. Este muestra los últimos en su contexto si así se desea y convierte la tarea en un simple asunto de presionar 'y' o 'n' para completar el proceso.

Internacionalización

Para crear su fichero ".pot", copie los comandos de la regla 'messages' ubicada en el Makefile.am de su proyecto en un script de línea de comandos que se llame Messages.sh. Puede asumir que las mismas variables aún existen ($PREPARETIPS, $XGETTEXT, $podir, etc.), pero tenga presente las diferencias de sintaxis existentes entre el Makefile y los scripts de línea de comandos. También hay que tener cuidado si se usa la opción "-k" con $XGETTEXT, podría tener que listar explícitamente todas las variantes que use. Por ejemplo, la creación de la regla 'messages': messages: rc.cpp

rm -f tips.cpp
$(PREPARETIPS) > tips.cpp
$(XGETTEXT) -ktranslate *.cpp *.h -o $(podir)/kmail.pot
rm -f tips.cpp

Se transforma en el script Messages.sh:

! /usr/bin/env bash

$PREPARETIPS > tips.cpp $XGETTEXT -ktranslate:1,1t -ktranslate:1c,2,2t *.cpp *.h -o $podir/kmail.pot rm -f tips.cpp

Qué hacer y qué no hacer

NO use las antiguas reglas de las clases de sockets.
NO use QPtrList, y en general, setAutoDelete().
NO haga uso de operaciones matriciales.
NO haga código que dibuje en widgets fuera de los eventos de dibujo.
Intente no usar QHBox, QVBox, QGrid. Es preferible que use Layouts en su lugar.
NO use frames de GroupBoxes, Labels o LineEdits para imitar un widget diferente. Use el widget apropiado. p.e., en vez de hacer que un label tenga un sunken lineedit border, ¿por qué no usa un KLineEdit de solo lectura mejor? Y en vez de usar un KLineEdit sin borde para un widget copiable, use KActiveLabel.
¡NO use un GroupBox sin borde para agrupar widgets! Use un Layout.

Documentación

Otras fuentes de ayuda

Canal #kde4-devel en el servidor irc.freenode.net.

Obtenido de "http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide"

@@ Line 123: / Line 123: @@
-==Internationalización==
+==Internacionalización==
 Para crear su fichero ".pot", copie los comandos de la regla 'messages' ubicada en el {{path|Makefile.am}} de su proyecto en un script de línea de comandos que se llame {{path|Messages.sh}}. Puede asumir que las mismas variables aún existen ($PREPARETIPS, $XGETTEXT, $podir, etc.), pero tenga presente las diferencias de sintaxis existentes entre el Makefile y los scripts de línea de comandos.
 También hay que tener cuidado si se usa la opción "-k" con $XGETTEXT, podría tener que listar explícitamente todas las variantes que use.