Bryce,
Actually, this is not intended - I mean, letting PuTTY interface available.
This happened because we upgraded to a new version of PuTTY and, as the code changes a lot between two versions, we may have missed the place where to disable this.
Why do we disable PuTTY preferences ?
Two main reasons:
1. we've no control on the interface. What if we "publish" one function that will be removed by PuTTY guys ? This is why we try to publish only what is mandatory for GDC connexion.
2. We don't use PuTTY's "save session" mechanism, as everything is meant to be driven by GDC
pro: shortcut mechanism is in one place, in the same interface.
cons: we need to implement our own interface and to pass items to fgltty as parameters.
One option would have be to use PuTTY's "saved session" mechanism, but this would break @TAGs and terminal strings mechanism.
The issue we have now is that each user has an interest in another PuTTY feature that we would have to integrate in GDC.
So this explains the current state.
For the future:
1. logging. This is in my eyes the next mandatory "feature" we've to add. When you start a shortcut, you don't know what happens, and this is bad. We've to improve that.
2. PuTTY's features. We are currently working on qPutty (
http://sourceforge.net/projects/qputty/). When this is in the right stage, this will be integrated in GDC:
- (internal) should be easier for us to upgrade when a new PuTTY version goes out
- should be easier to add configuration options in GDC
- last but not least: what about
GRID
{
[widget ]
[ ]
[ ]
[ ]
[ ]
}
END
ATTRIBUTES
TERMINAL widget : terminalWidget;
and
CALL FGL_SHOWTERMINAL_INFORM("terminalWidget","terminalName")
or
CALL FGL_STARTTERMINAL_INFORM("terminalWidget","shortCutName")
(just ideas, nothing fixed now).
Could be helpful if you've old text mode applications, right ?
Sign in for full access
Help
