Gtksourceview needs to be ported to the new printing API introduced in GTK+ 2.9/2.10. Here's a short summarization of the discussion that have been taken place in private mails:

<<Yevgen Muntyan>>
No, I didn't do anything about it in GtkSourceView. I do have printing
implemented (even with preview!), but I didn't try to do something in
GtkSourceView since it'd require lot of chat about api and stuff: e.g.
Paolo Borelli didn't seem to like idea of subclassing GtkPrintOperation,
while I don't understand why not subclass if you can subclass :)

So, if someone is interested, my printing is here:
http://mooedit.sourceforge.net/hg/moo/?f=-1;file=moo/mooedit/mootextprint.h
http://mooedit.sourceforge.net/hg/moo/?f=-1;file=moo/mooedit/mootextprint.c
http://mooedit.sourceforge.net/hg/moo/?f=-1;file=moo/mooedit/mooprintpreview.h
http://mooedit.sourceforge.net/hg/moo/?f=-1;file=moo/mooedit/mooprintpreview.c

But I don't have any plans about it in GtkSourceView, given that we can't
sort styles stuff out :)

<<Sayamindu Dasgupta>>
I looked through the code, and there seems to be two possible ways to
implement what we want:
1. As Yevgen suggests - we can subclass GtkPrintOperation.
2. We can follow the current implementation and finally instead of
providing the result at a GnomePrintJob object, we can return a
GtkPrintOperation object. In such an approach, the API can be kept
mostly the same - and users can use gtk_print_operation_run() to do
the printing/preview.

I can quickly do a rough implementation of approach 2 if you want.

<<Yevgen Muntyan>>
If you are going to return a GtkPrintOperation object, then you are
going to subclass GtkPrintOperation, since you need to store settings
somewhere, and that somewhere is the object.
Subclassing vs not subclassing does not affect anything but whether
you connect callbacks or implement virtual methods.
There is a funny bug, by the way, which probably can make one want
to connect callbacks instead of subclassing:
http://bugzilla.gnome.org/show_bug.cgi?id=345345

<<Paolo Borelli>>
Well, I didn't exactly say that subclassing is a bad idea and that it
should have been done differently... I just raised the question if
alternatives to subclassing were considered at all and if they could be
a better choice.

The reason why at a *quick* and *superficial* look (since I haven't
really used GtkPrint yet) I have the impression that subclassing may not
be ideal are the following:

- as far as I understand GtkPrintOperation works this way: you create
one and then implement (either connecting to signals or overriding the
vfuncs) the ::draw_page, ::paginate, etc methods. If GtkSourceView
implements those, why would the calling code (gedit, medit, etc) need to
see those signals? Is there any use in using a GtkSourcePrintOperation
and then overriding them? At that point one should use GtkPrintOperation
directly.

- GtkPrintOperation API is weird, maybe by wrapping in an object instead
of subclassing we can hide some of the suckiness. E.g. if gtksourceview
provides async (idle-based) pagination, preview etc we can hide the sync
version of the API and make the async version something more similar to
what gtksourceview has now.


Let me state it again: I am not opposed to subclassing, I just asked
myself the above questions when the subclassing solution was showed to
me. It may well turn out that subclassing is the best way forward.

<<Sayamindu Dasgupta>>
There's already a patch by J5 to port Gedit and gtksourceview to the new API - http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00268.html