large inboxes can be convenient. As is, this can be performed manually by running
a Save to store fetched mails in a text file and searching in that file externally.Frozen binary distribution
As a desktop program, PyMailGUI seems an ideal candidate for packing as a self-
contained frozen binary executable, using tools such as PyInstaller, Py2Exe, and
others. When distributed this way, users need not install Python, since the Python
runtime is embedded in the executable.
Selecting Reply versus Reply-All in the GUI
As described in the 3.0 changes overview earlier, in this version, Reply by default
now copies all the original mail’s recipients by prefilling the Cc line, in addition to
replying to the original sender. This Cc feature can be turned off in mailconfig
because it may not be desirable in all cases. Ideally, though, this should be select-
able in the GUI on a mail-by-mail basis, not per session. Adding another button to
list windows for ReplyAll would suffice; since this feature was added too late in
this project for GUI changes, though, this will have to be relegated to the domain
of suggested exercise.
Propagating attachments?
When replying to or forwarding an email, PyMailGUI discards any attachments
on the original message. This is by design, partly because there is currently no way
to delete attached parts in the GUI prior to sending (you couldn’t remove selectively
and couldn’t remove all), and partly because this system’s current sole user prefers
to work this way.
Users can work around this by running a Split to save all parts in a directory, and
then adding any desired attachments to the mail from there. Still, it might be better
to allow the user to choose that this happen automatically for replies and forwards.
Similarly, forwarding HTML mails well currently requires saving and attaching the
HTML part to avoid quoting the text; this might be similarly addressed by parts
propagation in general.
Disable editing for viewed mails?
Mail text is editable in message view windows, even though a new mail is not being
composed. This is deliberate—users can annotate the message’s text and save it in
a text file with the Save button at the bottom of the window, or simply cut-and-
paste portions of it into other windows. This might be confusing, though, and is
redundant (we can also edit and save by clicking on the main text’s quick-access
part button). Removing edit tools would require extending PyEdit. Using PyEdit
for display in general is a useful design—users also have access to all of PyEdit’s
tools for the mail text, including save, find, goto, grep, replace, undo/redo, and so,
though edits might be superfluous in this context.
Automatic periodic new mail check?
It would be straightforward to add the ability to automatically check for and fetch
new incoming email periodically, by registering long-duration timer events with
either the after widget method or the threading module’s timer object. I haven’t
1120 | Chapter 14: The PyMailGUI Client