Thefull

Ramas de desarrollo

Entre troncos y ramas anda la cosa.

Acabo de entender y llevar a la practica, el concepto de rama
de desarrollo bajo CVS.

Si bien el concepto lo tenia claro, dicha implementación no la
tenia todas conmigo.

Estoy usando para ello el tortoise como cliente, y la verdad , que hasta
que no descubri como funcionaba el tema del Update Special pues la
verdad es que no iba a ningun lado ;-)

La verdad , es que lo primero que hice para jugar con las ramas fue usar
el subversion.

Parece mentira que la gente se empeñe en decir que Windows es fácil de usar.
Con todos mis respectos, pero bajo GNU/Linux ES MUCHISIMO más fácil hacer
casi cualquier cosa.

Mira si es fácil, que para poner a correr el servidor de subversion:
svnserver -d ( como demonio ) , desde una shell.

Si encuentras algo mas sencillo que esta linea, me lo dices.

Lo que pasa, es que la gente tiene la fea costumbre de no leerse como
funcionan las cosas, o es más fácil molestar al vecino que tiene su Windows
para que nos eche una mano.

Despues, los ilusos, se creen con valor de decir que GNU/Linux es una mierda,
con perdón, cuando deberían de preguntarse, si realmente lo que son es un
completo IGNORANTE!.

En fin... a lo que ibamos.
¿ Como puedo aplicar una rama a mi proyecto y no morir en el intento ?

Normalmente, tenemos la sana costumbre de aplicar una instantanea, tag, del
estado actual, ok ?

Bien , pues la rama es 'algo similar', con la diferencia , que para podemos
estar en el tronco( HEAD ) , o en un rama 'determinada', sin ningun problema.

Asi, mientras unos usan por ejemplo, el tronco, yo puede 'derivar' parte de
mi trabajo a una rama, y seguir trabajando sin afectar al resto.

Muchas se preguntaran que sentido tiene esto, que desarrollando sobre el HEAD
y con tal de no hacer un 'commit' pues es lo mismo. Graso error.

Explicaré el porque me a llevado a experimental y llevar a la práctica el
uso de ramificaciones en el código de T-Gtk.

Como bien sabeis , GTK dispone de varias versiones, y cada version contiene
sus múltiples widgets, tambien hay funciones en unas y otras.

Como somos 2 desarrollando, Joaquim tiene las GTK 2.4 bajo XP, ya tengo las
GTK 2.6 en XP y 2000 y la 2.4 en GNU/Linux.

¿ Que pasa si introduzco código 'experimental' de la 2.6 ?
Automaticamente, Joaquim en su maquina y yo en mi GNU/LInux vamos a tener un
problema a la hora de intentar compilar las librerias de T-Gtk, porque no
encuentra funciones.

Quizas una manera elegante, tal y como he realizado en codigo de T-Gtk es usar
el chequeo de version en tiempo de compilacion, #ifdef , pero , si el
código es experimental , no creo que quede muy elegante realizarlo de esta
manera.

La solución pasa por hacer una rama en el CVS, usar la rama en el sistema
que me permita usarlo , sin interferir para nada en el desarrollo normal
de T-Gtk.

Asi, llegada la hora de que considere que este estable , fusionaré la rama
contra el tronco( HEAD ).

Al luchar entre distintas versiones de GTK+, y de momento, los dos sistemas
soportados, GNU/Linux y Windows, creo que las ramas son la mejor opcion de
ir avanzando en arreglar y experimentar sobre código muy inestable, no
afectando para nada al desarrollo de los demas miembros.

Os dejo imagen para que veais como esta quedando un fichero en concreto,
pango.c , dentro del CVS.
Podeis observar, las tags, el desarrollo principal HEAD, y la rama
'pango_under_2_6

Y tú, ¿ Ya vas haciendo el mono por las ramas ? ;-)

Para saber más sobre ramas del CVS:
http://lucas.ok.cl/Manuales-LuCAS/doc-cvsbook-es/cvsbook-html/Ramas.html

Soporte de primitivas

Ya tenemos disponible T-Gtk soportando primitivas gráficas.
No he podido resistir acabar una cosa que tenia hace tiempo pendiente, y no encontraba tiempo para ello.
Este sábado me he puesto esta tarde , y he terminado la primera hornada
de funciones de GTK para primitivas.

Desde arcos, rectangulos, hasta imagenes , texto, etc.... todo dibujando sobre
el widget gtk_drawing_area.

Dicho widget nos brinda una superficie para poder 'imprimir' , sobretodo, primitivas gráficas.

Pero , para poder enseñar en la superficie lo que tengamos pensado mostrar,
necesitamos hacerlo en el evento expose_event.

En dicho evento , recogeremos el widget de gtk_drawing_area que nos viene como
parámetro a la función que haremos que 'pinte' lo que nos interese.

Sale del proposito de este blog explicar cada funcion gdk_() disponible para realizar
primitivas gráficas, asi que no comentaré nada sobre como mostrar arcos, etc..,
teneis la documentación de gtk disponible en Intenet, ahi podeis consultar cualquier
tipo de duda o en su defecto , en cuanto publique la próxima revision de T-Gtk,
tendréis disponible el código fuente.

Por cierto, todo es controlado a nivel de Harbour, y me gustaria mostraros un par de lineas de ejemplo:

Funcion Dibuja( widget )

// contexto gráfico
gc = gdk_gc_new( widget )

// Propiedades de linea
gdk_gc_set_line_attributes(gc,;
5,; /* grosor */
GDK_LINE_DOUBLE_DASH,; /* tipo de línea (sólida en este caso) */
GDK_CAP_PROJECTING,; /* terminación (redondeada en este caso) */
GDK_JOIN_ROUND) /* unión de trazos (redondeado en este caso) */

aMiColor := { 0, 0XFFFF, 0, 0 }
colormap := gtk_widget_get_colormap( widget )
gdk_colormap_alloc_color( colormap, color,;
FALSE,; /* sólo lectura, para poder compartirlo */
TRUE ) /* si no lo puede reservar, pide uno parecido */
gdk_gc_set_foreground( gc, color )
gdk_draw_line( widget,; /* área en donde dibujar */
gc,; /* contexto gráfico a utilizar */
1, 1,; /* (x, y) inicial */
200, 200) /* (x, y) final */

...ETC....
...ETC....

g_object_unref( gc )

Return Nil

Si observais esas lineas de código, la unica diferencia con respecto a C es que
en vez de pasar estructuras de color, lo sustuimos por un simple array,
aMiColor, donde cada posicion es un miembro de la estructura GdkColor, de
esta manera conseguimos un parecido lo mas aproximado a C.

Pero, basta ya de tanto teoria y vamos haber el resultado:

Por cierto, fijaos en las transparencia que realiza el solito, tanto la imagen, de logo de glade.png asi como el resto de primitivas.

Saludos.
Rafa Carmona