Some fodder for discussion this weekend: 1. Is there a cross-platform printing user interface? Actually, what we are interested in is not the printing user interface per-se, but the points of interaction between the application user interface and the printing user - what are the menu items? What are the places where the application can extend the printing user interface? In terms of menu-items, Windows typically has: Page Setup Print And sometimes "Print Preview". OS X has Page Setup and Print; Preview is a button on the Print dialog. GNOME has Page Setup integrated into Print, though many (most?) apps also have a separate Page Setup which may or may not duplicate stuff from the print dialog. 2. If there is a cross-platform way that "printing works" in terms of menu items, is that really what we want for GNOME? The GNOME integrated page setup dialog does have the advantage that the interaction between selected printer and selected page size is more obvious. 3. What extension points are needed for applications? Windows provides a reasonably extensive amount of print dialog customizability ... you can add pages to it, and you can provide custom variants of certain portions of the main page. What do apps really want to do? Many applications probably will end up writing their own Page Setup dialogs ... there is a lot more variety there than with the print dialog. What hooks do we need to provide to let them do this well? 4. Can we use the native UI? Using the native UI means giving up a certain amount of gtk-ness. You can't use the GtkDialog API for a dialog create with PrintDialogEx on Windows. Instead of widgets, we'd probably have to have objects of some sort with signals for completion, or have a simplified blocking API that just shows a dialog and waits for completion. 5. Can we not use the native UI? If we write our own dialog, then we have to be able go beyond enumerating printers, show printer specific options, possibly with driver-provided UI, etc. It doesn't seem that either windows or OS X has a "API for writing print dialogs" I think trying to avoid the native UI is going to be a lot harder for the print dialog than for the file chooser. For the file chooser, we may be idiosynchratic, but there is a lot of variability anyways (on Windows). For the print dialog, we'll just be non-functional. 6. How do we divide up the objects? There are various "roles" that need to be filled: - Information about the printer - Information about the print job - Document content 7. Is printing callback based or simply procedural? Do you a) provide a callback to draw a page b) just open a document, draw_page/show_page/draw_page/show_page. For a print preview, we need random access, but that could conceivably be implemented with a metafile (as is done in libgnomeprint currently.) We could even provide both - some sort of interface with a signal-based implementation and a meta-file implementation. 8. How do we represent printer information and options? Some options - Paper size - Selected margins and orientation - Color profiles are needed by apps - and we can provide API for them. But do we need some more generic API that allows applications to access any conceivable option that might be set by a printer-specific print-dialog page? Does an app need to be able to access the fact that the user has told the printer to turn on the built-in stapler? To find out the phone number that the user has entered for the FAX driver? Can we consider that stuff to be private and backend specific. 9. What options do we persist? How? Page setup options should be saved with a document. Also, perhaps remembered as "defaults" for the application. Selected printer probably should be remembered across applications. How does the application get the information it needs? As a chunk of XML? As key-value pairs? 10. What, if anything, do we need to do to support non-GUI printing? There are some reasons people might want to print without a print dialog ... a web page that provides you PDFs of a generated spreadsheet, say. Is telling people to use Cairo good enough for that, or do we need to make parts of our printing infrastructure available? Would that imply "printing in GLib", or could we simply allow people to use a printing API in GDK without initializing a display connection? Of course, there aren't just 10 questions.... Owen
Attachment:
signature.asc
Description: This is a digitally signed message part