= WebKitGTK+ =
''' Expositor: Diego Escalante Urrelo (diegoe) '''
''' Moderador: Sergio Infante Montero (neosergio) '''
'' Sabado 19 de Diciembre de 2009, 17:00 horas UTC ''
'' irc.gnome.org #gnome-hispano ''
----
''neosergio''
{{{
Siendo las 17.05 UTC
Bienvenidos a todos a la Charla IRC de Diciembre
de GNOME Hispano
Hoy el tema sera: WebkitGTK+
estara a cargo de Diego Escalante - http://www.gnome.org/~diegoe/
antes de iniciar les pediria a todos intervenir cuando sea absolutamente necesario, con mensajes que ayuden a la charla
listo diegoe adelante la sala es tuya
}}}
'''diegoe'''
{{{
bueno
comencemos.
primero una rápida presentación, soy Diego Escalante Urrelo, participo en GNOME desde 2006
principalmente en Epiphany, el navegador web, aunque también en otros módulos. ahora estoy en el consejo de directores de la Fundación GNOME
hoy vamos a hablar sobre WebKitGTK+
haremos 2 partes, una de puro texto y mentiras, digo, información. luego veremos un ejemplo
para la segunda parte, si no tienen instalados los paquetes de desarrollo probablemente quieran ganar tiempo si tienen una conexión lenta
me parece q les bastará con libgtk2.0-dev y libwebkit-dev
si están usando debian o ubuntu, eso. si usan Fedora o parecidos, no tengo idea
}}}
''neosergio''
{{{
http://es.gnome.org/Eventos/CharlasIRC/CharlaDiciembre2009
}}}
'''diegoe'''
{{{
:)
pero es seguramente Gtk-devel o Webkit-devel
bueno. hecha la aclaración, vamos a la primera parte
primero, qué es webkitgtk? WebKit para empezar es un motor de render o de dibujado web. es como gecko (lo que dibuja las páginas en Firefox)
originalmente fue un fork de KHTML
lo hizo apple para usarlo en safari y etc, con el tiempo lo abrieron un poco más y ahora hay ports o frontends para varios toolkits
hay para Qt, Windows, GTK+
el que nos importa es el de GTK+, obvio.
WebKit lo desarrolla principalmente Apple y algunas empresas q rotan alrededor. El port GTK+ lo tocan principalmente Igalia y Collabora, actualmente.
antes han contribuido varias compañías más, y ahora mismo también, pero de memoria y para mencionar fácilmente esas dos.
ah y claro, Google mete mucho trabajo ahí, aunque ellos no usan directamente el port a Gtk+, es medio raro esto de chrome
bueno. lo especial del port GTK+ versus otras cosas es que se reutiliza el stack de GNOME
stack de GNOME son las librerías con las q está hecho casi todo en GNOME: cairo, gstreamer, libsoup, pango
libsoup hace todo lo referente a transporte de red
cairo hace el dibujado mismo de cosas (dibuja una línea, un círculo, una gradiente, etc)
gstreamer son las cañerías multimedia, como algunos sagaces asistentes supondrán esto es para HTML5 principalmente
y pango dibuja fuentes, pero actualmente no se usa por defecto, luego unos datos más de este punto
WebKitGTK+ lo usan ahora mismo Epiphany, Seed, Midori, para mencionar algunos
el port GTK+ tiene otras particularidades muy positivas
principalmente para desarrolladores, como ejemplo les comentaré la experiencia de Epiphany como consumidor de API
desde que firefox es firefox, firefox es el principal usuario del API de gecko
si usan solo firefox eso no es problema
pero si empotran gecko en sus aplicaciones, es un problema
lo que pasó varias veces en epiphany fue que gecko rompía el API a voluntad de firefox, y eso rompía epiphany a cada rato
a veces updates a firefox o xulrunner hacían que epiphany simplemente ya no arranque
evidentemente esto es terrible en cualquier librería o api
en el 2007 se comenzó a explorar el portar epiphany de gecko a webkit
eso lo inició Xan López que es ahora el maintainer de Epiphany
bueno, hasta el 2008 no era muy fácil de usar el port de epiphany a webkit
desde 2008 hasta ahora se ha trabajado mucho en webkit y ya está casi casi a la par con lo q teníamos en epiphany gecko
y precisamente ese es el punto importante de lo q les decía sobre gecko empotrado vs webkit empotrado
en el caso de webkit, todo el desarrollo viene siendo llevado por los principales consumidores del api que son varios y además manteniendo una política de buen api y estabilidad
por ejemplo, el mantenedor de midori es un colaborador activo en webkit y en revisiones de parches y nuevo api
xan por su parte también, e incluso es committer en webkit
esto ha ayudado a tener un api muy bueno
ahora mismo en coruña están reunidos ellos y varios más para el hackfest de WebKitGTK+
http://live.gnome.org/WebKitGtk/Hackfest2009
se está trabajando en regresiones y bugs de webkit y epiphany
http://live.gnome.org/WebKitGtk/Hackfest2009/RegressionBugs
}}}
xapiens
{{{
que es una regresion?
}}}
'''diegoe'''
{{{
una regresión es cuando tu software hace algo y en la siguiente versión luego de algún cambio ya no hace eso o lo hace mal
ha habido una regresión en la funcionalidad
hasta ahora se van haciendo varias cosas interesantes
si están usando una distribución de linux de este trimestre tienen disponible epiphany 2.28 en los repositorios para q prueben
van a ver q hay cosas q no funcionan a comparación de epiphany 2.26 q está hecho con gecko
}}}
dantrix
{{{
pregunta, no debio haber sido un cambio mayor, y colocarlo como 3.0?
}}}
'''diegoe'''
{{{
durante el hackfest se han arreglado por ejemplo los controles para lo elementos , el corrector ortográfico, recordar passwords en formularios en epiphany
y también un beta de los bindings DOM (que ahora explicaremos qué es)
dantrix, no, solo se cambió el backend, el UI y todo lo demás sigue igual o mínimamente cambiado
}}}
dantrix
{{{
gracias
}}}
'''diegoe'''
{{{
en los dos días que quedan de hackfest, deberíamos tener algunas cosas nuevas
mejor performance por ejemplo, si hay suerte una iteración del beta de DOM bindings y un par más de regresiones arregladas
ahora para ir terminando la "teoría", les contaré q son los DOM bindings
si alguna vez hicieron html con javascript habrán tenido que hacer algo como document.getElementById() o algo así
y los elementos que obtenían los cambiaron con cosas como elemento.innerHTML = "hola";
cosas así.
bueno esos elementos son parte del DOM
DOM es documento object model
q basicamente es un árbol de elementos
los elementos tienen propiedades y etc q pueden modificarse
los DOM bindings hacen algo muy interesante, permiten que uno pueda modificar estos elementos programaticamente desde el código C que hacemos para empotrar nuestro webkit
entonces en el callback de un botón en la barra de herramientas de epiphany podríamos hacer que todos los links aumentaran de tamaño, cosas así
pero sin recurrir a javascript, sino directamente en nuestro código C
bueno eso es más o menos una introducción general a WebKitGTK+
alguna pregunta hasta ahora, antes de pasar al ejemplo que previamente hemos cocinado
}}}
''neosergio''
{{{
parece que todo esta claro :)
}}}
'''diegoe'''
{{{
en otras noticias, no le cobraron penal al barcelona.
en fin.
continuemos entonces
}}}
Juanpe
{{{
pregunta?
diegoe: al usar C en ves de js no es un poco mas lento
?
}}}
'''diegoe'''
{{{
al revés
}}}
Juanpe
{{{
porque?
}}}
'''diegoe'''
{{{
javascript es interpretado, C es compilado :-)
en todo caso la diferencia no es perceptible para la mayoría de cosas
}}}
Juanpe
{{{
con C no tienes que subir una capa mas hasta el dom de js aunque tengas los dom bindings?
}}}
vensign
{{{
y se puede utilizar Python?
}}}
Juanpe
{{{
los dom bindings son como un puente nomas
o en algo me estoy confundiendo?
}}}
'''diegoe'''
{{{
tienes el DOM en tu html
con javascript puedes pedir elementos y todo, como haces con jQuery y afines
pero en C, no tienes manera de hacerlo
a menos q escribas javascript y lo ejecutes en tu WebKitWebView con webkit_web_view_execute_script()
entonces mientras que en tu html puedes tener una función que te hace todos los elementos de color fucsia y 20pt de letra
en C no hay forma limpia de hacerlo
}}}
Juanpe
{{{
eso ya lo interpreta webkit no c
}}}
'''diegoe'''
{{{
sí
esa función javascript dentro de tu .html lo interpreta webkit
JavaScriptCore para ser precisos
la idea es que puedas por ejemplo g_object_set (G_OBJECT (elemento), "innerHTML", cadena);
cosas así
como si fuese un objeto cualquiera
vensign, eso también se podría en python
}}}
user001
{{{
me suena a hacer web compilando el codigo... o me equivoco...
}}}
vensign
{{{
ok
}}}
'''diegoe'''
{{{
igual que en python puedes setear propiedades como visible o sensitive, igual
user001, sí, es una aplicación práctica de esto
en el ejemplo se ve precisamente un caso de eso
bueno, el ejemplo lo pueden obtener aquí: http://www.gnome.org/~diegoe/webkitgtk/
son 4 archivos, el Makefile es opcional
pero les ahorrará copiar y pegar una línea
cuando lo descarguen, tendrán q cambiar un #define en monito.c:
#define FILE_START "file:///hom...
la ruta a start.html tiene q ser la ruta actual en sus equipos
disculpen el primitivismo
}}}
''neosergio''
{{{
Nota: Todos los enlaces que han sido puestos durante la charla estan y estaran aqui : http://es.gnome.org/Eventos/CharlasIRC/CharlaDiciembre2009
}}}
'''diegoe'''
{{{
los sagaces habrán notado q este ejemplo es una reedición del que usé en el Encuentro Linux 2009
:)
reciclaje de electrones
a ver, empecemos en main()
en main() encontramos un par de cosas
si nunca han usado GTK+ con GtkBuilder les llamará la atención que no haya código creando ventanas o cosas así
la ventana y sus elementos están todos definidos en encuentro.ui
es un archivo GtkBuilder que pueden abrir con glade3
creo que la charla de pygtk de avaldez cubrió eso
}}}
''neosergio''
{{{
nota: Charla de avaldes - http://es.gnome.org/Eventos/CharlasIRC/CharlaNoviembre2009
}}}
'''diegoe'''
{{{
bien, si ven la línea 148: web_frame = webkit_web_view_get_main_frame (web_view);
web_view = WEBKIT_WEB_VIEW (webkit_web_view_new ());
ahí estamos creando el elemento principal de WebKit: WebKitWebView
si han usado GTK+ antes se preguntarán por qué ese cast a WEBKIT_WEB_VIEW (), lo que pasa es que webkit_web_view_new () devuelve el WebKitWebView como un GtkWidget
esto no se los había comentado aun, WebKitWebView es un widget más
así como un GtkButton
o un GtkWindow
osea que pueden meter un WebKitWebView donde sea que pueden meter un GtkButton o lo q sea
hay una referencia del API más o menos completa en http://webkitgtk.org/reference/index.html
continuando, van a ver que como les decía el WebView es un widget cualquiera:
gtk_container_add (GTK_CONTAINER (scrolled), GTK_WIDGET (web_view));
en ese caso lo empotramos dentro de una ventana con scroll
webkit se comportará como debe y tendrá un scroll operativo y todo, sin hacer mayores trucos
esto es todo el web_view, el objeto más "alto nivel"
luego van a ver q hay un par de creaciones de botones y callbacks conectados
vean por ejemplo
toolbutton = GTK_WIDGET (gtk_builder_get_object (ui, "homebutton"));
g_signal_connect (G_OBJECT (toolbutton), "clicked",
G_CALLBACK (home_clicked_cb), web_view);
si ven el callback de ese botón, que es el callback del botón con el ícono de casita
se hace esto: webkit_web_view_load_uri (web_view, FILE_START);
y eso no es nada más que decirle al web_View que cargue el path FILE_START
osea, el archivo start.html
alguien ya compiló el ejemplo?
o alguien q lo está intentando tiene problemas?
}}}
xapiens
{{{
que es un callback ?
}}}
'''diegoe'''
{{{
xapiens, la función llamada en reacción a un evento
}}}
Juanpe
{{{
diegoe: o/
hay un bug
}}}
'''diegoe'''
{{{
haces click a un botón, y el callback de "clicked" es mi_funcion_especial()
Juanpe, cuál?
}}}
Juanpe
{{{
cuando bajas el zoom lo vuelves a aumentar
el boton se mueve y tapa el texto que tiene detras
}}}
'''diegoe'''
{{{
ah interesante. está para reportar
confirmado.
}}}
Juanpe
{{{
error tuyo o de webkit? :D
}}}
''neosergio''
{{{
:D gnome bugsquad
}}}
'''diegoe'''
{{{
creo que webkit
}}}
Juanpe
{{{
cuando se hace ese zoom
}}}
'''diegoe'''
{{{
sí ya lo reproduje, se queda ahí en medio
encima de las cosas
}}}
Juanpe
{{{
aja
}}}
EGCdigital
{{{
:o
}}}
'''diegoe'''
{{{
ese control de zoom del que juanpe habla es un "slider" (GtkHScale)
tomaré un screenshot para q se haga obvio
}}}
Juanpe
{{{
eso
}}}
user001
{{{
no debería salir todo en fondo negro?
al hacer click?
}}}
Juanpe
{{{
eso si funciona
}}}
'''diegoe'''
{{{
bueno por algún motivo no puedo tomar un screenshot
Juanpe, puedes subir uno?
}}}
Juanpe
{{{
la propieda zoom_level no esta funcionando bien
oki
}}}
user001
{{{
juanpe: ok, ya lo note.
}}}
'''diegoe'''
{{{
bueno, la ventana tiene un control de zoom del cual pueden ver el código en la línea 170
verán que se ponen ciertas propiedades del widget y se conecta la señal value-changed
y el callback zoomscale_value_changed_cb lo único que hace es setear la propiedad "zoom-level" del WebView al nuevo valor del control de zoom
webkit por cierto puede hacer zoom del contenido completo
}}}
Juanpe
{{{
diegoe: http://www.ubuntu-pics.de/bild/34874/selecci__n_001_zeefaG.png
}}}
'''diegoe'''
{{{
no solo del texto como en el ejemplo
de hecho hay una línea comentada q dice: webkit_web_view_set_full_content_zoom (web_view, TRUE);
si le quitan el // van a usar el zoom completo
pero se ve medio mal con las imagenes q estan en el ejemplo
bueno eso es más o menos la descripción del UI. desde el punto de vista de webkit lo destacable está en cómo fue fácil de empotrar
y en cómo cambiar una propiedad del webview fue solo cosa de usar g_object_set, API estándar de cualquier GObject
ahora podemos pasar a la parte de hacer cosas "híbridas" de web y C
hasta aquí alguna pregunta?
(si no han compilado el ejemplo pueden verlo en el screenshot de Juanpe)
}}}
''neosergio''
{{{
nota: screenshot de juan-pe http://www.ubuntu-pics.de/bild/34874/selecci__n_001_zeefaG.png
}}}
'''diegoe'''
{{{
bueno sigamos
hay 2 abusos del API de webkit en este ejemplo
el primero es el abuso de create-plugin-widget
g_signal_connect (G_OBJECT (web_view), "create-plugin-widget",
G_CALLBACK (web_view_create_plugin_widget_cb), NULL);
la señal create-plugin-widget es emite cuando el html tiene un