Re: Concerns about print preview implementation
- From: Alexander Larsson <alexl redhat com>
- To: paolo maggi polito it
- Cc: "gtk-devel-list gnome org" <gtk-devel-list gnome org>
- Subject: Re: Concerns about print preview implementation
- Date: Mon, 15 May 2006 16:29:26 +0200
(replying via cut and paste from archives due to mail loss)
> Hi,
>
> looking at the previous mails about print preview it seems people are
> oriented toward using an external viewer for print previewing.
>
> However we still think this is a bad idea for several reasons.
Interesting viewpoint, and it sure has changed my opinion a bit. I'm not
really sure which model is best atm.
> * 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. I guess there is the process spawning and gtk
init time added, but is that really so slow? One could even argue that
the in-memory approach bloats all users of Gtk, since everything will be
linking in the preview code.
> * As explained many times when evince was created, the evince UI is so neat because it was
> thought with a clear use case in mind: multipages documents in portrait mode. However not all
> gtk apps that do printing are document oriented: think of CAD apps, image editors and probably
> others: is the evince UI well suited for previewing those documents?
In what way to you see the print preview widget ui will be significantly
different from that of evince though? Aren't they gonna be pretty
similar, with next/prev buttons and some way to zoom and scroll around.
> * 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.
> * 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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a maverick playboy master criminal who dotes on his loving old ma. She's
a pregnant hypochondriac widow with someone else's memories. They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]