Re: Concerns about print preview implementation

[Paolo Borelli <pborelli katamail com>]

>> * 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.

Yes, that's true. However by using a normal widget the app could always
replace it with a custom or derived widget which provides actions
specific to their kind of document.

>>  * 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 may be missing something here: note that by 'embedded' I mean embedded
in the app, not in the native dialog, so it would be a normal gtk
widget.

>>  * 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.

Well, but evince has additional features and thus a bigger codebase and
it depends on many other libraries like poppler which can introduce bugs
on their own from a version to another.
The external viewer version could be changed (for instance because of a
security update) and introduce a bug with the side effect of breaking
preview in all apps. This kind of thing is less likely to happen for an
internal widget.
Beside testing all combination of external viewers programs and versions
sounds much harder.
In particular I fear that this kind of things along with bad
configurations of the external viewer would generate an increased amount
of bogus bugs filed upstream.


Paolo