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