Road Map and clearinghouse for feature requests

[Dean]

Everyone,
I've settled on what I expect to be the road map for updates over
the following few months. As posted on the website, the expected
features are as follows: (in order of expected completion)

* Refinements to the VNC and X server interface
* Terminal option refinements (SCO Mode, exotic terminal settings,
etc.)
* User-defined and organized keys
* Connection organizer
* SSH, Telnet and VNC connection wizard
* Tunneled web browser
* RDP (Windows Remote Desktop) support

I'm hoping to make this thread a place were people can make feature
requests and, until the bug tracker is up, I'll use it to keep track
of them. Thanks everyone for your support. Expect the next ad hoc
release sometime in the middle of next week, sooner if Apple releases
3.5.

Dean

[Chris Jones]

Hi

Dean wrote:
> * User-defined and organized keys

Page Up/Page Down keys please :D

Cheers,
--
Chris Jones
cm...@tenshu.net
www.tenshu.net

[Jochen]

Hi Dean.

You might consider looking at the NX protocol as way to minimize the
latency of non-WLAN connections. AFAIK is the protocol itself open and
there open source client implementations.

Bye Jochen

[Brian Mastenbrook]

On Jul 5, 2009, at 9:16 PM, Dean wrote:

> * Tunneled web browser

>
> I'm hoping to make this thread a place were people can make feature
> requests and, until the bug tracker is up, I'll use it to keep track
> of them. Thanks everyone for your support. Expect the next ad hoc
> release sometime in the middle of next week, sooner if Apple releases
> 3.5.

Do you have any plans to implement URL detection / linking in advance
of having the tunneled web browser? This would significantly improve
my experience - more so if URLs opened up in an in-application non-
tunneled browser, if possible.

[André Braga]

On Jul 5, 11:16 pm, Dean <canada...@gmail.com> wrote:
> * Refinements to the VNC and X server interface

> * SSH, Telnet and VNC connection wizard

> * RDP (Windows Remote Desktop) support

NX protocol support, please! Should do wonders for slow connections
like Edge or spotty 3G. Too bad that FreeNX is GPL and Apple doesn't
allow launching a secondary binary, which rules out taking the lazy
path while not tainting the iSSH source. But perhaps you could
implement the protocol directly instead of using the FreeNX client...


Cheers,
A.

[Dean]

I can't seem to find much on the NX protocol at all. It all seems
proprietary and even FreeNX just seems to be scripts around the
proprietary binaries. Again, I won't turn down documentation of it
shows up.

Dean

[Tek]

Hi Dean,

To quote wikipedia:

'NoMachine uses the GNU General Public License for the core NX
technology, while at the same time offering non-free commercial NX
server and client products for Linux, Microsoft Windows, Solaris, Mac
OS X and embedded systems.
Due to the free software nature of NX, the FreeNX project was started
in order to provide the wrapper scripts for the GPL NX libraries.
FreeNX is developed and maintained by Fabian Franz.'

The NX protocol seems rather complicated to set up but I'm sure that
it can be done as it is largely just a compression layer on top of X
tunnelled through SSH and if done the rewards would certainly be worth
it, making iSSH the ultimate swiss army knife of UNIX remote
administration. Also, if I can be of assistance in any way
(deciphering, searching, testing, and I'd help with coding if iSSH
wasn't closed source... :D) then just e-mail me!

Here are some links that may help:

http://www.nomachine.com/technology.php - Lots of information about
the NX technology in a reasonable amount of detail...

http://www.nomachine.com/sources.php - Quote: 'The technology behind
NX has been released as OpenSource to the community, including the X
and the X compression libraries.' - This page has all of these
sources...

Unfortunately the seem not to have released the sources for their
embedded clients (http://www.nomachine.com/experimental-products.php)
but maybe NoMachine would provide a little assistance if you contacted
them? You never know...

Quote:
'If you wish to use NX Client for PlayStation2 or iPAQ or Zaurus 5XXX
then please go to our list of experimental software products. The
products listed here are NX compatible, but are not officially
supported and must be considered experimental projects. NX customers
who wish to use this software can request support for NX Server issues
through the regular support channels. Any queries concerning
development of NX Clients in this section should go through our sales
channel.'

Unless they are currently developing their own such product, it seems
very likely to me that NoMachine would be interested in an iPhone
application that is capable of connecting to their NX servers as it
would only be to their benefit.

As such, you can contact NoMachine here: http://www.nomachine.com/contactus.php

As a little more reference, the FreeNX sources are here:
http://developer.berlios.de/project/showfiles.php?group_id=2978
(though FreeNX is a server, rather than a client)

http://openfacts.berlios.de/index-en.phtml?title=NX_Components - This
seems interesting and relevant...

Finally, what is perhaps the most promising:

http://svn.berlios.de/svnroot/repos/freenx/trunk/freenx-client/ - This
is the subversion repository for a few open source NX client
attempts...

Note that, of these, 'nxcl' (http://svn.berlios.de/svnroot/repos/
freenx/trunk/freenx-client/nxcl/) seems to have been the most
promising and its library is here: http://svn.berlios.de/svnroot/repos/freenx/trunk/freenx-client/nxcl/lib/

Perhaps this library could be used to get started?

I hope that at least _some_ of the above information has been useful
and nxcl does indeed look like an interesting library. However, since
you have already implemented the X server on the iPhone, perhaps you
won't need the full extent of the libraries...

Once again, tell me if I can help and good luck with this rather
daunting project!

--
Tek

[Tek]

I just thought I'd point out... please, take as much time as you
need... I can see that this is probably a rather large project, but if
it were to be completed it would be invaluable and seems to be the
natural progression for a SSH and X client...

Even if this won't be ready for a while yet, if it could be done it
would be amazing.

Thanks,
Tek

On Jul 7, 6:52 pm, Tek <comcraz...@gmail.com> wrote:
> Hi Dean,
>
> To quote wikipedia:
>
> 'NoMachine uses the GNU General Public License for the core NX
> technology, while at the same time offering non-free commercial NX
> server and client products for Linux, Microsoft Windows, Solaris, Mac
> OS X and embedded systems.
> Due to the free software nature of NX, the FreeNX project was started
> in order to provide the wrapper scripts for the GPL NX libraries.
> FreeNX is developed and maintained by Fabian Franz.'
>
> The NX protocol seems rather complicated to set up but I'm sure that
> it can be done as it is largely just a compression layer on top of X
> tunnelled through SSH and if done the rewards would certainly be worth
> it, making iSSH the ultimate swiss army knife of UNIX remote
> administration. Also, if I can be of assistance in any way
> (deciphering, searching, testing, and I'd help with coding if iSSH
> wasn't closed source... :D) then just e-mail me!
>
> Here are some links that may help:
>

> http://www.nomachine.com/technology.php- Lots of information about

> the NX technology in a reasonable amount of detail...
>

> http://www.nomachine.com/sources.php- Quote: 'The technology behind

> NX has been released as OpenSource to the community, including the X
> and the X compression libraries.' - This page has all of these
> sources...
>
> Unfortunately the seem not to have released the sources for their
> embedded clients (http://www.nomachine.com/experimental-products.php)
> but maybe NoMachine would provide a little assistance if you contacted
> them? You never know...
>
> Quote:
> 'If you wish to use NX Client for PlayStation2 or iPAQ or Zaurus 5XXX
> then please go to our list of experimental software products. The
> products listed here are NX compatible, but are not officially
> supported and must be considered experimental projects. NX customers
> who wish to use this software can request support for NX Server issues
> through the regular support channels. Any queries concerning
> development of NX Clients in this section should go through our sales
> channel.'
>
> Unless they are currently developing their own such product, it seems
> very likely to me that NoMachine would be interested in an iPhone
> application that is capable of connecting to their NX servers as it
> would only be to their benefit.
>
> As such, you can contact NoMachine here:http://www.nomachine.com/contactus.php
>
> As a little more reference, the FreeNX sources are here:http://developer.berlios.de/project/showfiles.php?group_id=2978
> (though FreeNX is a server, rather than a client)
>

> http://openfacts.berlios.de/index-en.phtml?title=NX_Components- This

> seems interesting and relevant...
>
> Finally, what is perhaps the most promising:
>

> http://svn.berlios.de/svnroot/repos/freenx/trunk/freenx-client/- This

[Alex]

Bold color support in the terminal?

(I tried to make a separate post about this, but now I can't find it.
I hope I'm not spamming)

[Dean]

Bold ANSI color support has been fixed in the version currently in
review by Apple. It's also far more BBS friendly--complete with
classic font and encoding considerations.

The forum is setup to automatically moderate the first post of a new
arrival to prevent spam. You're good to go here on out! Thanks.

Oh yeah, all updates of iSSH are free.

Dean

[André Braga]

So far, then:

o RDP
o NX
o Embedded Webkit with tunneled connection

Now:

o SFTP support, to the sandbox even. This idea was rejected before,
but:
o A way to fetch and upload files from/to the phone/iPod, perhaps
via a simple Web server (look at iFile in Cydia, or Discover on the
App Store. Both are free.)
o A document viewer (again, iFile/Discover for inspiration), perhaps
with a plaintext editor. Yes, for the later of course I'm thinking of
the use case of downloading source code from a remote server, fix
stuff up locally and re-upload :)
o Audio tunneling for RDP, and maybe VNC too via ESD. Nomachine's NX
client uses the latter to tunnel audio, and EsounD is LGPL. This one
would be nice, but not essential, though. Jaadu RDP has it. I'll never
pay what they ask for it. :P

Anybody else would like to add anything?


Cheers,
A.

[Dean]

André,
These are all great suggestions and will definitely keep me busy for
a while. I'll admit Both RDP and NX are the most fascinating of
projects to me for additions to iSSH. I'm somewhat torn as which to
tackle first.

Dean

[Chris Jones]

Hi

Dean wrote:
> These are all great suggestions and will definitely keep me busy for
> a while. I'll admit Both RDP and NX are the most fascinating of
> projects to me for additions to iSSH. I'm somewhat torn as which to
> tackle first.

Are you not tempted to bundle up all 4 remote desktop protocols into a
single mega remote desktop type app which happens to be able to connect
to things over ssh?

I'm not complaining in any way, I just don't need these features so I
don't care if people have to pay more for them ;)

[Dean]

Chris,
You make a good point. With the in app purchases available on 3.0
iPhone apps, I could possibly implement RDP and charge $0.99 to enable
it. I really, really hate this business model (aka: defective by
design), however. Separating out the apps completely creates
headaches I'd rather not deal with though. I do like the thought of
having what I think is a good price for a swiss-army knife of remote
administration though.

Dean

>   c...@tenshu.net
>    www.tenshu.net

[André Braga]

On 15 jul, 14:02, Dean <canada...@gmail.com> wrote:
> André,
>   These are all great suggestions and will definitely keep me busy for
> a while.  I'll admit Both RDP and NX are the most fascinating of
> projects to me for additions to iSSH.  I'm somewhat torn as which to
> tackle first.

RDP, no contest! Enormous audience, only a single decent client on the
store (Jaadu; the others are a bag of shame), most likely to attract
new users and hence a steady revenue stream.

Consider renaming iSSH to Remote Army Knife (or something to that
effect, but feel free to use this name ;)), though, and distributing
redeemable codes to your existing iSSH customers. This goes so much
beyond the scope of SSH that people won't easily fnd about the many
capabilities of it if the name remains. Or shed the "weight" of iSSH
by bundling the larger functionality only into RAK; IOW have iSSH be a
single-purpose app, like iX11.

This way you get around the microtransactions situation (which I'm
also alergic to), and nobody is left in the cold. :)


Cheers,
A.

[André Braga]

On 15 jul, 15:40, André Braga <andrebr...@gmail.com> wrote:
> RDP, no contest! Enormous audience, only a single decent client on the
> store (Jaadu; the others are a bag of shame), most likely to attract
> new users and hence a steady revenue stream.

Oh, and incomparably better documentation.

A.

[Joshua Ochs]

> * User-defined and organized keys

I'm not quite sure what you're envisioning with this (other than the
*excellent* pie idea mentioned on the 4.0 thread), but here are some
observations from the 3.5 release:
* The highlight for when a modifier is held down is far to subtle for
me (and I *like* subtle!). A blue glossy highlight to indicate it's
locked down would be quite welcome.
* The dots on either end of the "ribbon" were far from obvious at
first. I'd recommend small arrows pointing either direction. I've seen
several posts to indicate I'm not the only one. :)
* Something similar to a drop-down menu or contextual gesture for
additional non-modifier keys would be quite useful. Right now there's
a LOT of scrolling back and forth, and such an interface doesn't scale
well for more and more keys. Since you're looking at "press and hold"
for the navigation pie, could "two finger press and hold" work for a
key palette?

A few other, non-key requests:
* When an SSH session is closed (e.g., typing "exit"), could the
connection be closed automatically, dropping the user back at the
connection list?
* Fonts. While truetype/outline fonts work great for scaling and
zooming, they're pretty miserable at small sizes such as when you're
trying to get more than 40-60 columns onscreen. My recommendations
would be a good bitmap font (ProFont 9 or a variant thereof) and
FreeMono for outline.

Thanks!
- Joshua Ochs

[Jay Snyder]

Dean,

You could offer a few different apps, all based on the same iSSH
core, but with different protocols. That way, people only pay for
what they need.

Regards,
Jay

[André Braga]

On 16 jul, 09:40, Jay Snyder <jay.snyde...@gmail.com> wrote:
> Dean,
>    You could offer a few different apps, all based on the same iSSH  
> core, but with different protocols.  That way, people only pay for  
> what they need.

He does that already, check iX11 on the App Store. I still believe
that one Army Knife solution for heterogenous network admins *and*
several smaller apps all derived from the same core is the way to go
to maximise profits (and hence support) and target audience (critical
mass, resp.).

I'm not really business oriented, but would really like to see iSSH
flourish. I feel like I found a great little secret which has gathered
a small and brilliant community around it. Which was bound to happen,
Unix sysadmins are usually smart people ;)

Cheers,
A.

[Chris Jones]

Hi

André Braga wrote:
> that one Army Knife solution for heterogenous network admins *and*
> several smaller apps all derived from the same core is the way to go

The smaller apps could each be able to purchase additional features
using the new iTunes Store feature, or you can pre-buy the whole lot as
the Network Army Knife. Maybe that would make life more complicated for
Dean though ;)

[Ken Weingold]

On Jul 16, 2009, at 24:09 , Joshua Ochs wrote:
> * The dots on either end of the "ribbon" were far from obvious at
> first. I'd recommend small arrows pointing either direction. I've seen
> several posts to indicate I'm not the only one. :)

You would be correct. I recently needed to do something on the server
and needed the back-tick, but it was nowhere to be found. I later
discovered that those buttons were scrollable.

-Ken

[Dean]

With the addition of the Key pie menu the ribbon at the top should
lose significance though I'll probably make it user configurable where
it goes and what happens to it. Ideally, with the exception of the
sticky keys like "Ctrl" and "Alt", the ribbon menu will be completely
replaced with a completely user configurable pie menu. A new beta of
this functionality will be out today!

Dean

[André Braga]

On Jul 16, 10:05 am, Chris Jones <c...@tenshu.net> wrote:
> The smaller apps could each be able to purchase additional features
> using the new iTunes Store feature, or you can pre-buy the whole lot as
> the Network Army Knife. Maybe that would make life more complicated for
> Dean though ;)

I haven't read the latest SDK agreement, but given Apple's policy I
don't think you can download *code* to an application via
microtransactions, only content. So unless Dean is satisfied with
bundling all the libraries even for the simplest apps Apple would
never authorise it. And I don't think Dean will take this route.

Cheers,
A.

[Dean]

André, you're right on the money on this one. As (I think) I said
before, I'm not a big fan of "defective by design"
software where I have an iVNC, an iX11, an iSSH and an iRDP and each
one is basically the same app with different "out of the gate"
functionality turned on and each additional protocol available for in-
app purchase.

I absolutely will not abandon my flagship product either. That means
every bit of related functionality that makes it into an ancillary app
(iX11, for example) will be reflected in iSSH. Over the year I
watched another SSH client developer only succeed in angering his past
customers when he forked his flagship app, made his "old" one free and
charged a significantly higher price for a marginal number of
features.

That being said, don't be too surprised if you see an "iVNC" (I know,
horrible names, but strangely not taken yet) appear in the store some
time soon. However, ideally I'd rather concentrate my time providing
support and improving iSSH with the current list of requested
features.

I can't thank everyone enough for their support, criticisms and bug
reports. Seeing a perfect rating in iTunes (as it stands in the US
store now) for this release is more motivating to me than whatever my
sales trend reports are for that day. Hope I can continue to impress.

Dean

[Stephen R. van den Berg]

Four things:

- I like your app.

- Can you please make the backspace key configurable, so that it sends
^H instead of DEL?

- I vote for support for RDP instead of NX. I (have to) use RDP for a
number of servers. NX I tried using, but I dislike the way that the
commercial NX client/servers try to do too much behind the scenes. If
it works, that's nice, if it doesn't, it is rather messy. Besides,
commercially speaking, RDP is the larger market. Changing the name of
the app might be a good idea (make sure the word "remote" is matched).

- You talk about beta releases, where can I get them?

[Stephen R. van den Berg]

Another feature suggestion would be to look at the block/pie menu of
the inofficial Terminal application and see if it looks useful.
Possibly make it configurable what appears where, on which level (it
has multilevel block/pie-type menus).

[André Braga]

On 16 jul, 10:05, Chris Jones <c...@tenshu.net> wrote:
> or you can pre-buy the whole lot as
> the Network Army Knife.

Oops, except that this acronyms to NAK, which is probably the last
name you'd like for a remote network connectivity app ;)

Except if one appreciates the irony of it as a pun.

Remote Army Knife still gets my vote, and I guess Stephan's as well
(welcome!).


Cheers,
A.

[Dean]

Thanks. Yeah, fine-tuned terminal settings are on the to-do list. ^H
in lieu of DEL is one of higher priority items.

I've yet to do anything with NX beyond reading news about it and
finding what technical details I can about the protocol. The core NX
functionality seems less-than-ideally documented so RDP may be first
simply due to better documentation being available about the protocol.

I'll probably release an ad hoc beta sometime today (PDT time), Send
me your UDID directly ( http://www.innerfence.com/howto/find-iphone-unique-device-identifier-udid
) and I'll included you on the list. Watch the forum for my
announcement which should hopefully be by the end of today.

Dean

On Jul 18, 2:28 am, "Stephen R. van den Berg" <bugles...@gmail.com>
wrote:

[André Braga]

Updating the list with the added suggestions so far:

> o   RDP
> o   NX
> o   Embedded Webkit with tunneled connection

> o   SFTP support, to the sandbox even, [combined with]:

> o   A way to fetch and upload files from/to the phone/iPod, perhaps
> via a simple Web server

> o   A document viewer, perhaps with a plaintext editor.

> o   Audio tunneling for RDP, and maybe VNC too via ESD.

o ^H instead of raw backspace; configurable (done?)
o Make Fn accept functions over 1-10. Stick Fn plus numerical keys,
unstick on return
o Secondary "home" panel for the pie menu accessible via 2-finger
touch/hold
o Move the toolbar funcionality to the pie menu, by default to the
secondary pie home; have it contain all the modifiers (esc, ctrl, alt/
option, winkey/command, Fn), forward delete (del), AltGr (and "context
menu" as an option). Consolidate the connection manager keys ("X" on
console, "<" on GUI) into a single entry and put it on the remaining
slot of the secondary pie home.
o Ability to send modifiers raw, currently they must always be
combined to a non-modifier key
o Ability to invoke the pie menu via simple touch instead of hold
o Ability to make either the whole pie menu sticky, or on a per-slot
basis (I'm liking the latter better now). Make direction keys (cursor,
pagination, home/end) sticky by default
o Configurable cursor position for macros, like what MobileTerminal
does
o Emulate missing fonts by using a scaled outline font (should work
okay as a fallback now that hinting was fixed)
o Ability to assign modifiers to gestures; this would require
disabling the multi-terminal switching by swiping, but no
functionality should be lost given the connection manager
o Multiple simultaneous X11/VNC/what-else connections. This one will
be a little tricky, as it will require freezing the current display
server state and buffer any additional messages for the background
sessions. Care to discard older update messages when new ones draw
over the same screen region. Checking what the null X server does
might help, as well as how the NX server maintains state. Not trivial.
o On the same note, a terminal session manager, possibly a front-end
to "screen". Should connect and verify the list of open "screen"
sockets and offer to resume one
o Terminal activity alert
o Screen flash as visual bell instead of shake; configurable. The
shake is cute but grows old after the nth sequential error :P
o Move the "email buffer log" function to the connections manager;
use the OS 3.0 email hook instead of leaving the app
o Tunnel email server connections under iSSH if possible (I don't
believe it is unless localhost is added as the email server and SOCKS
tunneling is added to iSSH)
o So: SOCKS-over-SSH tunelling in general for the embedded Mail and
Web views

Phew. Did I miss anything?

Cheers,
A.

[André Braga]

Of course I missed things...

o Pie menu on top of everything; currently portions of it can get
under the keyboard. But allow it to have portions outside of the
visible screen; with carefully positioned shortcuts this might be
exactly what the user wants for quick and unobtrusive shortcut access
o Because of the above, and one thing that wasn't at all obvious on
my previous discussions of the sticky pie menu, don't unstick it if
the *keyboard* or mouse keys are touched, only some other "free"
portion of the screen
o "Touchpad" mode for mouse control, in addition to the current
"touchscreen" mode
o Support for 3rd mouse button
o Ability to hide the keyboard on vertical mode as well. Yet another
toggle on the pie menu, I guess... Or a swipe gesture.
o As a consequence, translucent keyboard mode for vertical
orientation as well
o Deeper zoom
o Pie menu on the GUI, sticky and repositionable (like the current
"extra keys" window); remember to kill the topmost toolbar to reclaim
screen estate ;)

o A walkthrough when the application is first started to explain all
those wonderful functions and how to access them ;) Special care to
mention how to access the connections menu first of all.


Cheers,
A.

[Dean]

These are all very good suggestions. I certainly have my work cut out
for me. Speaking of which, what's your (and everyone else's) feeling
of priority on these items? Should some take precedence over a
connection organizer?

Dean

> A.- Hide quoted text -
>
> - Show quoted text -

[tsuehpsyde]

I personally think switching the pie to tap and copy/paste to holding down should be a 1st priority, imo. I got it to work on 3.5.6, but it took some guess work as I saw no how-tos anywhere. Still, it was a bit more difficult than other apps with the built-in feature. Still, thanks for adding it in any capacity, will make my SSH work much, much easier. :)

That said, I think there needs to be a Wiki (is there one? if so please link me) as well as announcements on new features as well as new Wiki pages, or at least a "owners manual" of sorts. New features are great so long as you know about them/how to use them. =)

But yeah,  that's the only feature this user really cares about. Switching copy/paste to holding down (adding in the magnifying glass would be awesome) and having tapping the screen become the pie thing. Also, the pie thing either needs to go over the keyboard, or the pie thing needs rendered above the keyboard when clicked in an not-so-great place.

Lastly, is there any reason there's no transparency option for the standard keyboard and only landscape?

Thanks for all you do, Dean! =) Love the app.

[André Braga]

On Jul 19, 8:29 pm, Dean <canada...@gmail.com> wrote:
> These are all very good suggestions. I certainly have my work cut out
> for me. Speaking of which, what's your (and everyone else's) feeling
> of priority on these items? Should some take precedence over a
> connection organizer?

Allright, so here's the list again, reorganised and a little expanded.
I tried to group the tasks logically per similarity or dependencies.
Tasks are not in order of priority per se, but in what I perceive to
be order of impact. By that I mean that first I'm grouping things that
should improve usability and be of immediate benefit to everyone, and
from them on the features that I believe would require more involved
programming.

That said, tackle these any way you like, Dean. The list is here more
to help with documenting the suggestions and fleshing out the
dependencies rather than to provide some guidance of order or demand
that something gets done. Remember that you have the power to veto any
of them, and I'm (well, we all are, I assume) interested in knowing
which of those you liked for real and which you'd rather not take on
for the time being. Then, concentrate on the features and improvements
that resonate with your needs and tastes to build motivation to deal
with the boring tasks :)

P.s.: Well, seems that I just took the role of features janitor :D If
you'd like to contact me directly for anything, for example if you'd
like me to maintain a Wiki page with this list or have me collect and
organise other suggestions and feedback you received on your email or
international App Stores, feel free to.

Cheers,
A.

---------------------------------

== INTERFACE ==
-- 0) Help --
0.1) A walkthrough when the application is first started to explain

all those wonderful functions and how to access them ;) Special care
to mention how to access the connections menu first of all.

-- 1) Mouse --
1.1) "Touchpad" mode for mouse control, in addition to the current
"touchscreen" mode.
1.2) Support for 3rd mouse button.
-- 2) Pie menu --
2.1) Pie menu on top of everything. Allow it to have portions outside
of the visible screen (rationale: with carefully positioned shortcuts

this might be exactly what the user wants for quick and unobtrusive

shortcut access).
2.2) Ability to invoke the pie menu via simple touch instead of hold.
Make the hold gesture enter selection mode.
2.3) Ability to make either the whole pie menu sticky, or on a per-

slot basis (I'm liking the latter better now). Make direction keys

(cursor, pagination, home/end) sticky by default. Don't unstick on
tapping keyboard/mouse keys, only some other "free" portion of the
screen.
2.4) Secondary "home" panel for the pie menu accessible via 2-finger
touch/hold.
2.5) Move the toolbar funcionality to the pie menu; have it contain
all the modifiers (esc, ctrl, alt/option, winkey/command, Fn), forward

delete (del), AltGr (and "context menu" as an option). Consolidate the
connection manager keys ("X" on console, "<" on GUI) into a single
entry and put it on the remaining slot of the secondary pie home.

Works best in tandem with (2.4)
2.6) Pie menu on the GUI mode inside a floating window (like the
current "extra keys" window). Dismissable via the stickyness settings
of (2.3). Depends on and partially supersedes (2.3).
2.7) Consider putting the pie menu inside a floating window for
console mode as well. Doesn't depend on, but uses the same code as
(2.6).
2.8) The middle of the pie menu is a VERY accessible area (zero effort
in Fitts' law) and I believe it's a colossal waste to use it only for
scrolling the pie menu panels. Paginate the pie menu using the same
scheme as the floating window seen on the GUI mode. Depends on (2.6,
2.7).
2.9) Kill the topmost toolbar to reclaim screen estate. Depends on
(2.5, 2.6), and loosely on (2.7)
-- 3) Screen --
3.1) Deeper zoom levels.
3.2) Configurable bell, audible and visual, not mutually exclusive.
Screen flash and shake as visual bell options. Have some tone choices
for audible bell, as well as a mute option.
3.3) Notification system, possibly on a message tray/billboard that
scrolls down from the top of the screen.
3.4) Terminal activity alert. Depends on (3.3).
-- 4) Selection --
4.1) Allow partial selections, currently it always selects whole
words.

== INPUT ==
-- 5) Swipe gestures --
5.1) Introduce swipe gestures as a method of shortcut invocation. This
would require disabling the multi-terminal switching by swiping; but
see (2.5, 9.1).
5.2) Verify whether it's possible to detect two-finger swipe. Depends
on and complements (5.1).
5.3) Visual feedback on the swipe gestures; just draw a line on the
screen that indicates the finger movement and show a notification of
what shortcut/modifier was activated. Depends on (3.3, 5.1).
-- 6) Keyboard --
6.1) Ability to hide the keyboard on vertical mode as well. Depends
loosely on (2.4, 2.5, 2.6, 2.9, 5.1, 5.2)
6.2) Translucent keyboard mode for vertical orientation. Depends on
(5.1).
-- 7) Modifiers and special keys --
7.1) Feedback on the key combination that is sent to the server.
Depends on (3.3)
7.2) Make Fn accept functions over 1-10. Stick Fn plus numerical keys,
unstick on return. Depends on (2.5, 2.7).
7.3) Ability to send modifiers raw; currently they must always be
combined to a non-modifier key. Depends on (2.5, 2.6, 2.7).
7.4) ^H instead of raw backspace; configurable (done?)
7.5) Generalise (7.4) into a more configurable keymap, full with ctrl,
meta, esc and other escapes. Actually, see (c.1) for a more
comprehensive solution.
-- 8) Macros --
8.1) Make it easier to input escape codes when building macros. I like
the way MobileTerminal uses the bullet as a symbol for ctrl, but it
doesn't scale to other symbols like meta and esc, so some other
solution must be found. Borrows from (7.4).
8.2) Configurable cursor position for macros, like what MobileTerminal
does. Depends on (8.1).

== CONNECTIVITY ==
-- 9) Connection manager --
9.1) Revamped connection manager.
9.2) Move the "email log" function to a submenu in the connection
manager. Depends on (9.1).
9.3) Terminal session manager, possibly a front-end to "screen".

Should connect and verify the list of open "screen" sockets and offer

to resume one. Depends on (9.1).

== X11 AND CONSOLE ==
-- 10) Font handling --
10.1) Verify the possibility of reusing the system fonts on the iPhone
OS instead of bundling lots of fonts with iSSH. As soon as Unicode
enters the game, bundling fonts becomes very uncomfortable. Ideally
only fonts that bring real advantages over the system fonts should be
bundled (like ANSI BBS). Seems doable, as MobileTerminal uses system
fonts.
10.2) Emulate missing X11 fonts by using a scaled outline font. Works
best in tandem with (10.1).


+++ WHOLE NEW FEATURES +++
== a) TUNNELING ==
a.1) Embedded Webkit view, so one doesn't need to leave iSSH to grab
something from the web.
a.2) Embedded Mail view, so one doesn't have to leave iSSH to email
logs.
a.3) SOCKS-over-SSH tunelling for the Web view, and if possible also
for the Mail view. I believe the latter is only possible if an email
account is configured to use localhost as the server, which would in
reality only work when iSSH is active to create the a tunnel. Depends
on (a.1, a.2)

== b) DOCUMENT HANDLING ==
b.1) SFTP support, transfer files to/from the sandbox
b.2) A way to fetch and upload files from/to the phone/iPod, perhaps
via a simple Web server; depends on (b.1)
b.3) A document viewer, perhaps with a plaintext editor. Depends
loosely on (a.1), and strongly on on (b.2) and Apple-provided viewers.
b.4) Ability to download and save arbitrary stuff from the web view.
Works best in tandem with (b.2). Depends on (a.1).

== c) KEYBOARD ==
c.1) Do away with the iPhoneOS widget and roll out a custom, fully
configurable one with Unicode support and what have you. iKeyEx 5-Row
Keyboard with cursor keys and numeric keypad for inspiration.
Supersedes (7.4, 7.5).

== d) CONNECTIVITY ==
d.1) RDP
d.2) NX
d.3) Audio tunneling for RDP, and maybe VNC too via ESD. Depends on (d.
1).
d.3) Multiple simultaneous X11/VNC/what-else connections. This one

will be a little tricky, as it will require freezing the current
display server state and buffer any additional messages for the
background sessions. Care to discard older update messages when new
ones draw over the same screen region. Checking what the null X server
does might help, as well as how the NX server maintains state. Not
trivial.

-x-x-x-x-x-

[Dean]

Wow. Awesome work. Now if I could only get as good requirements
analysis done at my day job as well. Really. :-)

Some of this stuff is low hanging fruit and while not as glamorous as
adding a whole new tunneled protocol, will get completed sooner
because I'll typically be brushing over that code anyway. See the ^H
issue and now the Key Pie window positioning and "stickiness" option
(not quite ready for another beta though.)

There's another class of items that are technically easy but require
careful consideration to go into the UI or significant code
refactoring. Letting VNC zoom in further than 1:1 is a trivial item
but the VNC viewer is most efficient when displayed at 1:1 (since no
scaling is required.) Therefore I'd need someway to lock the user
back to 1:1 from whatever zoom ratio they're at (ideally without
having to do a finger dance on their iPhone.)

And then there's the stuff that's hard but will get done as long as
interest is there for it. (RDP is a good example of this.)

And finally there's that class of stuff I like but I'm nervous about.
NX support is in this category. Documentation is scant and the best
I'm finding is the code being the documentation, which means that
unless I have someone read the NX code and convert it to pseudo-code
for me, the Free Software Foundation is going to have a talking to me
about GPL violations.

And that document handler, while it sounded "out there" for a time,
actually starts sounding more and more reasonable particularly in
light of a backup/settings transfer feature.

Back to coding or The Secret of Monkey Island: Special Edition,
whichever I click on first.

Dean

[tsuehpsyde]

While RDP would be nice, it's not essential. At least not for me. =) I did buy an SSH client, not a Windows RDP client, fwiw. I say fix the core SSH stuff, add new fancy remote administration features for other platforms once the core one is pretty close to "good". Just my 2 cents.

[Jocke Selin]

On 20 Jul 2009, at 06:10, tsuehpsyde wrote:
> While RDP would be nice, it's not essential. At least not for me. =)
> I did buy an SSH client, not a Windows RDP client, fwiw. I say fix
> the core SSH stuff, add new fancy remote administration features for
> other platforms once the core one is pretty close to "good". Just my
> 2 cents.

I'm agreeing to this. SSH is what I'm using (no graphical stuff at
all). Anything that makes the SSH stuff more useable is of huge value
for me. Such things are tabbing, arrow keys, copy-paste, zooming,
scrolling, session switching, etc.

Just my £0.02.

/JS

[André Braga]

On 20 jul, 02:07, Dean <canada...@gmail.com> wrote:
> Wow.  Awesome work.  Now if I could only get as good requirements
> analysis done at my day job as well.  Really.  :-)

So where do I send my résumé? :D

> Some of this stuff is low hanging fruit and while not as glamorous as
> adding a whole new tunneled protocol, will get completed sooner
> because I'll typically be brushing over that code anyway.  See the ^H
> issue and now the Key Pie window positioning and "stickiness" option
> (not quite ready for another beta though.)

That's the spirit! Reap the lower hanging fruit and while you're at it
revamp something here and there. Having a roadmap of sorts that's
organised by area really helps at those times. Good Mac (and iPhone,
as I'm observing) software is usually born from the combination of
scratching an itch, having a team of smart people suggest ways the app
could grow while not losing its sense of identity and purpose, and
great interface design. I believe you have all your bases covered
now :)

> There's another class of items that are technically easy but require
> careful consideration to go into the UI or significant code
> refactoring.  Letting VNC zoom in further than 1:1 is a trivial item
> but the VNC viewer is most efficient when displayed at 1:1 (since no
> scaling is required.)  Therefore I'd need someway to lock the user
> back to 1:1 from whatever zoom ratio they're at (ideally without
> having to do a finger dance on their iPhone.)

A shake gesture is perfect for those situations where you want to
reset the terminal or the GUI to a default state, like zero
coordinates and 1:1 zoom. And for the console it could map to soft
reset on first shake and hard reset on two sequential shakes. Which
would be a good addition, since it's only too common to cat a binary
file by accident and have the terminal go bananas...

> And then there's the stuff that's hard but will get done as long as
> interest is there for it.  (RDP is a good example of this.)

There is, plenty. But take your time, don't rush it. As you build the
foundation widgets it's going to be a matter of implementing the
protocol per se.

> And finally there's that class of stuff I like but I'm nervous about.
> NX support is in this category.  Documentation is scant and the best
> I'm finding is the code being the documentation, which means that
> unless I have someone read the NX code and convert it to pseudo-code
> for me, the Free Software Foundation is going to have a talking to me
> about GPL violations.

Well, there must be some headers that defines the protocol itself. You
might have noticed by now that I'm a programmer too, only with zero
experience with programming for the iPhone OS. Perhaps I could lend
you a hand at this.

> And that document handler, while it sounded "out there" for a time,
> actually starts sounding more and more reasonable particularly in
> light of a backup/settings transfer feature.

Clairvoyance 2.0 ^^

> Back to coding or The Secret of Monkey Island: Special Edition,
> whichever I click on first.

Hmf. They should have made a Wii version :P


Cheers,
A.