Older blog entries for lgs (starting at number 11)

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 ...

After the orkut effect this weekend I didn't code too much. Luckily I managed to advance a little bit today.

I needed to see the libgnomecanvas code to see how to generate the marshaler for my first signal: "move-cursor". So changes to configure.in and Makefile.am were mandatory.

All this for what? Well now you can use the arrow keys to navigate through the cells of the grid. No edition so far but at least you can see how the focus changes.

A screenshot is worthy again. See how the cell 3, 2 is the current cell.

3 Feb 2004 (updated 3 Feb 2004 at 11:10 UTC) »

Some more progress: now the grid uses the GtkListStore as its model. We are a little bit closer to the MVC architecture.

Wanna see more screenshots? Well this time nothing is really spectacular but I can tell you is a important step to separate the data from the widget. Ok, the screenshot is here.

Now it's time to paste some code. As an add-on, the GtkGrid API will be pretty similar to the GtkTreeView one, so programmers will not need to learn a lot of different things. Let's see an example of how to use it:

  /* Create the model and populate it */
  for (i=0; i<n_columns; i++)
    types[i] = G_TYPE_STRING;

model = gtk_list_store_newv (n_columns, types);

for (y=0; y<n_rows; y++) { GtkTreeIter iter; gtk_list_store_append (model, &iter); for (x=0; x<n_columns; x++) { GValue value = { 0, }; g_value_init (&value, G_TYPE_STRING); snprintf (buffer, 99, "cell %d %d", y, x); g_value_set_string (&value, buffer); gtk_list_store_set_value (model, &iter, x, &value); } }

/* Create the grid with the model */ grid = GTK_GRID (gtk_grid_new_with_model (model));

for (i=0; i<n_columns; i++) { renderer = gtk_cell_renderer_text_new (); column = gtk_grid_column_new_with_attributes ("testing", renderer, "text", i, NULL); gtk_grid_append_column(grid, column); }

Well, things are going pretty well so far but I guess that's because I'm just biting the edge of the iceberg. The easy parts, in other words.

I have a demo with 10 columns and unlimited rows that use GtkCellRendereText with data created on the fly. You can see it right here

Next step: to use the GtkListStore

Mental note: I need to write some design documents right now because every time someone ask me for the Grid I keep repeating the same boring stuff.

Well, things are going pretty well so far but I guess that's because I'm just biting the edge of the iceberg. The easy parts, in other words.

I have a demo with 10 columns and unlimited rows that use GtkCellRendereText with data created on the fly. You can see it right here

Mental note: I need to write some design documents right now because every time someone ask me for the Grid I keep repeating the same boring stuff.

First steps towards the use of Gtk Renderers. Now I have a GtkGridColumn class pretty similar to GtkTreeViewColumn and it will use renderers.

The demo program is used for testing purposes so far and is going pretty well. I have a toy grid with two columns and two renderers.

For those of you who care about this I set up a subversion repository at

svn://www.sicem.biz/sicem/gtkgrid

Finally it seems that there are people interested in a Grid like acs :)

2 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!