Re: Problem with preview and the blocking print dialog
On Thu, 2006-05-11 at 14:35 -0400, Jody Goldberg wrote: On Wed, May 10, 2006 at 04:51:48PM -0500, Federico Mena Quintero wrote: On Wed, 2006-05-10 at 17:42 -0400, John (J5) Palmieri wrote: I'm implementing the preview code in gtkprint. I have decided to use an external helper (default is evince) to do print preview. The idea was to write out to a pdf in /tmp and launch the external helper when the user hits the preview button. ignorant Why do we have an external helper? Gnome-print would save everything to its own internal metafile, and then it would spit it to a gnome-canvas. Could we make Cairo just render everything to a preview window? /ignorant This was a performance nightmare in libgnomeprint because it would queue up the entire document in a metafile which could easily reach into the hundreds of megs. The new code is a huge improvement in supporting per page rendering. If that can avoid the overhead then there are benefits to inline rendereing. Some of the new features Lutz added to gnomeprintui such as drag-n-drop page reordering and subsetting are not really feasible with an external I guess not having to render the whole document is a distinct advantage of the in-process preview. What does subsetting mean? Just changing the page ranges from the preview window? That sounds useful. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a lonely skateboarding paranormal investigator in a wheelchair. She's a violent thirtysomething politician from out of town. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
On Wed, 10 May 2006, John (J5) Palmieri wrote: I'm implementing the preview code in gtkprint. I have decided to use an external helper (default is evince) to do print preview. The idea was to write out to a pdf in /tmp and launch the external helper when the user hits the preview button. The print dialog would stick around even after the preview button was pressed. The issue with the blocking dialog is that, while we can keep the dialog from going away, the way the code is structured right now we would have to wait until the preview was done before reattaching to gtk_dialog_run. This leaves a gap where the user can hit a button on the dialog and nothing will happen. Do we want to allow the user to actually change anything while generating the preview? That strikes me as a bit tricky. Do you expect the generated preview to contain that change or not? There are a couple of solutions as I see them: 1) We could gray out the dialog while the preview is being generated A simple way to do this would be to add a progress dialog for the preview generation and make that modal to the printer dialog. 2) Restructure _gtk_print_operation_platform_backend_run_dialog so that we setup the print before we return instead of it happening in the calling function. Exactly what do you mean by this? 3) Move to a completely async dialog This is not possible at all on Win32. How do you propose print preview to work on win32 btw? We can't launch evince there, can we? Also, is the preview stuff just gonna be a feature of the print dialog, or will it be availible in the API. (So you can add a print preview menu item to your app if you want.) With 1 we need to figure out a way to reenter _gtk_print_operation_platform_backend_run_dialog without cleaning up or reinitializing data. With 2 we end up possibly duplicating code across platforms Not having looked at this in detail, can we not pass the print_pages function into _gtk_print_operation_platform_backend_run_dialog, like we do in the async case. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a maverick Republican master criminal on the run. She's a mistrustful impetuous cab driver with a birthmark shaped like Liberty's torch. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
On Wed, 2006-05-10 at 16:51 -0500, Federico Mena Quintero wrote: On Wed, 2006-05-10 at 17:42 -0400, John (J5) Palmieri wrote: I'm implementing the preview code in gtkprint. I have decided to use an external helper (default is evince) to do print preview. The idea was to write out to a pdf in /tmp and launch the external helper when the user hits the preview button. ignorant Why do we have an external helper? Gnome-print would save everything to its own internal metafile, and then it would spit it to a gnome-canvas. Could we make Cairo just render everything to a preview window? /ignorant So, I think everyone agrees on this approach: 1) run the print loop on a cairo surface producing a metafile of some form 2) display the metafile in a window which allows you to flip between pages, zoom in/out, etc. Now, the metafile format could be some special cairo format, or it could equally well be PDF. It would have to be written to a file anyway, for scalability reasons we don't want to keep it in memory. I think the best way to do this is to rely on an external helper. For a couple of reasons: * Running something as complicated as a document viewer in the same process as the application scares me for stability reasons. Its easy for a bug in the viewer to bring the whole app down, or to affect it badly. * Writing a good viewer is hard. Its not just about rendering the metafile to a window and adding next/prev buttons. The people working on evince have learnt this, and they have created a very nice viewer. This would just be a massive amount of duplicative work. * Using pdf for the metafile format gives a slightly better chance of the preview being accurate, given that this uses most of the actual real printing codepaths. On unix we could use evince (or another pdf viewer of your choice), on OSX we could use preview.app, and on Windows we could generate a .emf file (easy with cairo) and use the emf viewer that ships with windows. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an oversexed devious cop with a winning smile and a way with the ladies. She's a wealthy wisecracking schoolgirl with a birthmark shaped like Liberty's torch. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
Alexander Larsson wrote: I think the best way to do this is to rely on an external helper. For a couple of reasons: * Running something as complicated as a document viewer in the same process as the application scares me for stability reasons. Its easy for a bug in the viewer to bring the whole app down, or to affect it badly. * Writing a good viewer is hard. Its not just about rendering the metafile to a window and adding next/prev buttons. The people working on evince have learnt this, and they have created a very nice viewer. This would just be a massive amount of duplicative work. But who needs a good viewer? Doesn't preview in gnomeprint work well enough? Preview is needed to get the user the idea of what he will have on paper (like will content fit on the page or he needs to change margins, or something), but it doesn't have to be of super good quality. Regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
On 5/11/06, Alexander Larsson [EMAIL PROTECTED] wrote: On unix we could use evince (or another pdf viewer of your choice), on OSX we could use preview.app, and on Windows we could generate a .emf file (easy with cairo) and use the emf viewer that ships with windows. So what happens if you try to get a print preview in evince? :) -- Travis Watkins http://www.realistanew.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
On Thu, 2006-05-11 at 12:29 -0500, Travis Watkins wrote: On 5/11/06, Alexander Larsson [EMAIL PROTECTED] wrote: On unix we could use evince (or another pdf viewer of your choice), on OSX we could use preview.app, and on Windows we could generate a .emf file (easy with cairo) and use the emf viewer that ships with windows. So what happens if you try to get a print preview in evince? :) I would like to point out that OSX uses preview.app for this, and you can, in fact, run print preview recursively. We can do better, but we are going to prolly want a special evince mode to handle this anyway. Thanks, -Jonathan signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Problem with preview and the blocking print dialog
I'm implementing the preview code in gtkprint. I have decided to use an external helper (default is evince) to do print preview. The idea was to write out to a pdf in /tmp and launch the external helper when the user hits the preview button. The print dialog would stick around even after the preview button was pressed. The issue with the blocking dialog is that, while we can keep the dialog from going away, the way the code is structured right now we would have to wait until the preview was done before reattaching to gtk_dialog_run. This leaves a gap where the user can hit a button on the dialog and nothing will happen. There are a couple of solutions as I see them: 1) We could gray out the dialog while the preview is being generated 2) Restructure _gtk_print_operation_platform_backend_run_dialog so that we setup the print before we return instead of it happening in the calling function. 3) Move to a completely async dialog With 1 we need to figure out a way to reenter _gtk_print_operation_platform_backend_run_dialog without cleaning up or reinitializing data. With 2 we end up possibly duplicating code across platforms Is 3 plausible on Windows and Mac? I sort of like 3 since it simplifies some things by having 1 API for sync/async in that we could restrict input to the calling window even if the underlying code is async. As it is now I can generate a preview by simply having the dialog dismissed. I am going to post that patch sometime tomorrow so you can get a better idea of what I am talking about. -- John (J5) Palmieri [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
On Wed, 2006-05-10 at 17:42 -0400, John (J5) Palmieri wrote: I'm implementing the preview code in gtkprint. I have decided to use an external helper (default is evince) to do print preview. The idea was to write out to a pdf in /tmp and launch the external helper when the user hits the preview button. ignorant Why do we have an external helper? Gnome-print would save everything to its own internal metafile, and then it would spit it to a gnome-canvas. Could we make Cairo just render everything to a preview window? /ignorant Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
John (J5) Palmieri wrote: This was my original thought but Matthias and others suggested this. One of the issues with cairo is that we would have to either run through the drawing commands on every expose event or save out to a bitmaps surface which would remove the ability to zoom. The other option is to recreate evince in gtk+. That is not going to happen. One issue is that there's a good chance evince won't be installed on win32 or OS X. I'm a bit unclear on what you're doing though. I'd have thought there'd be a preview widget that would need to handle expose events and render as appropriate. As far as the question about about print dialog modality, the win32 dialog api is designed to block until the dialog is closed. It might be possible to work around this using threads, but it would be ugly. I'm not entirely clear on why the helper app needs to be closed before the dialog is closed, though. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
On Wed, 2006-05-10 at 18:56 -0400, John Ehresman wrote: John (J5) Palmieri wrote: This was my original thought but Matthias and others suggested this. One of the issues with cairo is that we would have to either run through the drawing commands on every expose event or save out to a bitmaps surface which would remove the ability to zoom. The other option is to recreate evince in gtk+. That is not going to happen. One issue is that there's a good chance evince won't be installed on win32 or OS X. I'm a bit unclear on what you're doing though. I'd have thought there'd be a preview widget that would need to handle expose events and render as appropriate. win32 and OS X use their own dialogs. I haven't yet looked at the issue of enabling previews there. As far as the question about about print dialog modality, the win32 dialog api is designed to block until the dialog is closed. It might be possible to work around this using threads, but it would be ugly. Eak, ugly :-) I'm not entirely clear on why the helper app needs to be closed before the dialog is closed, though. No it doesn't. The dialog just needs to stick around even after we run the helper app. -- John (J5) Palmieri [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
This was my original thought but Matthias and others suggested this. One of the issues with cairo is that we would have to either run through the drawing commands on every expose event or save out to a bitmaps surface which would remove the ability to zoom. The other option is to recreate evince in gtk+. That is not going to happen. Or convince Carl to make the meta surface a public API before 1.2 hits the streets, and make whatever improvements are necessary for that to happen. That's essentially what GnomePrint does, anyway. Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
On Wed, 2006-05-10 at 19:37 -0400, Dominic Lachowicz wrote: This was my original thought but Matthias and others suggested this. One of the issues with cairo is that we would have to either run through the drawing commands on every expose event or save out to a bitmaps surface which would remove the ability to zoom. The other option is to recreate evince in gtk+. That is not going to happen. Or convince Carl to make the meta surface a public API before 1.2 hits the streets, and make whatever improvements are necessary for that to happen. That's essentially what GnomePrint does, anyway. Carl says this is not going to happen but if I understand him correctly the pdf or ps surface preserves the cairo_meta_surface_t and can be used as a source for painting. -- John (J5) Palmieri [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
