Re: Concerns about print preview implementation

[Paolo Borelli <pborelli katamail com>]

Alexander Larsson wrote:
> On Mon, 2006-05-15 at 18:44 +0200, Paolo Borelli wrote:
>   
> > > > * 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.
> >     
>
> So, you want an API where you can completely replace the print preview
> widget?
>
>   

Well, saying that I "want" it, is a bit strong :)
We have made many other requests that are more pressing for us... still 
leaving the door open to the application to customize the preview widget 
sounds useful to me in the long run.

> > > >  * 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.
> >     
>
> Still, there is a native dialog around, with all the mainloop vs win32
> mainloop using native dialogs. I guess if we close the print dialog
> when showing the print preview that might be solvable, but as I said
> earlier, is that really the behaviour we want?
>   
I see... I admit I did miss the discussion about this. Does win32 even 
allow to have a preview button in the print dialog? It's been a while 
since I last looked at a print dialog there, but I don't recall sucha a 
button.
Which programs currently show the preview keeping the print dialog open?
As far as I recall win32, OO.o, firefox, kde don't even allow to launch 
the preview from the print dialog, so usually you launch the preview and 
from the preview you launch the print dialog, but you can't do the other 
way around.
gnomeprint programs currently allow to launch the preview from the print 
dialog by emitting a PREVIEW response and as far as I can see all the 
gnome programs close the print dialog.


Paolo