Remove dead comment about writing settings, and query one about reading them.

[u/mdw/putty] / unix / uxputty.c

diff --git a/unix/uxputty.c b/unix/uxputty.c
index 8f2fad1..6b1eabb 100644 (file)
--- a/unix/uxputty.c
+++ b/unix/uxputty.c
@@ -12,68 +12,6 @@
 #include "storage.h"
 
 /*
- * TODO:
- * 
- *  - Copy-and-paste from the Event Log.
- * 
- *  - Remainder of the context menu:
- * 
- *     - New Session and Duplicate Session (perhaps in pterm, in fact?!)
- *        + Duplicate Session will be fun, since we must work out
- *          how to pass the config data through.
- *        + In fact this should be easier on Unix, since fork() is
- *          available so we need not even exec (this also saves us
- *          the trouble of scrabbling around trying to find our own
- *          binary). Possible scenario: respond to Duplicate
- *          Session by forking. Parent continues as before; child
- *          unceremoniously frees all extant resources (backend,
- *          terminal, ldisc, frontend etc) and then _longjmps_ (I
- *          kid you not) back to a point in pt_main() which causes
- *          it to go back round to the point of opening a new
- *          terminal window and a new backend.
- *        + A tricky bit here is how to free everything without
- *          also _destroying_ things - calling GTK to free up
- *          existing widgets is liable to send destroy messages to
- *          the X server, which won't go down too well with the
- *          parent process. exec() is a much cleaner solution to
- *          this bit, but requires us to invent some ghastly IPC as
- *          we did in Windows PuTTY.
- *        + Arrgh! Also, this won't work in pterm since we'll
- *          already have dropped privileges by this point, so we
- *          can't get another pty. Sigh. Looks like exec has to be
- *          the way forward then :-/
- * 
- *     - Saved Sessions submenu (not in pterm of course)
- * 
- *     - Change Settings
- *        + we must also implement mid-session reconfig in pterm.c.
- *       + This will require some work. We have to throw the new
- *         config at the log module, the ldisc, the terminal, and
- *         the backend; that's the easy bit. But within pterm.c
- *         itself we must also: 
- *           - redo the colour palette if necessary
- *             * might be nice to move this over into terminal.c.
- *               That way we could check which palette entries in
- *               cfg have actually been _changed_ during
- *               reconfiguration, and only update those ones in
- *               the currently visible palette. Also it'd save
- *               some of this hassle in the next port.
- *           - enable/disable/move the scroll bar if necessary
- *           - change the window title if necessary
- *           - reinitialise the fonts
- *          - resize the window if necessary (may be required
- *            either by terminal size change or font size change
- *            or both)
- *           - redraw everything, just to be safe.
- *       + In particular, among the above chaos, we must look into
- *         how the choice of font affects the choice of codepage
- *         since the Unix default is to derive the latter from the
- *         former.
- * 
- *     - Copy All to Clipboard (for what that's worth)
- */
-
-/*
  * Clean up and exit.
  */
 void cleanup_exit(int code)
@@ -101,13 +39,12 @@ Backend *select_backend(Config *cfg)
 
 int cfgbox(Config *cfg)
 {
-    extern int do_config_box(const char *title, Config *cfg);
-    return do_config_box("PuTTY Configuration", cfg);
+    return do_config_box("PuTTY Configuration", cfg, 0);
 }
 
 static int got_host = 0;
 
-const int use_event_log = 1;
+const int use_event_log = 1, new_session = 1, saved_sessions = 1;
 
 int process_nonoption_arg(char *arg, Config *cfg)
 {