nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
3c6ab5bbb7
putty-source/unix/gtkapp.c

348 lines
11 KiB
C
Raw Normal View History

New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
/*
* gtkapp.c: a top-level front end to GUI PuTTY and pterm, using
* GtkApplication. Suitable for OS X. Currently unfinished.
*
* (You could run it on ordinary Linux GTK too, in principle, but I
* don't think it would be particularly useful to do so, even once
* it's fully working.)
*/
Create OS X application bundles for PuTTY and pterm. This commit adds two .plist files, which go in the app bundles; two .bundle files, which are input to gtk-mac-bundler and explain to it how to _create_ the bundles; and a piece of manual addition to Makefile.am that actually runs gtk-mac-bundler after building the gtkapp.c based binaries and the OSX launcher. The latter is conditionalised on configuring --with-quartz (unlike the binaries themselves, which you can build on other platforms too, though they won't do much that's useful).
2016-03-23 22:14:13 +00:00
/*
To build on OS X, you will need a build environment with GTK 3 and
gtk-mac-bundler, and also Halibut on the path (to build the man pages,
without which the standard Makefile will complain). Then, from a clean
checkout, do this:
./mkfiles.pl -U --with-quartz
make -C icons icns
make -C doc
make
and you should get unix/PuTTY.app and unix/PTerm.app as output.
*/
Add a TODO list to gtkapp.c. This lists all the things I currently know to be wrong with the OS X work. There are quite a few of them, but I doubt I've thought of them all.
2016-03-23 22:17:09 +00:00
/*
TODO list for a sensible GTK3 PuTTY/pterm on OS X:
Rewrite the OS X TODO a bit. I've filled in the results of some not-entirely-conclusive investigation into the trackpad scrolling issue, some thoughts on resizing, and reordered the items into what currently seems the most sensible order to me.
2017-12-18 14:04:57 +00:00
Still to do on the application menu bar: items that have to vary with
context or user action (saved sessions and mid-session special
commands), and disabling/enabling the main actions in parallel with
their counterparts in the Ctrl-rightclick context menu.
Add a TODO list to gtkapp.c. This lists all the things I currently know to be wrong with the OS X work. There are quite a few of them, but I doubt I've thought of them all.
2016-03-23 22:17:09 +00:00
Mouse wheel events and trackpad scrolling gestures don't work quite
Rewrite the OS X TODO a bit. I've filled in the results of some not-entirely-conclusive investigation into the trackpad scrolling issue, some thoughts on resizing, and reordered the items into what currently seems the most sensible order to me.
2017-12-18 14:04:57 +00:00
right in the terminal drawing area. This seems to be a combination of
two things, neither of which I completely understand yet. Firstly, on
OS X GTK my trackpad seems to generate GDK scroll events for which
gdk_event_get_scroll_deltas returns integers rather than integer
multiples of 1/30, so we end up scrolling by very large amounts;
secondly, the window doesn't seem to receive a GTK "draw" event until
after the entire scroll gesture is complete, which means we don't get
constant visual feedback on how much we're scrolling by.
Add a TODO list to gtkapp.c. This lists all the things I currently know to be wrong with the OS X work. There are quite a few of them, but I doubt I've thought of them all.
2016-03-23 22:17:09 +00:00
Rewrite the OS X TODO a bit. I've filled in the results of some not-entirely-conclusive investigation into the trackpad scrolling issue, some thoughts on resizing, and reordered the items into what currently seems the most sensible order to me.
2017-12-18 14:04:57 +00:00
There doesn't seem to be a resize handle on terminal windows. Then
again, they do seem to _be_ resizable; the handle just isn't shown.
Perhaps that's a feature (certainly in a scrollbarless configuration
the handle gets in the way of the bottom right character cell in the
terminal itself), but it would be nice to at least understand _why_ it
happens and perhaps include an option to put it back again.
Add a TODO list to gtkapp.c. This lists all the things I currently know to be wrong with the OS X work. There are quite a few of them, but I doubt I've thought of them all.
2016-03-23 22:17:09 +00:00
A slight oddity with menus that pop up directly under the mouse
pointer: mousing over the menu items doesn't highlight them initially,
but if I mouse off the menu and back on (without un-popping-it-up)
then suddenly that does work. I don't know if this is something I can
fix, though; it might very well be a quirk of the underlying GTK.
Does OS X have a standard system of online help that I could tie into?
Need to work out what if anything we can do with Pageant on OS X.
Perhaps it's too much bother and we should just talk to the
system-provided SSH agent? Or perhaps not.
Nice-to-have: a custom right-click menu from the application's dock
tile, listing the saved sessions for quick launch. As far as I know
there's nothing built in to GtkApplication that can produce this, but
it's possible we might be able to drop a piece of native Cocoa code in
under ifdef, substituting an application delegate of our own which
forwards all methods we're not interested in to the GTK-provided one?
At the point where this becomes polished enough to publish pre-built,
I suppose I'll have to look into OS X code signing.
https://wiki.gnome.org/Projects/GTK%2B/OSX/Bundling has some links.
*/
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
#include <assert.h>
#include <stdlib.h>
#include <unistd.h>
#include <gtk/gtk.h>
#define MAY_REFER_TO_GTK_IN_HEADERS
#include "putty.h"
GTK: fix the exit(1) response to startup-time font errors. For gtkapp-based tools that will have to stop being a program-fatal error, so I've turned it into a function called window_setup_error (which I could in principle reuse for other problems in the long and tortuous progress of new_session_window), and kept the original handling in gtkmain.c's implementation of that function while gtkapp.c does something more sensible with a message box.
2017-11-27 20:09:54 +00:00
#include "gtkmisc.h"
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
char *x_get_default(const char *key) { return NULL; }
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
const bool buildinfo_gtk_relevant = true;
Unix buildinfo: stop saying 'GTK' in pure CLI utilities. Unix PSCP, PSFTP, Plink and PuTTYgen now just report their build platform as '64-bit Unix' or '32-bit Unix', without mentioning irrelevant details of what flavour of GTK the other tools in the suite might have been built against. (In particular, they now won't imply anything outright untrue if there was no GTK present at build time at all!)
2017-02-22 22:10:05 +00:00
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
/* This front end only works in GTK 3. If that's not what we've got,
* it's easier to just turn this program into a trivial stub by ifdef
* in the source than it is to remove it in the makefile edifice. */
int main(int argc, char **argv)
{
gtkapp.c: fix a copy-paste error in stub main(). Apparently I copied that rather too literally from osxlaunch.c, where the text about OS X and 'launcher' made more sense. The stub main in gtkapp.c has nothing to do with launchers and OS X, so I've corrected the wording to say that a completely different thing won't work in completely different circumstances :-)
2017-11-25 21:55:17 +00:00
fprintf(stderr, "GtkApplication frontend doesn't work pre-GTK3\n");
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
return 1;
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkWidget *make_gtk_toplevel_window(GtkFrontend *frontend) { return NULL; }
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
void launch_duplicate_session(Conf *conf) {}
void launch_new_session(void) {}
void launch_saved_session(const char *str) {}
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
void session_window_closed(void) {}
Build fixes for GTK2. Apparently I haven't tried a GTK2 build since the most recent set of GTK-related code reorganisation. Some functions that were ifdef'ed out in GTK3 builds were now unused even in GTK2 builds (and, because they were also declared static, caused a -Werror build failure); and the pointless stub version of gtkapp.c was missing a stub version of a recently added function referred to from another module.
2018-01-30 19:22:45 +00:00
void window_setup_error(const char *errmsg) {}
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
#else /* GTK_CHECK_VERSION(3,0,0) */
static void startup(GApplication *app, gpointer user_data)
{
GMenu *menubar, *menu, *section;
menubar = g_menu_new();
menu = g_menu_new();
g_menu_append_submenu(menubar, "File", G_MENU_MODEL(menu));
section = g_menu_new();
g_menu_append_section(menu, NULL, G_MENU_MODEL(section));
g_menu_append(section, "New Window", "app.newwin");
menu = g_menu_new();
g_menu_append_submenu(menubar, "Edit", G_MENU_MODEL(menu));
section = g_menu_new();
g_menu_append_section(menu, NULL, G_MENU_MODEL(section));
Sort out clipboard-related menu items. The gtkapp.c menu now has a Copy as well as Paste option; those menu items, as well as the corresponding ones on the context menu and Copy All, now address sets of clipboards parametrised between OS X and ordinary GTK in unix.h. Also I've tweaked the wording of the context-menu items to not use the X-specific terminology "CLIPBOARD" on OS X.
2017-12-17 20:35:45 +00:00
g_menu_append(section, "Copy", "win.copy");
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
g_menu_append(section, "Paste", "win.paste");
Fill in some more of the OS X menu bar. This still isn't complete: I also need to add the variable collections of things like mid-session special commands and saved session names, and also I need to try to grey out menu items when they're not applicable. But it's a start.
2017-12-18 11:46:48 +00:00
g_menu_append(section, "Copy All", "win.copyall");
menu = g_menu_new();
g_menu_append_submenu(menubar, "Window", G_MENU_MODEL(menu));
section = g_menu_new();
g_menu_append_section(menu, NULL, G_MENU_MODEL(section));
g_menu_append(section, "Restart Session", "win.restart");
g_menu_append(section, "Duplicate Session", "win.duplicate");
section = g_menu_new();
g_menu_append_section(menu, NULL, G_MENU_MODEL(section));
g_menu_append(section, "Change Settings", "win.changesettings");
if (use_event_log) {
section = g_menu_new();
g_menu_append_section(menu, NULL, G_MENU_MODEL(section));
g_menu_append(section, "Event Log", "win.eventlog");
}
section = g_menu_new();
g_menu_append_section(menu, NULL, G_MENU_MODEL(section));
g_menu_append(section, "Clear Scrollback", "win.clearscrollback");
g_menu_append(section, "Reset Terminal", "win.resetterm");
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
Let puttyapp/ptermapp build against old Gtk 3. gtk_application_set_accels_for_action() is new in Gtk 3.12, but (e.g.) Ubuntu 14.04 LTS still ships with Gtk 3.10. On the other hand, the function I've used instead, gtk_application_add_accelerator(), is deprecated from Gtk 3.14 onwards, indicating that it will disappear in some future version, so I've left the newer code in against that day.
2017-12-20 11:55:51 +00:00
#if GTK_CHECK_VERSION(3,12,0)
Add keyboard accelerators in the GtkApplication menu. Now that they actually _work_, it seems more useful to start putting them in on purpose.
2017-12-18 11:01:42 +00:00
#define SET_ACCEL(app, command, accel) do \
{ \
static const char *const accels[] = { accel, NULL }; \
gtk_application_set_accels_for_action( \
GTK_APPLICATION(app), command, accels); \
} while (0)
Let puttyapp/ptermapp build against old Gtk 3. gtk_application_set_accels_for_action() is new in Gtk 3.12, but (e.g.) Ubuntu 14.04 LTS still ships with Gtk 3.10. On the other hand, the function I've used instead, gtk_application_add_accelerator(), is deprecated from Gtk 3.14 onwards, indicating that it will disappear in some future version, so I've left the newer code in against that day.
2017-12-20 11:55:51 +00:00
#else
/* The Gtk function used above was new in 3.12; the one below
* was deprecated from 3.14. */
#define SET_ACCEL(app, command, accel) \
gtk_application_add_accelerator(GTK_APPLICATION(app), accel, \
command, NULL)
#endif
Add keyboard accelerators in the GtkApplication menu. Now that they actually _work_, it seems more useful to start putting them in on purpose.
2017-12-18 11:01:42 +00:00
SET_ACCEL(app, "app.newwin", "<Primary>n");
SET_ACCEL(app, "win.copy", "<Primary>c");
SET_ACCEL(app, "win.paste", "<Primary>v");
#undef SET_ACCEL
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
gtk_application_set_menubar(GTK_APPLICATION(app),
G_MENU_MODEL(menubar));
}
Minor refactoring of gtkapp.c -> gtkwin.c menu triggers. Just to avoid an endless proliferation of functions too small to see, I've arranged an enumeration of action ids and a single app_menu_action function on the receiving end, and in gtkapp.c, a list macro that means I at least don't have to define the tiny callback functions and the GActionEntry records by hand and keep them in sync.
2017-12-18 11:15:44 +00:00
#define WIN_ACTION_LIST(X) \
X("copy", MA_COPY) \
X("paste", MA_PASTE) \
Fill in some more of the OS X menu bar. This still isn't complete: I also need to add the variable collections of things like mid-session special commands and saved session names, and also I need to try to grey out menu items when they're not applicable. But it's a start.
2017-12-18 11:46:48 +00:00
X("copyall", MA_COPY_ALL) \
X("duplicate", MA_DUPLICATE_SESSION) \
X("restart", MA_RESTART_SESSION) \
X("changesettings", MA_CHANGE_SETTINGS) \
X("clearscrollback", MA_CLEAR_SCROLLBACK) \
X("resetterm", MA_RESET_TERMINAL) \
X("eventlog", MA_EVENT_LOG) \
Minor refactoring of gtkapp.c -> gtkwin.c menu triggers. Just to avoid an endless proliferation of functions too small to see, I've arranged an enumeration of action ids and a single app_menu_action function on the receiving end, and in gtkapp.c, a list macro that means I at least don't have to define the tiny callback functions and the GActionEntry records by hand and keep them in sync.
2017-12-18 11:15:44 +00:00
/* end of list */
Sort out clipboard-related menu items. The gtkapp.c menu now has a Copy as well as Paste option; those menu items, as well as the corresponding ones on the context menu and Copy All, now address sets of clipboards parametrised between OS X and ordinary GTK in unix.h. Also I've tweaked the wording of the context-menu items to not use the X-specific terminology "CLIPBOARD" on OS X.
2017-12-17 20:35:45 +00:00
Minor refactoring of gtkapp.c -> gtkwin.c menu triggers. Just to avoid an endless proliferation of functions too small to see, I've arranged an enumeration of action ids and a single app_menu_action function on the receiving end, and in gtkapp.c, a list macro that means I at least don't have to define the tiny callback functions and the GActionEntry records by hand and keep them in sync.
2017-12-18 11:15:44 +00:00
#define WIN_ACTION_CALLBACK(name, id) \
static void win_action_cb_ ## id(GSimpleAction *a, GVariant *p, gpointer d) \
{ app_menu_action(d, id); }
WIN_ACTION_LIST(WIN_ACTION_CALLBACK)
#undef WIN_ACTION_CALLBACK
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
static const GActionEntry win_actions[] = {
Minor refactoring of gtkapp.c -> gtkwin.c menu triggers. Just to avoid an endless proliferation of functions too small to see, I've arranged an enumeration of action ids and a single app_menu_action function on the receiving end, and in gtkapp.c, a list macro that means I at least don't have to define the tiny callback functions and the GActionEntry records by hand and keep them in sync.
2017-12-18 11:15:44 +00:00
#define WIN_ACTION_ENTRY(name, id) { name, win_action_cb_ ## id },
WIN_ACTION_LIST(WIN_ACTION_ENTRY)
#undef WIN_ACTION_ENTRY
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
};
static GtkApplication *app;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkWidget *make_gtk_toplevel_window(GtkFrontend *frontend)
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
{
GtkWidget *win = gtk_application_window_new(app);
g_action_map_add_action_entries(G_ACTION_MAP(win),
win_actions,
G_N_ELEMENTS(win_actions),
frontend);
return win;
}
void launch_duplicate_session(Conf *conf)
{
Omit the conf_launchable check in pterm Duplicate Session. It won't return true, because pterm's use of conf is a bit nonstandard (it doesn't really bother about the protocol field, and has no use for either host names _or_ serial port filenames). Was affecting both gtkapp and gtkmain based builds.
2016-03-27 13:10:06 +00:00
assert(!dup_check_launchable || conf_launchable(conf));
Add missing g_application_hold on Duplicate Session. The omission of this call caused a GTK assertion failure when the GApplication's use count went negative after two releases and only one hold.
2017-12-17 20:18:20 +00:00
g_application_hold(G_APPLICATION(app));
Add a missing conf_copy in gtkapp's Duplicate Session. Without this, the Conf objects in a session and its duplicate were aliases of each other, which could lead to confusing semantic effects if one of the sessions was reconfigured in mid-run, and worse still, a crash if one session got cleaned up and called conf_free on a Conf that the other was still using. None of that was intentional; it was just a matter of forgetting to clone the Conf for the duplicated session. Now we do.
2017-11-25 21:51:45 +00:00
new_session_window(conf_copy(conf), NULL);
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
}
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
void session_window_closed(void)
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
{
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
g_application_release(G_APPLICATION(app));
}
static void post_initial_config_box(void *vctx, int result)
{
Conf *conf = (Conf *)vctx;
Fix a cleanup issue in dlgparam_destroy. If a dialog box is destroyed by the program before the user has pressed one of the result-delivering buttons - e.g. because the parent window closes so the dialog is no longer relevant to anything anyway - then dlgparam_destroy would never call the client code's provided callback. That makes sense in terms of the callback wanting to _take action_ based on the result of the dialog box, but it ignores the possibility that the callback may simply need to free its own context structure. So now dlgparam_destroy always calls the client's callback, even if the result it passes is negative (meaning 'the user never got round to pressing any of the dialog-ending buttons'), and all the existing client callbacks handle the negative-result case by doing nothing except freeing any allocated memory they might have.
2017-11-26 14:37:38 +00:00
if (result > 0) {
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
new_session_window(conf, NULL);
Fix a cleanup issue in dlgparam_destroy. If a dialog box is destroyed by the program before the user has pressed one of the result-delivering buttons - e.g. because the parent window closes so the dialog is no longer relevant to anything anyway - then dlgparam_destroy would never call the client code's provided callback. That makes sense in terms of the callback wanting to _take action_ based on the result of the dialog box, but it ignores the possibility that the callback may simply need to free its own context structure. So now dlgparam_destroy always calls the client's callback, even if the result it passes is negative (meaning 'the user never got round to pressing any of the dialog-ending buttons'), and all the existing client callbacks handle the negative-result case by doing nothing except freeing any allocated memory they might have.
2017-11-26 14:37:38 +00:00
} else if (result == 0) {
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
conf_free(conf);
g_application_release(G_APPLICATION(app));
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
}
}
void launch_saved_session(const char *str)
{
Conf *conf = conf_new();
do_defaults(str, conf);
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
g_application_hold(G_APPLICATION(app));
if (!conf_launchable(conf)) {
initial_config_box(conf, post_initial_config_box, conf);
} else {
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
new_session_window(conf, NULL);
}
}
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
void launch_new_session(void)
{
/* Same as launch_saved_session except that we pass NULL to
* do_defaults. */
launch_saved_session(NULL);
}
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
void new_app_win(GtkApplication *app)
{
launch_new_session();
}
GTK: fix the exit(1) response to startup-time font errors. For gtkapp-based tools that will have to stop being a program-fatal error, so I've turned it into a function called window_setup_error (which I could in principle reuse for other problems in the long and tortuous progress of new_session_window), and kept the original handling in gtkmain.c's implementation of that function while gtkapp.c does something more sensible with a message box.
2017-11-27 20:09:54 +00:00
static void window_setup_error_callback(void *vctx, int result)
{
g_application_release(G_APPLICATION(app));
}
void window_setup_error(const char *errmsg)
{
create_message_box(NULL, "Error creating session window", errmsg,
string_width("Some sort of fiddly error message that "
"might be technical"),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
true, &buttons_ok, window_setup_error_callback, NULL);
GTK: fix the exit(1) response to startup-time font errors. For gtkapp-based tools that will have to stop being a program-fatal error, so I've turned it into a function called window_setup_error (which I could in principle reuse for other problems in the long and tortuous progress of new_session_window), and kept the original handling in gtkmain.c's implementation of that function while gtkapp.c does something more sensible with a message box.
2017-11-27 20:09:54 +00:00
}
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
static void activate(GApplication *app,
gpointer user_data)
{
new_app_win(GTK_APPLICATION(app));
}
static void newwin_cb(GSimpleAction *action,
GVariant *parameter,
gpointer user_data)
{
new_app_win(GTK_APPLICATION(user_data));
}
static void quit_cb(GSimpleAction *action,
GVariant *parameter,
gpointer user_data)
{
g_application_quit(G_APPLICATION(user_data));
}
Fill in some more of the OS X menu bar. This still isn't complete: I also need to add the variable collections of things like mid-session special commands and saved session names, and also I need to try to grey out menu items when they're not applicable. But it's a start.
2017-12-18 11:46:48 +00:00
static void about_cb(GSimpleAction *action,
GVariant *parameter,
gpointer user_data)
{
about_box(NULL);
}
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
static const GActionEntry app_actions[] = {
{ "newwin", newwin_cb },
Fill in some more of the OS X menu bar. This still isn't complete: I also need to add the variable collections of things like mid-session special commands and saved session names, and also I need to try to grey out menu items when they're not applicable. But it's a start.
2017-12-18 11:46:48 +00:00
{ "about", about_cb },
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
{ "quit", quit_cb },
};
int main(int argc, char **argv)
{
int status;
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
/* Call the function in ux{putty,pterm}.c to do app-type
* specific setup */
setup(false); /* false means we are not a one-session process */
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
New program 'osxlaunch', to use as an OS X bundle launcher. The big problem with making an OS X application out of a GTK program is that it won't start unless DYLD_LIBRARY_PATH and several other environment variables point at all the GTK machinery. So your app bundle has to contain two programs: a launcher to set up that environment, and then the real main program that the launcher execs once it's done so. But in our case, we also need pterm to start subprocesses _without_ all that stuff in the environment - so our launcher has to be more complicated than the usual one, because it's also got to save every detail of how the environment was when it started up. So this is the launcher program I'm going to use. Comments in the header explain in more detail how it'll work. Also in this commit, I add the other end of the same machinery to gtkapp.c and uxpty.c: the former catches an extra command-line argument that the launcher used to indicate how it had munged the environment, and stores it in a global variable where the latter can pick it up after fork() and use to actually undo the munging.
2016-03-23 22:13:30 +00:00
if (argc > 1) {
pty_osx_envrestore_prefix = argv[--argc];
}
New front end to PuTTY/pterm, as a GtkApplication. When it's finished, this will be the backbone of the OS X GTK port: using a GtkApplication automatically gives us a properly OS X integrated menu bar. Using this source file in place of gtkmain.c turns the usual Unix single-session-per-process PuTTY or pterm into the multi-session-per- process OS X style one. Things like Duplicate Session can be done much more simply here - we just grab the Conf * from the source window and launch a new window using it, with no fiddly interprocess work needed. This is still experimental and has a lot of holes, but it's usable enough to test and improve.
2016-03-23 22:22:30 +00:00
{
const char *home = getenv("HOME");
if (home) {
if (chdir(home)) {}
}
}
gtkcomm_setup();
app = gtk_application_new("org.tartarus.projects.putty.macputty",
G_APPLICATION_FLAGS_NONE);
g_signal_connect(app, "activate", G_CALLBACK(activate), NULL);
g_signal_connect(app, "startup", G_CALLBACK(startup), NULL);
g_action_map_add_action_entries(G_ACTION_MAP(app),
app_actions,
G_N_ELEMENTS(app_actions),
app);
status = g_application_run(G_APPLICATION(app), argc, argv);
g_object_unref(app);
return status;
}
#endif /* GTK_CHECK_VERSION(3,0,0) */
Reference in New Issue Copy Permalink