Changeset 1750

Show
Ignore:
Timestamp:
03/25/07 15:19:30
Author:
pvanhoof
Message:

Some comments and documentation

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • trunk/libtinymailui-gtk/tny-gtk-header-list-model.c

    r1749 r1750  
    127127        g_static_rec_mutex_lock (list_model->iterator_lock); 
    128128 
    129         i = (gint)iter->user_data; 
     129        i = (gint) iter->user_data; 
    130130 
    131131        if (i < 0 || i >= list_model->items->len) { 
    …… 
    179179        time_t recv_a, recv_b; 
    180180 
     181        /* Get the index out of the iter, and use the item by looking it up in 
     182         * the GPtrArray. This must be quite efficient, as this is called lots 
     183         * of times while you are sorting things. */ 
     184 
    181185        hdr_a = list_model->items->pdata[(gint)a->user_data]; 
    182186        hdr_b = list_model->items->pdata[(gint)b->user_data]; 
    …… 
    207211        time_t recv_a, recv_b; 
    208212 
     213        /* Get the index out of the iter, and use the item by looking it up in 
     214         * the GPtrArray. This must be quite efficient, as this is called lots 
     215         * of times while you are sorting things. */ 
     216 
    209217        hdr_a = list_model->items->pdata[(gint)a->user_data]; 
    210218        hdr_b = list_model->items->pdata[(gint)b->user_data]; 
    …… 
    228236 
    229237        g_static_rec_mutex_lock (list_model->iterator_lock); 
     238 
     239        /* Get the index out of the iter, and use the item by looking it up in 
     240         * the GPtrArray. This must be quite efficient, as this is called lots 
     241         * of times while you are sorting things. */ 
    230242 
    231243        i = (gint) iter->user_data; 
    …… 
    324336        g_static_rec_mutex_lock (list_model->iterator_lock); 
    325337 
     338        /* The next will simply be the current plus one: That's because we are 
     339         * storing the GPtrArray's index in the iters. Simple, efficient. Just 
     340         * always make sure that such an iter doesn't contain an index that 
     341         * can't be part of the GPtrArray instance (would be devastating). */ 
     342 
    326343        newv = ((gint)iter->user_data); 
    327         newv++; 
     344        newv++;  
    328345        iter->user_data = (gpointer) newv; 
    329346 
    …… 
    343360tny_gtk_header_list_model_iter_has_child (GtkTreeModel *self, GtkTreeIter *iter) 
    344361{ 
     362        /* This is a flat list (we don't yet support threaded views anyway), so 
     363         * the answer is flat-out no. Always. */ 
     364 
    345365        return FALSE; 
    346366} 
    …… 
    423443        notify_views_data_t *stuff = data; 
    424444 
     445        /* Caused by the delayer (see below), this one wont trigger for each 
     446         * added item. Let's hope that the GtkTreeView copes with this by  
     447         * reading the get_length property each time. March 2007 it did, as far 
     448         * as I know. */ 
     449 
    425450        gtk_tree_model_row_inserted (GTK_TREE_MODEL (stuff->self), stuff->path, &(stuff->iter)); 
    426451        gtk_tree_path_free (stuff->path); 
    …… 
    431456} 
    432457 
     458/* This will be called often while you are in tny_folder_refresh(_async). It can 
     459 * and will be called from a thread, so we must cope with that in case we want  
     460 * to update the GtkTreeViews that have been attached to this model (self). */ 
    433461static void 
    434462tny_gtk_header_list_model_prepend (TnyList *self, GObject* item) 
    435463{ 
    436464        TnyGtkHeaderListModel *me = (TnyGtkHeaderListModel*)self; 
    437         GtkTreePath *path; 
    438465 
    439466        g_static_rec_mutex_lock (me->iterator_lock); 
    440467 
    441         /* Prepend something to the list */ 
     468        /* Prepend something to the list itself. The get_length will auto update 
     469         * because that one uses GPtrArray's len property. We are reusing the  
     470         * iterator_lock for locking this out, by the way. */ 
     471 
    442472        g_object_ref (G_OBJECT (item)); 
    443473        g_ptr_array_add (me->items, item); 
    444474 
     475        /* This will prepend happen very often, the allocation and the notificating 
     476         * of the view is, however, quite slow. So we delay it per 100 or so. */ 
    445477        if (me->delayer == 100) 
    446478        { 
    447479                notify_views_data_t *stuff; 
     480 
    448481                stuff = g_slice_new (notify_views_data_t); 
    449482                stuff->self = g_object_ref (G_OBJECT (self)); 
    …… 
    453486                stuff->iter.user_data = (gpointer) (me->items->len - 1); 
    454487 
    455                 /* Letting the model observers know about this (the GtkTreeViews). The  
    456                  * g_timeout_add stuff keeps it possible to launch the prepender in a  
    457                  * thread. Else wouldn't the GtkTreeViews like this. */ 
     488                /* Letting the model observers know about this (the GtkTreeViews). 
     489                 * The g_timeout_add stuff keeps it possible to launch the pre- 
     490                 * pender in a thread. Else wouldn't the GtkTreeViews like this. */ 
    458491 
    459492                if (stuff->path) 
    …… 
    463496                        g_slice_free (notify_views_data_t, stuff); 
    464497                } 
     498 
    465499                me->delayer = 0; 
    466500        } 
    …… 
    500534 
    501535 
     536/* TNY TODO: massive removals would be slow due to the g_timeout_add being 
     537 * called often. Take a look at the prepend to see how this can be solved. */ 
    502538static void 
    503539tny_gtk_header_list_model_remove (TnyList *self, GObject* item)