[106] in Athena User Interface
RFC: New Athena printing UIs
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Mon Jun 5 04:54:57 2000
Message-Id: <200006050854.EAA22012@No-Whammies.mit.edu>
To: aui@MIT.EDU
Date: Mon, 05 Jun 2000 04:54:52 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
Someone please let me know if there are printer people I should bug
about this who aren't on this list.
* PRINTING *
There is an existing GNOME applet that supports drag-and-drop
printing, which I think we should put on the desktop by default. You
can check it out on the default panel under Applets -> Utility ->
Printer Applet.
We would need to modify the print applet to correctly detect the
current host's default printer and display this each time the user
logs in (and on a per-host basis).
We would also need to create a modified configuration page that might
look something like this:
=========================================
Current printer: ajax
Change printer to: (pulldown)
[Add printer to list]
[Delete printer from list]
[Reset to default list]
Print method:
(X) Built in
( ) Print header pages for each job
(X) Enable Zephyr notification
( ) Use custom command: _____________
=========================================
ASCII Legend:
[buttons]
( ) Check boxes
(other GUI objects)
Fill-in field: ___________
=========================================
We would be deliberately not be supporting multiple copies and e-mail
notification, among the many other flags for lpr, which is what would
presumably be behind the "built-in" command.
Personally, I think the default should be zephyr notification, no
header. I have never actually lost a print job because someone took
it by accident, and header pages are a huge waste of paper and toner.
On the other hand, it does make it a bit easier to clean piled-up
papers. (But you can always just put the accumulated pile aside, and
throw papers already tossed aside into the recycling.) On the other
hand, current print policy is to have headers on by default (I don't
know about zephyrs, but it used to be they were off by deafult.)
The SAVE people have been crusading for people to do this for a while
now, and users seem to like the idea, if they bother to care. But we
should get some official word on this before changing the policy.
* PRINT JOB TRACKING *
To enable users to track jobs once they're on the queue, we need to
code up a new applet that would basically be a splufty front-end to
lpq. Here's my vision of what it should look like. (Sorry for the
wide formatting.)
===================================================================================
ATHENA PRINT JOB TRACKING APPLET
Default printer for this host: ajax (w20-575)
[Show all jobs for beland] [Show all jobs for printer: (pulldown menu)]
[Add new printer to menu] [Delete printer from menu]
[Reset to default list]
[Show all jobs on all
printers with jobs for
beland]
-------------------------------------------------------------------------------------------
Click Queue Owner Job# Job name Printed From Printer Time Size
to Rank Host Sent to Sent
Cancel
X 1 beland 238 foo.txt No-Whammies ajax (w20-575) 17:05:49 6.8 Kb
2 joeuser 259 bar.frame w20-575-200 ajax (w20-575) 17:06:20 5.2 Mb
--------------------------------------------------------------------------------------------
[Cancel all jobs for beland]
--------------------------------- [Add new printer to tracking list]
Printer Location Status [Delete printer from tracking list]
[Reset to default list]
ajax w20-575 printing [Track (active printers only)/(all printers on list)]
ceres w20-575 idle
housebook Fenway House jammed
---------------------------------
[Update lists every: 10 sec]
[Printing Configuration]
Auto start applet when printing? (yes/no)
=============================================================================================
By default, pull-down menu should include all public Athena printers.
Changes to the lists should be maintainer per-user and from session
to session.
I think we can track which printers a person has jobs on by putting
recently-used printers in a dotfile in the user's home directory. We
could cause these printers to be deleted from the list either by
watching the active jobs for the user or setting a timeout to poll
lpq. (This has some drawbacks; see below.)
Note that we might not need to allow users to set list update
frequencies, if we establish default (like say, every 10 sec) which
would otherwise be the minimum setting. We might also reduce load by
having a mode where the lists only update when the user pushes a
button. This could be more confusing, though, and I would also
hesitate to make this the default. We want novice users to see if
their print jobs are stuck in a long queue, or if the printer needs
attention, so they can take action, rather than letting the queue
fester. Intermediate and advanced users who don't need constant
updates might disable auto activation and/or use lpq instead. On the
other hand, the current policy is to update only on request (by
running lpq). We should determine the load that the various options
will put on the print servers, compared to what they can actually
handle. I should expect even the 10-second update option wouldn't be
terribly bad, considering only people with active print jobs would be
pinging the servers. But someone more clueful than I needs to OK
this.
* PRINT DOCUMENTATION *
Help should be accessible from within all the relevant
applets/applications from the pulldown menus, via the GNOME help
browser. Athena-specific documentation should be added to the GNOME
docs, including:
- How to move jobs to another printer if the queue is long
(kill and reprint)
- What does and doesn't work (w.r.t. drag-and-drop)
- Instructions on what (or what not) to do when a printer is
physically jammed, misbehaving, or broken (e.g. e-mail
hotline@mit.edu)
- How to request that a queue be cleared (Zephyr -i printadm)
complain about abuse, etc.
- Where to print your thesis, in color, etc.
- Updates to all other OLC stock printing answers
This may or may not be offloaded to people elsewhere in I/S.
* POTENTIAL PROBLEMS WITH PROPOSED ARCHITECTURE *
The two leading file managers we are considering (gmc and Nautilus -
please make suggestions for any other good candidates) support DnD
printing, as do GNOME-aware applications, like ApplixWare.
Non-GNOME-aware applications will not support DnD printing (as far as
I know) nor would they trigger the correct printer in the job tracker
if printing to any location other than the cluster default.
More importantly, when certain file types are dragged to the print
icon, the wrong thing happens. Plaintext and PostScript files print
OK. HTML files print the source instead of the web page (not
unexpectedly, at least for experienced users). Other file types, like
PDF and GIF, die with a console error message.
It should be possible to alter this behavior, either by modifying the
print applet, or by calling a wrapper script to lpr.
In the ideal case, the system would detect the actual file type, and
pass the file off to the appropriate application to be printed
correctly. In the almost-ideal case, the user would be notified that
the file cannot be printed, and will be given the option to use the
GNOME MIME handler to try to open the file automatically, and then
manually invoke that application's print function. HTML (and perhaps
other similar formats) may need some sort of special detection
mechanism. Users should have the option of printing the source code
if they wish, obviously, but I think most would expect to get the
content as it would be seen in the corresponding application.
At last resort, we can simply pass along the "fatal error" message
that binary files produce, and print source for HTML-like formats.
Though one of the requirements for the new AUI is that console
messages be handled more intelligently. The error message returned
would thus have to be modified to something like "Could not print this
file; try opening the file with the application that created it, and
printing from that application." or "Try opening the file before
printing. Double click on it in the file manager."
* * *
That's the end of my draft. Thanks for reading. I'll add this to the
components tracking page RSN.
Beland
===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
Got spam? Stop it at the source. http://spamcop.net
===============================================================
