Development/Tutorials/Services/Plugins (es)

From KDE TechBase
Revision as of 14:13, 27 February 2009 by Tampakrap (talk | contribs) (New page: {{Template:I18n/Language Navigation Bar|Development/Tutorials/Services/Plugins}} {{TutorialBrowser| series=Services| name=Creando y cargando Complementos usando KService| pre=[[../Trad...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


Development/Tutorials/Services/Plugins


Creando y cargando Complementos usando KService
Tutorial Series   Services
Previous   Traders: Querying the System
What's Next   n/a
Further Reading   n/a

Resumen

Antes de empezar con el código, vamos a ver qué ventajas podemos obtener desarrollando una aplicación estructura en complementos (plugins). Primero de todo, una aplicación capaz de manejar complementos puede extender su funcionalidad sin límites aparentes. No obstante, en lugar de desarrollar un aplicación estructurada en complementos porque "es muy guay!!", el desarrollador debería pensar en las ventajas reales de este tipo de desarrollos. Por ejemplo podemos pensar en una aplicación que maneja archivos: el programa principal delega la creación/extracción/edición de cada tipo de archivo al complemento específico. De esta manera conseguimos modularidad en la aplicación, de forma que soportar nuevos tipos de archivos en el futuro consistirá simplemente en escribir el complemento específico y no en reescribir la aplicación. Bien, dejemos de hablar... y empecemos a programar =).

Ejemplo del Editor de Textos

Aunque una aplicación de manejo de archivos sería resultaría más bonita, aqui examinaremos un editor de textos simple capaz de cargar complementos. Cada complemento proveerá simplemente una característica nueva para la edición de texto.

Creando una clase como Interfaz de Complementos

El paso principal para crear una estructura de complementos es definir su clase base. Esta clase será heredada por cada complemento y debería dar acceso a los recursos de la aplicación principal. En este ejemplo la clase principal de un complemento heredará un KXMLGUIClient, ya que cada complemento dará acceso a sus añadidos a través de un elemento gráfico (un KAction en este caso).

  1. include <kdemacros.h>
  2. include <kxmlguiclient.h>
  3. include <QObject>

class KTextEdit;

class KDE_EXPORT Plugin : public QObject , public KXMLGUIClient {

   Q_OBJECT
   public:
       Plugin(QObject *parent);
       virtual ~Plugin();
       /**
        * @return KTextEdit apunta al control de edición de la aplicación principal
        */
       KTextEdit* editorInterface();
       /**
        * @internal Usado por la aplicación principal para establecer correctamente el editor.
        * No llamar desde la reimplementación.
        */
       void setEditorInterface(KTextEdit *);
   private:
       class PluginPrivate;
       PluginPrivate *d;

};

Esta clase base dará los punteros necesarios para cada complemento que le permitan manipular los datos de la aplicación principal. En este caso, sólo damos acceso a la interfaz del editor principal a través de editorInterface().

La Macro de la fábrica de complementos

Cada complemento estará "visible y disponible" a través del uso de una macro. Por tanto, mejor poner esta macro en nuestro propio myplugin_macros.h como sigue.

  1. include <kdemacros.h>
  2. include <KPluginFactory>
  3. include <KPluginLoader>
  1. define TEXTEDITOR_PLUGIN_EXPORT( c ) \
 K_PLUGIN_FACTORY( TextEditorFactory, registerPlugin< c >(); ) \
 K_EXPORT_PLUGIN( TextEditorFactory("c") ) 

Registrando un Tipo de Complemento

Registrando un Complemento con SyCoCa

Encontrando Complementos

Instanciando Complementos