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