Re: Concerns about print preview implementation

[Paolo Maggi <paolo maggi polito it>]

Hi,
> 
> > * launching an external app could be slow and memory greedy, especially if the viewer 
> > has to render the whole document (which could be big, include images, etc.)
> 
> Why would an external app be slower, greedier, whatever than an
> in-memory approach? They both would do about the same thing, so I'm not
> sure one has to be worse. 

This is not true, they could and should behave in a very different way.
Using the in-memory approach you could render the pages on-demand when
the user want to display them and not the entire document.

There are also two additional steps to count: document serialization and
deserialization.

> I guess there is the process spawning and gtk
> init time added, but is that really so slow?

Well, on my machine evince needs about two seconds to display his
window. 

>  One could even argue that
> the in-memory approach bloats all users of Gtk, since everything will be
> linking in the preview code. 

Well, it is code shared among all the Gtk+ application and if not used
it will be swapped out by the OS after a few time.

> 
> >  * preview embedding: for instance gedit currently embeds the preview in the tab and we are pretty happy
> > with it. Sure, someone may argue that we should not do it, but I don't think that this kind of policy decisions
> > belong in a toolkit. Beside there may be other apps where an embedded preview may make even more sense.
> 
> This does complicate the API a bit though. For instance, I'm not sure
> how easy that would be to do with the win32 native dialogs. 

I don't know Win32 API so I cannot help here, what I can say is that
most windows applications use embedded preview so forcing gtk+ apps to
use an external viewer breaks consistency on Windows. 
I also break consistency with important applications on Linux,
OpenOffice.org and Firefox use embedded preview.

> 
> >  * a bug in evince/$VIEWER would compromise the print preview feature of every gtk+ app
> 
> The same is true for a bug in the print preview widget. And a not
> reusing the evince code probably makes such bugs more common.

This is true, but it is clearly easier to manage from a maintainability
point of view, since you don't have dependency on an external app.
We don't know which external viewer the user is running.

Ciao,
Paolo