Older blog entries for lgs (starting at number 16)

Decent gcubogotchi

This weekend I did some icons for my friends just to include them on Evolution contacts and I also made a decent one for myself

There is also another version of the whole body

/gnome stuff

Finally I realized that the easiest way to get the last piece of bit of every program I usually need is to install them all in a alternate prefix, like /gnome. And forget about your distro packages and dependencies. Yes, we all know apt and yum are great but then you go back to use jhbuild or garnome to get the last gnome build. What if you want other programs (e.g. Gaim) integrated with it?

After quite a while without posting I come back again thanks to the preasure somebody is doing these days.

Let's start with something simple: small hack to display a rotated pango text. I just copied the idea from pygtk mailing list but I didn't want to wait until I have my widgets realized to draw the rotated label.

So here you have the code and a small demonstration of the concept.

Thanks to jamesh for his nice explanation about colors, visuals, depth, and all those internal X concepts we all love.

Después de casi un mes sin escribir nada por aqui vuelvo a hacerlo y esta vez en mi idioma natural.

Y la razón es que entre el montón de spam que me llega todos los días al buzón de correo ayer me llegó un mensaje muy especial. Es sobre una persona que ha leido mi traducción del tutorial de Pygtk y me ha mandado correcciones y sugerencias.

Pero no sólo eso, también acaba su correo con este párrafo:

Tu traduccion esta siendo usada en el Seminario de
Programacion Multiplataforma del GrupoLInux
de la Universidad Distrital (Bogota, Colombia)

Gracias por este gran trabajo con el cual hemos podido aprender acerca pygtk en nuestra lengua materna, documento que al ser libre nos ha permitido un facil acceso a esta tecnologia, sin ningun precio, y que ademas ayuda a un pais con graves problemas como Colombia a que salga de su atraso en las cuestiones de la informatica.

Cosas como están son las que te dan ánimos para seguir trabajando día a día.

14 Apr 2004 (updated 14 Apr 2004 at 16:37 UTC) »

Well, yesterday was a really good day indeed. Federico and Jonathan are interested in GtkGrid and this is more than I could dream about.

Federico even told me that they are considering it for being in GTK+ 2.6:

<federico> estoy platicando con jrb acerca de gtkgrid :)
<federico> hay planes para ponerlo en gtk+ 2.6 si esta listo para esas fechas
<federico> entonces si tienes preguntas, no dudes en consultarme

Then I asked what need to be done for this milestone. They kindly answered me so now I have these short time goals:

  • Write a desing document explaining what the Grid is and what it is not.
  • Complete the API for the Grid
  • Write some documentation for the API itself and some sort tutorial with examples.
  • Ask gnome-db guys to make a branch and let me put my hands on Mergeant to see how good the Grid is in a real project

As you can see there is a *lot* of work to do so any help is more than appreciated.

In the meantime Jonathan is helping me to get a combo renderer working in the TreeView (and I'm copying ideas to make it work on the Grid) and we are close to get it. :-)

Compilation headaches

After some days working in other stuff I came back to work with GtkGrid. I even got a patch from Todd Fisher for displaying the row number in the sidebar!

So today was the compilation win32 day. I got some problems building pygtk in win32 for Python 2.3 but after some googling I discovered how to fix it. More info here. So no Visual Studio C was needed, thanks heaven.

After that and some changes to my lgsbuild.py script because I updated all the versions of our software dependencies I run into another problem with pygtk.

I got some undefined references when compiling pygtk and I asked to the pygtk list about this issue. I should have googled this time too as kiko showed to me :)

In the meanwhile Johan et al are working harder and harder and we are having releases very fast. So I guess my compilation nightmares have just started .... :)

At least we have new versions of GtkGrid and pyGrid (python bindings), this time for Python 2.3. CHeck them out here !!.

Today was a gtkgrid full time day and I did some fancy stuff. This is a list of current improvements:

  • There is a header window now with a button in every column. The label of the button is the title of the column.
  • Columns have variable width to acomodate their model contents and also the title text.
  • We also have a sidebar with a small right arrow pointing to the current row. This would be a good place to check for right click buttons to pop up a menu for adding and removing rows.
  • I fixed an anoying bug with the CellRendererSpin. When the user clicked too fast on the spin arrows the focus came back to the grid. All I needed to do was to check if the button event window field was the correct one.
  • Thanks to Owen now I know how to draw with the color I want. I used this knowledge to draw a blue rectangle on the current cell.

Wanna see al this changes together? Well, here you have an screenshot

But not everything are good news. The scroll is broken now after so many changes. I'll need to understand better how the gdk_window_move and gdk_window_scroll works.

After some days I managed to have some time to keep hacking on the grid. Before this I had some issues about the renderers and still I can't make the Combo and Spin Button editors work without problems.

At least today I added a cool feature: you can now have columns with different width. Right now the width for every column is computed when the model is set. It is the maximum with of all of its cells.

Now, I just need to put the header and sidebar and I'll be happy for one more week. So if I can do it tomorrow, we will have 0.0.2 very soon.

Somebody told me Python is an easy language and it's fun to program with it. Very true. But what about Python development? Specifically Python bindings development? Well, it's a nightmare, I can tell you.

After having my first GtkGrid version released yesterday (0.0.1) I decided to make the Python bindings today. It began very good: I understood pretty well how the h2def.py, override files and python-codegen.py works all together to create a Python C module.

But then problems started to arrive in no particular order. First my gtkgrid module didn't get imported properly and I got an undefined reference to a function codegen was putting on grid.c. After asking to gjc he told me it was probably a bug in codegen. So I filled a bug report in bugzilla and to my surprise gjc had a patch 20 minutes later!! This is user support and not what some big companies claim they do. I applied the patch and everything worked smoothly. :)

So next step was to show my cute small binding to the world but proper autotools stuff was needed for that because I was using a hard coded Makefile to build the module. And this is where the second part of the nightmare began.

I looked at the diacanvas2 Makefile.am/configure.in files. I looked at the pygtk Makefile.am/configure.in files and I copied everything pretty literal but it didn't work. I copied the pygtk autogen.sh file and some m4 macros and got some errors fixed, but still didn't work. After more than 2 hours reading autotools documentation and trying different aproaches I go really frustrated. I was also a little bit tired.

Then I give distutils a try and can you believe it? In less than 5 minutes I got it working. So after a whole day my conclusions are:

  • pygtk developers are really nice guys that will help you
  • autotools are a nightmare only designed to make your head explode
  • Python tools are nice and you should use them and avoid using C tools for things different than C.

Well, let's see if somebody gets interested in the (in)famous Grid

After several days I managed to have the scrolling working not without some pain. You know, expose areas are evil specially if you assume things you shouldn't...

GtkTreeView scroll is different for vertical and horizontal directions. I still don't know why this inconsistency but I decided to do both directions identical. The main reason is code readability. I'm a Python programmer so you can guess speed is not my top priority...

Next thing in mind is to support mouse clicks to change the current cell.

11 Feb 2004 (updated 13 Feb 2004 at 09:49 UTC) »

Things are getting complicated...

First the Allocate nightmare. When the user enters into a cell I call gtk_cell_renderer_start_editing and it gives me a brand new GtkCellEditable widget. Then I put it on the Grid by calling gtk_size_allocate but it is not shown properly and I can't give it the focus. Thanks to Owen who iluminated me and told me that only inside the gtk_size_allocate of the Grid it is legal to call gtk_size_allocate on the children of the grid. Yes, the GtkCellEditable widget must be a child of the Grid. First problem solved :) . You can see how nice are the GTK+ Gurus by reading this piece of IRC chat:

<lgs> is it legal to call gtk_widget_size_allocate without calling gtk_widget_size_request if we don't care about our children wishes?
<owen> lgs: No. A) The only time a custom widget is allowed to call gtk_widget_size_allocate() is in it's gtk_widget_size_allocate() handler
<owen> B) A widget must call size_request() on all children in it's size_request() handler, even if it ignores the result
<lgs> owen, what if I add a child after the size_request of the parent has been called
<owen> Actually also A') A custom widget must call gtk_widget_size_allocate() on all its children in it's size_allocate() handler
<lgs> owen, what's the equivalent to gtk_widget_queue_draw, for size issues?
<owen> lgs: When you add a child, GTK+ automatically queues a resize, so you'll
get a size_allocate()
<owen> lgs: gtk_widget_queue_resize()
<lgs> how gtk+ knows that I added a child? when I call gtk_widget_set_parent?
<owen> lgs: Yeah
<lgs> cool, thanks a lot owen
<lgs> that makes me understand a little bit more of the gtktreeview.c code

After some time playing with the key bindings of the Grid I realized that what I needed to do is to listen for key presses in the GtkCellEditable and move the focus that way. So I got moving left and right of my grid and it worked.

But moving up and down didn't work because strangely I wasn't getting up and down key press. I dived into the GtkEntry code and I discovered why: when calling gtk_cell_editable_start_editing it connect a signal handler to the key press event and check if the user press these arrows to do something special. Solution: noo to call gtk_cell_editable_start_editing. Second problem solved :)

But best of all, while I'm writing these lines people in the #gnome-hispano channel (setepo and apg) are fixing bugs and giving me suggestions (Devin). I feel the power of free software ...

7 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!