porting issues

[Allin Cottrell <cottrell wfu edu>]

I'm in the process of porting a fairly substantial app from gtk 1.2 to
gtk 2.0.  It's proving to be a non-trivial operation.  The main issues
so far relate to the replacement of gtk_text functions with
gtk_text_view/text_buffer ones.  I can see that the new setup allows
for much greater flexibility, but it does so at a cost of much greater
complexity.  Those of us whose apps do not involve split-screen
editing (so that every text_view is associated with just one
text_buffer and vice versa) find ourselves having to jump through a
large number of hoops to reconstitute basic text display and editing
functionality.

Anyway, while working on the gtk_text stuff I'm looking over my
shoulder at the clist stuff.  My 1.2 clist code still works fine, so
long as I don't try to compile with GTK_DISABLE_DEPRECATED defined.
Just how strong is the "deprecation" here?  I see that the new model
for lists is similar to that for text, with a separation of the viewer
mechanism from the object viewed and an extra layer of abstraction.
Once again, those (such as myself) whose apps don't require this
separation (i.e. we're not writing split-pane file managers) will
have to manage much greater complexity to get the same functionality.
In the clist case, a first inspection of the reference docs suggests
that a rigorous port will be quite nightmarish.  I just hate to think
what I'm going to have to do to replicate, e.g.,

static void set_extra_var (gint i, selector *sr)
{
    gchar *vnum, *vname;

    gtk_clist_get_text(GTK_CLIST(sr->varlist), i, 0, &vnum);
    gtk_clist_get_text(GTK_CLIST(sr->varlist), i, 1, &vname);
    ...
}

At this point I'm wondering what other developer-users of GTK are
thinking, and whether there's a case for providing a "helper" layer
that replicates (more or less) the functionality of gtk_clist (and
maybe even gtk_text, modulo utf-8 issues).  That is, "if you don't
need to make a distinction between viewer and object viewed, then..."
use the helper functions.  I find that I'm writing things of this sort
for my own use, e.g.,

gchar *textview_get_full_text (GtkTextView *view)
{
    GtkTextBuffer *tbuf;
    GtkTextIter start, end;

    tbuf = gtk_text_view_get_buffer(view);
    gtk_text_buffer_get_start_iter(tbuf, &start);
    gtk_text_buffer_get_end_iter(tbuf, &end);

    return gtk_text_buffer_get_text(tbuf, &start, &end, FALSE);
}

to replace what previously would have been one gtk function call.
But I'm not in the best position to ensure that my own helpers of this
sort are optimized or foolproof.

I guess my bottom line at the moment is that if "deprecated" means
that the plug will be pulled on gtk_clist in the not-far-distant
future, then I'm not a happy camper. I wonder whether the complexity
of gtk 2.0 isn't raising the bar too high for non-professional
developers of free software such as myself.  It seems a bit ironic
that while gnome2 and sawfish2 et al are busy discarding "excess"
complexity (perhaps a bit over-zealously) on the grounds that users
can't handle it, gtk2 is seriously upping the ante for would-be
programmers.

Allin Cottrell.