Thefull

T-Gtk con soporte Glade

Primera etapa inicial soportando Glade.

Muchos de vosotros me han escrito si T-Gtk correra con fuentes , con poo, que tipo de jerarquia de clases y sobre todo si se podra usar glade.

Bien, lo estaba dejando pendiente de implementar, quedan muchas cosas por ahora, sobre todo en el tema de la POO, y no he podido resistirme,....

T-Gtk tiene la puerta abierta para usar GLADE como diseñador
de nuestra aplicacion.

Como muestra, una imagen donde todo lo que veis esta creado desde glade y
corriendo bajo harbour, como si nada ;-), ademas, con conexion a señales.

De esta manera, un simple fichero xml que genera glade, tenemos un paso mas
hacia nuestro REDEFINES de los ficheros .RC

De esta manera tendreis :
- O programar en base a funciones
- O programar en base a POO de una jerarquia al estilo GTK, en base contenedores.
- O diseñar nuestras ventanas en base a Glade y usarlas en nuestra aplicacion.

La verdad es que en principio todo se puede mezclar :
¿ Y a ti que, te gusta todo este PURURRI ;-) ?

Saludos.

POO y más 'cacharros'...

Mientras yo me dedicaba a la implementacion de POO para T-Gtk,
Joaquim se dedicaba a la implementacion de más Widgets y a añadirle mas funcionalidades.

Como pasa el tiempo, parece que fue ayer cuando 'el juguete' empezo con sus primeros pasos, todo eran mimos y ilusiones.

Con el paso de las semanas, 'el juguete' empezo a crecer, y vinieron nuevas necesidades, y el 'padrino Joaquim Ferrer' le regaló unos 'cacharros' a base de 'Listas Multidimensionales', iconos, dialogos, etc..., lo esta mal mimando ;-)

Además, al 'papa' le dio por ver sus primeras implementaciones de 'POO',
todo muy sencillo, tan sencillo que cuesta creerlo, para ejemplo un trozo de
codigo:

DEFINE WINDOW oWindow TITLE "GUI T-Gtk for Harbour by Rafa Carmona"
DEFINE BOX oBoxMenu VERTICAL OF oWindow
Create_Menus( oBoxMenu ) // ----> Nos vamos a crear MENUS!!

DEFINE BOX oBoxH OF oBoxMenu
DEFINE BOX oBoxV VERTICAL OF oBoxH
ListBrowse( oBoxv )
DEFINE LABEL TEXT cTextLabel MARKUP OF oBoxV

DEFINE BUTTON oBtn TEXT "Hola, ponte encima" ACTION MyClicked( oBtn ) OF oBoxV

// Podemos asignar señales facilmente
oBtn:bLeave := { |o| MyLeave( o ) } //Asignamos al code la ejecuccion de codigo
oBtn:Connect( "leave" ) // y conectamos la señal

DEFINE TOGGLE oToggle TEXT "Comnutador" OF oBoxV ACTION EstadoCom( o )

DEFINE BUTTON oBtn ;
TEXT "_Salida rapidita..." ;
MNEMONIC ;
ACTION Exit( oFont );
OF oBoxV FONT oFont
oBtn:Style( "Blue", FGCOLOR , STATE_NORMAL ) // cambiamos el estilo del boton

DEFINE BOX oBoxV2 VERTICAL OF oBoxH

DEFINE IMAGE oImage FILE "nena.jpg" OF oBoxv2 CONTAINER

ACTIVATE WINDOW oWindow CENTER

y a medida que la criatura va creciendo, sus exigencias son mas altas ;-)
ahora con pleno soporte de menus, mirar el dialogo "Ejemplos" es una parte
que podemos hacer que salga automaticamente, realmente es el menu de la barra de herramientas!! ;-), ...,
y mucho mas que esperemos dar noticias sobre ello.

El resultado del trabajo, 90 % en POO + funciones de widgets aparte :

T-Gtk. Mas implementaciones

Mas implementaciones para T-Gtk...

En esta semana he podido terminar , por mi parte :
+ Los menus y sus distintos menuitems( falta solamente los radiomenus )
+ La barra de botones y sus distantas representaciones de botones.

Solamante para GTK2.4 , pues en GTK+2.0 es completamente distinto, y no
se aconseja su uso por que no se va a usar mas y no garantizan que este en versiones posteriores de la 2.4, asi , ¿ Para que perder el tiempo ? ;-)

Espero que veas como con [x]Harbour es posible tambien hacer cosas sorprendentes en cualquier sistema.

Os dejo imagen para que vayais viendo los progresos

Mi buen amigo Joaquim Ferrer esta metiendo mano a ListBox , Tree, etc..
que espero añadirlo a mi repositorio lo antes posible.

Saludos.

Aspecto Visual T-Gtk

Este seria el aspecto de muestras aplicaciones usando T-Gtk.

Como no tenia nada que decir, ya lo dice el refran:
Una imagen vale más que mil palabras

Este ejemplo corre sobre una Fedora Core 1 , con un themes con aspecto
mac, me encanta ;-).
Es una version de T-Gtk sin soporte de Expander, sobre GTK2.2, como
podreis comparar con la siguiente imagen.

Este ejemplo es el mismo codigo, con expander incluido, GTK2.4, sobre
Windows XP, y con un themes añadido por GTK ;-)

Espero que os guste estas capturas y para quien quiera ver el codigo fuente:

Download ejemplo demo.prg

Saludos.

T-Gtk. Implementacion Multiplataforma bajo GTK+

T-Gtk. Implementacion Multiplataforma bajo GTK+

Dentro de la reunion que tuvo lugar en Barcelona, explique lo que era T-Gtk
y para que la gente entienda el concepto dejo en estas lineas, espero que os
saque de dudas, lo que es y lo que no es T-Gtk.

Todo aquel que quiera probarlas, ya sea bajo Win32 o GNU/Linux,
enviarme un correo con el asunto: T-Gtk y sobre que plataforma.

¿ Que es T-Gtk ?
T-Gtk es un GUI de GTK+ para usarlo desde [x]Harbour.

Sobre que sistema operativo funciona
T-Gtk correra donde haya un Harbour , gcc y gtk+ disponible, es decir,
actualmente compagino en probar tanto en GNU/Linux y Windows, pero
tambien podra correr sobre MAC, FreeBsd, etc..

Estamos hablando a nivel de COMPATIBILIDAD de codigo a nivel de GUI,
no de codigo a nivel de sistema, como por ejemplo, la gestion de INIs,
el acceso a nivel de hardware, etc... donde los sistemas son completamente
distintos.

Implementacion y uso.
El camino escogido a sido, desde mi punto de vista claro esto, ser lo mas
parecido a GTK+ a nivel de C, ¿ Que quiero decir con esto ?
Quiero decir, que para programar , se programara practicamente como se hacer
en C, a nivel de funciones, despues ya se encapsulara todo eso , y si,
haremos el mismo preprocesador DEFINE WINDOW....

¿ Tengo que saber C ?
No. Que las funciones del API de GTK+ , sera el mismo nombre de funcion a
nivel de harbour, no signifique que se vaya a programar en C, si no
que se usara EL MISMO NOMBRE de la funcion, por ejemplo:

Si para crear un boton en C es :
GtkWidget * button = gtk_button_new_with_label( "Hola" );

transformando a T-Gtk+Harbour sera:
button = gtk_button_new_with_label( "Hola" )

Ustedes se preguntaran el porque asi, y no haber creado una funcion
que se llame, createbutton( cLabel ).

EL motivo principal, es que si buscan ayuda sobre una funcion en GTK+,
la misma ayuda de C le servira, porque se comportara EXACTAMENTE IGUAL.

Asi , la trasformacion de codigo C a PRG es trivial, en cosas bastantes
sencillas.

Ahora bien, para ahorrar velocidad y facilitar un poco la historia, hay
dos excepciones de momento:

+ Conversion a traves de Macros, esto lo hace ya automaticamente desde C,
no hace falta hacerlo, por ejemplo, esta funcion en C :

GtkWidget * button= gtk_button_new() ;
GtkWidget * checkbox = gtk_check_button_new_with_label( "Check" );
gtk_container_add( GTK_CONTAINER( button ), checkbox );

en harbour quedaria:

button= gtk_button_new()
checkbox = gtk_check_button_new_with_label( "Check" )
gtk_container_add( button , checkbox )

fijese , que la macro GTK_CONTAINER a desaparecido.

+ Por comodidad de transportar el codigo de C, se ha echo el soporte
de dichas funciones, que lo unico que hace es retorna el valor pasado.

+ La function Gtk_Connect_signal permite saltar a una funcion estatica en
Harbour, porque Harbour mete en la tabla dinamica de simbolos las
funciones estaticas, y Xharbour NO!
En xHarbour solamente se puede saltar, por el momento, a funciones
publicas.

Ahora bien, como pueden ver en los ejemplos, el usar funciones, impone
el escribir mucho codigo, para ello, tambien se esta portando a la
programacion de POO, de esta manera, sera mucho mas rapido y ademas
realizar el preprocesado es trivial y aprovecharemos mejor el tiempo.

¿ Como funciona GTK+ y que es eso de los widgets ?

Los widgets son sinonimos de controles en sistema Win32 API.
GTK+ es una libreria que crea y pone a disposicion una seria de controles,
para ello se basa en otro libreria de nivel inferior, GDK, que es la
encargada de dibujarlos, a parte de otras mas.
A nivel mas bajo , se conecta con XLib o Win32, nada mas.

En GTK+ existe el concepto de 'contenedor' de widgets, y solamente puede
contener un solo widget, es decir , un hijo.
Usted se pregunta , ¿ entonces en una ventana como coloco mis botones ?
Como dice el dicho popular, HECHA LA LEY HECHA LA TRAMPA,
pues bien sencillo, un contenedor a su vez puede contener a su vez a
otros contenedores.

Para entendernos, seria equivalente a usar la clase TPanel de Fivewin,
y esta a su vez fuera mas paneles, que contienen los botones.

Hay varios tipo de contenedores, hBox, vBox, paned, table, etc...

A su vez , un boton es un contenedor que contiene una etiqueta, por ejemplo.

A principio, este concepto es muy extraño si lo comparamos con el api win32,
pero es mucho mas potente a efectos practicos, son AUTODIMENSIONABLES, no
tenemos que gestionar su ancho / alto, el solo lo hara y se adaptara segun
le hayamos especificado su comportamiento.

Que de madura esta.

Actualmente esta portado estos widgets :

+ Window
+ Get/Entry ( Partialmente )
+ Notebooks
+ Button
+ Say
+ Radiobutton
+ Checkbox
+ Table
+ Box
+ Tooglebutton
+ Frame
+ Calendar
+ Paned
+ Image
+ Expander
+ Menus ( Parcialemente, falta el checkmenu, imagemenu )
+ Fixed
+ StatusBar
+ Separador
+ ProgressBar
+ Soporte de lenguaje de Marcas.
+ hSeparator
+ vSeparator
+ VBox
+ HBox
+ ToolTips
+ ButtonColor
+ Fonts ( Parcialmente, permite poner fuente a los widgets )
+ Combobox

Prototipo de Clases y control de eventos :
+ TWidget
+ TWindow
+ TButton

Funciones para hace la vida mas simples.
+ MyStyle(). Pon un stylo determinado a un widget concreto.

Explicacion de ejemplos

1.ProgressBar
Este ejemplo sencillamente enseña las distintas maneras de las cual podemos
enseñar una barra de progreso.

2.StatusBar.
Enseña como funciona la barra de status y los comboboxs.

3.Radiobutton
Ejemplo de seleccion por defecto de de unos radiobuttons, el 2.

4.Radiobutton2.
Metiendo un widget entry en el radiobutton.

5.Fixed.
Implementacion de widgets en posiciones fijas, a la win32

6.Notebook.
Sinonimo de Folders, funcionamiento de posiciones, etc..

7.Demotable.
Funcionamiento de tablas de empaquetamiento, imagenes y botones por
defecto, separados por un paned, simil de splitter y Fonts.

8.Demo.
Distintos widgets, calendar, expand, lenguaje de marcas, menus, el mas
completo.

Conclusiones de la Reunion de Barna.

Como diria mi buen amigo Rene Flores, IMPRESIONANTE!!
Sobretodo, porque teniamos aire acondicionado, joe que calor que hacia fuera..

Ante todo , muchas gracias a Jose F.Gimenez y Capel por hacer el
esfuerzo de asistir, venian de Almeria y Valencia, ahi es na! ;-)
y a Freddy que vino desde Zaragona.

Vayamos por partes.

1.- FiveLinux.
La gente pude ver como se esta montado FiveLinux por dentro y se
dieron cuenta la similitud que hay con Fivewin, por eso no me extendi
demasiado, pues parece un 'clon' de Fivewin, y apenas me tuve que
esforzarme en las explicaciones.

2.- T-Gtk.
Me dio la sensacion, de que la gente todavia no se creia que como
era posible que el mismo codigo funcionara exactamente igual
en Window que en GNU/Linux corriendo en Harbour.
Y cuando digo 'EXACTAMENTE IGUAL' es sin modificar una coma.

3.- C3.
Vimos la aplicacion de Xevi corriendo con C3 y su GUI Nativa,
yo todavia me saco el sombrero por lo que esta haciendo Bruno.

4.-GForge.
Este impresionante gestor de proyectos que nos enseño Salva
nos dio la oportunidad de 'ver' lo atrasados que vamos con
respecto a gente 'profesional' ;-)

5.- Fivewin.
Estuvimos hablando sobre todo del presente/futuro de esta
gran herramienta y de como todavia puede seguir dando mucha
guerra.

6.-Xailer.
Señores, yo no se ustedes, pero esta gente SE LO A CURRADO!!!
Impresionante la facilidad y encima cosas que en Fivewin serian
MUY COMPLEJAS DE HACER, con Xailer son dos clicks de raton,
y no se si el pintado de controles lo haria tambien como la
solucion de esta gente.
Ah! Y vimos el control de rtf que tiene Xailer, gracias a Pedro Gil,
otro del Team de Xailer, donde es una verdadera delicia realizar
documentos compuestos.
Otra de las caracteristicas es su 'peculiar' herencia de controles,
donde para realizar una modificacion del comportamiento de un control
en concreto no es necesario MODIFICAR la clase original, una idea
cojonuda la cual estoy muy interesado...

Y porque el tiempo no daba para mas, sino hubiesemos visto mas
cosas en profundidad.

Lástima que Jose no trajo la version con soporte OCX, jejeje no quiso
mostrar todo el potencial de Xailer, pero cuando lo liberen creo
que sera una novedad mundial a nivel xBase.

Y alguna otra novedad por parte de Jose Lalin, no digo nada mas,
que me comento Jose F.Gimenez, que sera tambien una sorpresa dentro
de Xailer, otra mas de las sorpresas.

Muchas gracias a Jose F.Gimenez por aclararme muchas de las dudas,
sobretodo con la maquina virtual de harbour y las callbacks,
por ser una de las personas mas 'cojonudas' que conozco del xBase,
y por ser tan buena persona que hasta me ofrecio el motor de objetos
de Xailer por si lo necesitaba para mi propia GUI experimental.
( Cenando le saque un papel y boli, pa que firmara ,jejeje, en plan coña..)

Yo , simplemente, con gente como esta da gusto reunirse.

Conclusiones:
Las conclusiones y charla sobre las distintas opciones que se nos
vienen encima fue realmente interesante.
Por un lado, Xevi es un incondicional de C3, estaba muy a gusto
con el, Carles tambien estaba muy a gusto con Fivewin,
yo claro, estoy a gusto con mi juguete , jejeje, y el resto, en fin
cada uno estaba con lo suyo.

Lo que esta claro, y creo que eso es lo que la mayoria de gente
estuvimos de acuerdo, es que para empezar un proyecto nuevo,
Xailer BARRE a todos las posibles opciones.
Como opinion personal, creo que Xailer es la herramienta MEJOR
situada AHORA mismo para empezar un proyecto NUEVO.

Con Xailer empieza una nueva manera de programar con xBase, basado en
la sencillez y con todo la potencia de Windows, y se pone a la altura
de cualquier lenguaje moderno con las ultimas tecnologias para Windows.

Yo , solamente espero, que Antonio Linares, nos sorprenda con 'algo'
realmente similar en calidad/potencia de Xailer, pero si FW3.0 va estar
basado en lo que hay ahora, mucho me temo que eso no sera suficiente,
pero conociendo a Antonio, quizas nos sorprenda con algo realmente
interesante...

Bueno, en fin, siempre nos quedara organizar otra el año que viene ;-),
y hablar de como a evolucionado todo con respecto a esta reunion.

Saludos.