Created attachment 50689 [details] [review]
Patch that adds connect to server dialog.

Created attachment 50691 [details]
Window icon used when terminal is connected. Rename to gnome-terminal-connect.png

Place in src dir. Someone with more graphics-fu then me needs to come up with
something better.

Created attachment 50692 [details]
Screenshot showing new menu entries.

Created attachment 50693 [details]
Screenshot showing connect dialog with some servers.

Servers with the network stock icon to the left are servers that have been
discovered via Zeroconf. Servers with a lock icon are partially or completely
locked down by the system administrator and can't be removed by the user.

Created attachment 50694 [details]
Screenshot showing three servers beeing edited.

A Zeroconf server, a server partially locked down by the administrator and a
server created by the user with "Optional Settings" expanded. The Zeroconf and
partially locked servers have text in their dialogs explaining why all settings
can't be edited. All according to the HIG
http://developer.gnome.org/projects/gup/hig/2.0/controls-sensitivity.html#controls-locked
.

Created attachment 50695 [details]
Screenshot showing a terminal tab connected to a server.

Notice the connect icon to the left of the tab label, also recommended by the
HIG
http://developer.gnome.org/projects/gup/hig/2.0/controls-notebooks.html#controls-tab-status
, and that the window icon has changed to indicate that you are connected.

Other nifty things worth mentioning:

* Customizations made to Zeroconf servers are remembered so you don't have to do
it all over again when they reappear.

* Changing encoding/profile in the menu while connected will update the server.

* There is a --connect-to-server argument that brings up the connect dialog.
This makes it possible to have a "Remote Terminal" entry in the Applications
menu (though I feel it adds clutter) or an icon on your panel.

* There is a "Add or Remove..." entry in the encoding combo-box and a "Edit
profiles..." entry in the profile combo box.

* The state of the Optional Settings expander is remembered

* Server being edited and has it's name changed is scrolled to if it moves out
of view in the connect dialog.


Open issues and stuff we might do (feel free to chip in):

* Why doesn't pressing return in the connect dialog activate the connect button
even if has_default property is set to true?

* Height of window is decreased when connect icon is added to a tab.

* "connection refused" etc from ssh/telnet isn't always outputted (VTE bug?)

* Would be nice if "Connecting to <server>..." och "Disconnected from <server>"
was printed in the terminal. I don't know how to output text without it being
fed to the child though.

* Nicer gnome-terminal-connect.png icon (I'm no good at this).

* Documentation (another weakness of mine).

* --geometry etc. (not all of them makes sense to pass on) is ignored when using
--connect-to-server

* Integration with gnome-keyring (don't know if this is a good idea).

* 100% CPU when starting gnome-terminal, opening a second tab with the menu,
closing the first tab and connecting to server. Nothing is outputted to the
terminal. When the terminal widget is clicked, cpu usage goes back to normal and
output is placed in terminal. If first terminal is left open everything works
fins. I suspect this is a VTE bug. Would appreciate help with tracking this down.

* When a profile is created in the profile editor the profile list is
temporarily set to contain only the newly created profile (see
new_profile_response_callback in terminal.c). The result is that all servers
that are being edited have their profile set to that profile. This also has
other implications not related to this patch. Is this a feature or a bug? Was
stuff like this the intention behind the temp. change? If not, I'll file a
separate bug.

Not sure if this is the best way to integrate this. Seems to have some overlap
with the profiles. CC'ing usability.

Hum, overlap with profiles? Not really. The only thing that's really overridden
in the profile is the execution command and what to do when the command exits.
The modifications to title and window icon doesn't override what's in the
profile since they are set as dynamic.  But conceptually, profiles and servers
aren't even remotely the same thing. At least that's how I look at it. :)

Some time way, waaaaay, back I remember there was a discussion to add the GNOME
Network Remote Shell utility to the desktop. But having it directly in the
terminal allows for a level of integration not possible if it's put in a
completely separate program. (I also believe that was one of the reasons it
wasn't included.)

Could you please be a bit more specific about the overlap you are talking about?

Btw, I would like to hear from some usability people what they think about
always connecting in the current window/tab. I tried some different approaches
(always current window/tab, always new window, combo box in connect dialog to
select new window, new tab or current).

As the HIG says in table 4.1 [1]:

"[The File->Open menu item ...] Opens an existing document in a new window.
Present the user with a standard Open File dialog from which they can choose an
existing file. If the chosen file is already open in the application, raise that
window instead of opening a new one."

Really only the first sentence applies here, but the general concept is the same
- you open something.

Anyway, I'm not sure this behavior is consistent even among GNOME applications.
How does Epiphany behave (I'm not in GNOME at the moment, so I can't check) ?

1: http://developer.gnome.org/projects/gup/hig/2.0/menus-standard.html#the-file-menu

I don't know how pertinent the comparison to the Open menu item is.

The most "object oriented" and spatial thing to do, I think, would be to open
each server in a new window and save the size of the window in the server when
it's closed etc. But I don't think that fits in with how many people use the
terminal (often one window with many tabs).

And yes, this very much involves the "tabs is a band-aid for shortcomings in
window management" debacle we all have come to love and appreciate so much. :)

I added some comments about encoding in profiles vs servers to bug 108711
(comment #24 and #25). 

Basically, if the use case in mind when adding encoding to profiles is "because
I connect to ssh/telnet servers with different encodings", it's IMHO _much_
better suited in something like the server editor dialog in this patch.

I agree with that. It's more of a per-server than a per-profile thing.

Gah, wanted to modify comment #2 to add that the name of the icon should be
gnome-terminal-connect.png .

I'll stop spamming you now... sorry :(

Guess we have similiar aims: Bug 332148.

I plan to update this patch against CVS in two/three weeks with some of the issues mentioned in comment #7 fixed, use of Avahi directly instead of gnome_vfs_dns_sd_*(), break out some code into server.[ch] etc...

It would be nice to get some feedback and to know if there's a chance to get this integrated so I don't do all this work for naught. ;)

In response to bug 332148 comment #23:

Humm... if you remove the part that creates connect-to-server.[ch], modifies the Glade file and GConf schema the patch is actually pretty small and not that invasive at all IMO.

I guess there could be a point in breaking it up in smaller patches (one that adds the encoding argument to terminal_app_new_terminal(), one that creates the new files, one that modifies the Glade file, one that modifies the GConf schema etc, one that adds the menu entries etc)... but that's much more work for something that's fairly contained in two new files (four when I've broken out the Server "object" to server.[ch]). I am willing to do that work if that's what it takes to get the patch accepted though.

(In reply to comment #17)
> It would be nice to get some feedback and to know if there's a chance to get
> this integrated so I don't do all this work for naught. ;)

As an end user, I'd love to have this feature. The Mac's Terminal.app has this and it is quite useful.

Out of curiosity, why do you plan on using Avahi directly rather than GNOME VFS?

When I put it in the todo I guess I had the notion that using Avahi directly was the general direction in which things where going... that was a long time ago and I'm not so sure any more...

But it's worth thinking about. I.e. what's the recommended way to add zeroconf support in GNOME in general? Do you want to pull in all of gnome-vfs just for this? (gnome_vfs_get_mime_type() is also used in the terminal so gnome-vfs is already pulled in. But isn't there something similar in glib? If there isn't there should be... ;)

I'll leave it as is (gnome_vfs_dns_sd_*()) for now.

Bug 319597 talks about xdgmime and glib. Only mentioning it here since it might be relevant when it comes to if gnome-terminal should depend on gnome-vfs or not.

Don't see a reason for avoiding GNOME-VFS.

Ping. Any plans to integrate this niftyness?

I have dropped it since there was no reply whatsoever from the maintainer when asking (once or twice on IRC and maybe once or twice via email) if he was interested (wanted to know if it was worth syncing and improving the patch). Not even a simple "yes" or "no".

I've worked on and off on a completely new terminal since a couple of months back but it's on my low (very much so) priority list so I don't even know if I'll ever release it. Maybe this summer, who knows.

Oh well, keep it open if you want.

I changed the title since I don't necessarily think always bringing up a dialog is the best way to go.

I also think most of the patch needs to be refactored (create a proper Server class (or at least create server.[ch]), separate the dialogs from the "model", don't use GNOME vfs, create names automatically and move the Name entry to optional settings, don't duplicate glade code, etc etc...)

<rant>
I now also agree somewhat with comment 8. But my solution to that problem would be to ditch profiles completely (seriously, how common is it with more than one profile?) and at the same time remove many of the useless settings while I'm at it (people who really care which side the scrollbar is on can use their old terminal :). But I imagine that would be pretty hard to get through so I won't even bother.
</rant>

Btw, can someone also mark all the attachments as obsolete? I don't think I'm allowed to do that (or at least it isn't immediately obvious how to do it).

Will this ever be integrated with Gnome Terminal? I'm looking for a solution for having to always switch encoding of my GT each time I connect to my FreeBSD server. This kind of saved remote sessions is a nice idea and wouldn't interfere too much with the standard way of using GT.

I would like this feature implemented/committed. I currently manage over 30 servers and use multiple tabs to navigate thought each server. I always have to open a new tab, rename it to show the server name and then fire up ssh to connect to the desired machine. Having this done with a mouse click would be beneficial and time saving.

I've pitched the idea of ssh integration to downstream projects (ROXTerm, which uses VTE):
https://sourceforge.net/tracker/?func=detail&aid=2810009&group_id=124080&atid=698431

and just ran across this ticket.

What I don't follow from the prior discussion is why this feature was so closely tied to auto-discovery. It seems like that would be a "nice to have" incremental feature to be added later, after basic ssh integration is accomplished.

Can the prior work be reduced in scope to cover just the ssh integration aspect (with manual configuration)? Might that increase its chances of getting accepted into the trunk?