Re: printing

On Thu, 2006-02-16 at 09:37 -0600, Bob Caryl wrote:
> viewcvs doesn't list libgnomeprintuimm,

It's in gnomemm:

>  so I cannot link to that.  
> However, the situation to which I allude above is with
> Gnome::Print::UI::PrintDialog::run();
> In the file "printdialog.h" in the libgnomeprintuimm library I 
> downloaded (version 2.5.2), the run method  is listed in the class 
> declaration but it is commented out.   The method  as it appears (also 
> commented out) in is shown below:
> /*
> int PrintDialog::run()
> {
>     gnome_print_dialog_run(gobj());
> }
> */

This is just some old commented-out code - I've removed it now to
prevent confusion. It is actually implemented if you search further
(generated by a WRAP_METHOD() call in the .hg file). It doesn't do
anything interesting compared to Gtk::Dialog::run() anyway.

> As you can see, the function prototype specifies a return value, but the 
> function returns nothing.  Because the method wrapper is commented out, 
> and since the class is derived from Gtk::Dialog I made the assumption 
> that the run method would return something meaningful, but as I said in 
> my previous message, it does not seem to do that.

Are you talking about the result of a test, or just what you thought the
source code did?

>   My perusal of the 
> gedit source code indicated that a callback function was connected to 
> the print dialog object to handle the different button presses in the 
> dialog.

In general, people seem to prefer to avoid Gtk::Dialog::run() because it
forces the dialog to be modal, which some people don't like, so they
handle the button presses asynchronously like this. But I doubt it's
worth the bother in most cases so I recommend starting simple.

>   I am guessing that this is probably what should have been done 
> in the wrapped version of the dialog since the buttons displayed by the 
> print dialog are "PRINT PREVIEW", "PRINT", and  "CANCEL". 
> Gnome::Print::UI::PrintDialog::run  returns the same value regardless of 
> which of those buttons are pushed.

It seems to return different values for each button in the example. The
possible values are:

I will wrap that enum in cvs. I have already added tests for the
response value in the example.

> >We are all waiting for the perfect cairo-based printing API to arrive in
> >a future version of GTK+.
> >  
> >
> Is there any forecast about when the new cairo-based printing API will 
> arrive?

Maybe in GTK+ 2.10, which should be stable within 6 months:

People are working on it (see gtk-devel-list), and it looks like they
will succeed. It's a difficult job because it needs to be suitable for
Windows and Mac as well as Linux.

Murray Cumming
murrayc murrayc com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]