This is a really nice write up, Alex! I'm replying to selected parts. On Wed, 2006-01-18 at 20:07 +0100, Alexander Larsson wrote: > (cc:ing some people who I think might be interested in this) > > I've just started looking at doing a printing dialog for Gtk+ > 2.10. For some background thoughts from owen, see: > http://mail.gnome.org/archives/gtk-devel-list/2005-October/msg00024.html > > I've started studying various platform APIs and UIs, cups, PPDs, etc, > preparing for this. To compare various platform and application > printing dialogs I have put together a set of screenshots from > Linux/OSX/Windows at: > http://people.redhat.com/alexl/print_dialogs/ This is a great comparison. > One important question that owen brough up is the "Can we/can we not > use the native UI?". If we go with native dialogs we loose a certain > amount of customizability, we get a bit more non-standard APIs > (i.e. we're unable to use GtkDialog derived objects), and we're a bit > limited in what the dialogs can do (least-common denominator of > features, although we might be able to do better with some work). > > My opinion is that we should go with native dialogs. Printing dialogs > are already confusing enough that having to learn a totally new one is > a pain, and its probably gonna be very hard to make a print dialog > that works right on Windows, because I don't think all the required > APIs are availible. Furthermore, you'd loose driver-specific additions > to the printer dialogs that are availible in Windows/OSX. At the Boston summit, we came to the opposite conclusion. We looked at a random windows installation, and it seemed like every application had a different print dialog. Even on OS/X, there was a lot of variety. If we did go with the 'native' dialog, it wasn't empirically clear which native dialog that would be. It may be easier anyway to use it, but consistency is a bad argument here. The driver-specific options is a better argument for that, though. > I've been talking to the Tor on Win32 and Andersca on OSX, and both > think it should be possible (but not tested yet) to embedd gtk+ > widgets into a native dialog, so if we're lucky we can allow some > generic way of adding custom widgets to the dialog. (Given the APIs on > OSX and Win32 this will likely be in the form of an extra tab page.) > If there is some simple common feature we want to support that is > missing on a particular platform we could customize the native dialog > from gtk itself so that all gtk apps would use the same ui for it, and > its availible on all platforms. > It might be wise to allow some amount of access to the > platform-specific objects so that advanced applications can do more > advanced customization using #ifdef. Sounds very reasonable > The print dialog implementation has two parts. First the generic > portable API with implementations for the platform native dialogs, > then the "native" dialog for Unix. In order to support the "Using the > Gtk+ dialog as a native print dialog" use-case we probably need to > expose this as a platform-specific api, with accessors similar to the > ones we have for accessing e.g. the win32 print dialog object. So typical code would be something like: #ifdef WIN32 dialog = gtk_win32_print_dialog_new (); if (gtk_win32_print_dialog_run (dialog) == GTK_RESPONSE_OK) ...; #else dialog = gtk_print_dialog_new(); if (gtk_dialog_run (dialog) == GTK_RESPONSE_OK) ...; #endif Would we expect all the various gtk_print_dialog_* functions to be available? For the native functions, or will every app running on Win32 have to special case printing? > I think we should have a Page Setup dialog, supporting the native > dialogs of the platforms. While using the native dialog here is less > important, since it does less "magic" than the print dialog, and there > is already a considerable amount of variation in this dialog I think > its important that at least simple print applications look "normal" on > the platform. Agreed. <snip> > I think the general print model should go something like: > * create a print job > * set settings on it (page settings etc) > * call the print method, bringing up the print dialog > * user sets options in dialog, presses print > * internally we get the underlying native object to print to (hDC, > NSView, cups printer + PPD) > * internally we create a cairo context for the native object and > pass it to the app > * the app draws stuff to the cairo context, possibly using some > furter information from the print dialog result > > The last drawing part can be done in several ways. Either procedurally > (just draw all the pages in order), or with some form of callback > driven system. The callbacks could either always be called in page > incremental order, or it could be random access given a page number as > argument. I think the callback driven, random access model is the > best. It allows us to handle things like "nr of copies" and collation > perfectly invisible from the app. It does put some higher demands on > simpler applications, i.e. you have to do pagination fully up-front, > but in almost all cases you want to do that anyway (e.g. to have "page > nr x of X" headers) so I don't think that is a problem. > > Having a random access model allows us to easily do inline > mini-previews if we want to, which is nice. We probably should also > have a well defined API for "full size" print preview. This could > launch a document viewer (evince?) like OSX does, or use a normal > in-app dialog, in fact it could do different things on different > platforms. At the summit, we thought evince would be perfect for this. There are patches floating around to make evince compile on Windows, so we could even distribute it there. For OS/X, we could (of course) use preview itself. The one problem with this approach, is that the 'Preview' button requires you to generate the full document before sending it out to evince. This is obviously going to be slower (and sometimes, much slower) than previewing individual pages on the fly. Also, there's the danger of introducing drawing errors in the flow of: App -> cairo -> pdf -> pdf parser (poppler) -> cairo -> screen That being said, we want a good pdf library anyway, so we shouldn't hold off on this for that reason. Thanks, -Jonathan
Attachment:
signature.asc
Description: This is a digitally signed message part