1. Introducción

NOTA: Esta página está en proceso de traducción. Nos vendría bien tu ayuda para terminarla

¿Qué es un componente?

Los componentes de Gambas son librerías compartidas escritas en C o C++ que añaden funciones nuevas al intérprete de Gambas.

Estos componentes actúan de forma similar a como lo hacen los drivers Linux con el kernel del sistema:

  • Los componentes y el intérprete se comunican a través de la Interfaz de Programación de Gambas.

  • Deben de estar compilados dentro del paquete fuente de Gambas.

  • Son ejecutados en el entorno del intérprete y por tanto no pueden hacer cualquier cosa.

Un componente puede contener:

  • Nuevas clases que son añadidas a otras clases de Gambas. Estas clases son declaradas al intérprete usando una estructura en C que contiene la descripción de cada símbolo, método, constante y evento.

  • Ganchos (hooks) del intérprete: funciones especiales que implementan importantes operaciones del intérprete, como el manejo del bucle de eventos, lectura de los parámetros del programa...

  • Una interfaz de programación que mejore la Interface de Programación de Gambas, y que otros componentes pueden usar.

Un componente debe tener un nombre. Este nombre es la palabra gb seguida por una lista de palabras, separadas por un punto, que describen el papel del componente y la relación entre éste y otros componente, si la hubiera.

Por ejemplo, gb.qt.kde es un componente que transforma una aplicación Gambas en una aplicación KDE. Este componentes está relacionado con el componente gb.qt y cargar el primero implica cargar el segundo.

La Interfaz de Programación de Gambas

La Interfaz de Programación de Gambas es un conjunto de utilidades, funciones y macros que le permiten:
  • Describir el componente.

  • Definir los ganchos (hooks) del intérprete.

  • Manipular matrices (arrays), tablas hash...

  • Manipular los tipos de datos nativos de Gambas.

  • Crear arrays (matrices) y colecciones de Gambas.

  • Lanzar eventos

  • Manipular los objetos de Gambas.

  • Cargar un fichero desde el archivo de proyecto.

  • Cargar otros componentes.

  • ...

El uso de este interfaz de programación está altamente recomendado, porque previene que un componente pueda hacer cosas dañinas.

El Interfaz de Programación de Gambas es una estructura de C que contiene un puntero de función por cada función del interfaz.

Esta estructura se declara en el archivo main del componente y la inicializa automáticamente el intérprete al cargar el componente.

Escribir buenos componentes (Components)

¡Escribir buenos componentes es bastante difícil!. Supongamos que quiere escribir un componente SDL, es decir, un componente que le permita a un proyecto de Gambas usar toda la potencia de la librería SDL: gráficos, sonido, CD-ROM...

Se puede contentar con simplemente recubrir las funciones de la librería, sus estructuras y constantes. Es el modo fácil, incluso si el recubrimiento de funciones y estructuras de C no fuera posible en todos los casos con Gambas.

Su componente sería útil, pero no muy interesante para el programador de Gambas porque se vería obligado a programar en estilo C o C++.

En lugar de hacer esto, sería mejor que se rascara un poco el cerebro para crear un interfaz distinto entre Gambas y la librería, intentando generalizar y simplificar la interfaz original de la librería.

That is what I did with QT: it is far easier to use the QT component than programming the QT library directly. And if one day somebody writes a GTK+ component, he will be able to use the same interface because I tried to generalize the QT interface by avoiding all the QT specific stuff... Well, to be honest, I put all the useful QT specific stuff into a dedicated extended component, gb.qt.ext

Component Source Organization

The source files of a component are stored in a sub-directory of the lib directory of the source package. The path of this directory reflects the name of the component.

For example, the gb.qt.kde component sources are stored in the .src/lib/qt/kde directory.

A typical component directory contains :
  • The autoconf/automake stuff, i.e. a Makefile.am file that describes how to the component. (new topic)

  • One source file and one header file for each main class implemented in the component.

  • One main file that implements the entry points of the component.

  • One component description file.

For example, here is the result of ls ./src/lib/qt/kde just before the compilation : 

CApplication.cpp  CDatePicker.cpp  CDialog.cpp  lib.gb.qt.kde.component  main.h    Makefile.am
CApplication.h    CDatePicker.h    CDialog.h    main.cpp                 Makefile  Makefile.in

The component source directory structure looks something like this: 

-+- lib
 |
 +---+- db
 |   |
 |   +----- mysql
 |   |
 |   +----- postgresql
 |
 +----- eval
 |
 +----- example
 |
 +----- net
 |
 +---+- qt
 |   |
 |   +----- editor
 |   |
 |   +----- ext
 |   |
 |   +----- kde
 |
 +----- sdl