textview virtual function is, or isn't?

[Steven Ashe <steve ashe minolta-qms com>]

Hello.

When is a function in a class' virtual table truly virtual?
Take a look at gtk_text_view_delete_from_cursor.  Here is
a virtual function (actually the default handler for the
"delete_from_cursor" signal) that also functions as
a bona fide C proc.

Consider this scenario: within a textview I wish to treat
groups of characters as a single entity.  Not so strange,
if for instance I was writing a binary-file editor.  The
groups of characters are hex representations of bytes in the
subject file.  Certainly it would be nice if tags could be
used to bind groups of characters that behave as a signal
character, but since they can't, it seems I have two choices:
1) subclass textwidget, and replace the default handlers
for the basic editing functions with ones that handle
our character-groups appropriately, or
2) put a "before" sort of handler on the delete_from_cursor
and other such signals, do things my way, and then stop
the signal.

However, the way gtk_text_view is coded, it appears that neither
will work.  To the naive code reader, it appears that
gtk_text_view_commit_handler calls 
gtk_text_view_delete_from_cursor directly, bypassing the latter's
role as a virtual function and bypassing its role as a signal
handler.  (gtk_text_view_commit_handler is itself a signal
handler that cannot be overridden, but this doesn't seem
particularly relevant to the problem.)

If this is an oversight of some sort, or something that puzzles
someone else, then I will at least be relieved that I'm not the
only one to get muddied tiptoeing through the conceptual
morass of what are true -- and what are ersatz -- signal handlers
and emitters in gtk.  ;-)


-Steve Ashe

PS.  Owen Taylor makes reference in one of
his papers to a pixmap engine that uses
gdk-pixbuf instead of the imlib/pixmap
engine in gtk-engines.  Is this real?