>> * 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
