Do

Provide Reusable Terminal Interface to Plugins

Registered by Armin Ronacher on 2008-11-11

Because many users use different terminals than gnome-terminal a more flexible terminal plugin that can detect the terminal in use automatically should be implemented.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Armin Ronacher
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Not started
Milestone target:
None

Related branches

Sprints

Whiteboard

Right now the only way for gnome-do to start a terminal is the GNOME-Terminal plugin. This is hard coded to only support gnome-terminal, but in a nice fashion (that is profile support, running terminals in given folders, running commands in terminals etc.)

Of course it would be possible to write a Konsole, XTerm etc. plugin so that each terminal emulator is covered, however that would unnecessarily make the whole thing more complex and leads to code that's harder to maintain.

Furthermore some other plugins want to open terminals as well, so these would have to figure out which terminal to start (for example the SSH plugin that connects with a the standard gnome terminal emulator right now).

I guess the best solution for the problem is dropping the GNOME-Terminal plugin and implementing a generic Terminal plugin that just talks to a "terminal-abstraction" layer, somewhere in the Do core.

This layer would have to implement the following methods:

Terminal.Open(string working_directory) -- open a terminal in a given working directory or the default one if the string is null.

Terminal.RunCommand(string command) -- run a command in the terminal.

This of course would drop the profile support for the terminals. The question is if profiles are actually something you want to use from the command line. For terminals that support profiles it would still be possible to implement profile support as a separate plugin (For example a GNOME-Terminal-Profiles plugin that supports opening a terminal with a specific profile).

Selecting the Terminal:

The method to find the active terminal should check the gconf key for the terminal first. If that one is not set (gconf not available?) it could try to fall back to xgd-terminal if available, otherwise gnome-terminal or xterm.

Supporting Terminals:

All terminals support the "-e" parameter. The argument that follows this parameter is executed in a new shell. This could be used instead of the current "-x" parameter that is only supported by gnome-terminal. Starting a terminal in a given directory should work for all graphical terminals as well if StartInfo.WorkingDirectory is set properly.

For the icon it's probably okay to use the "gnome-terminal" stock icon, even though a different terminal may be in use. Figuring out the correct icons for terminals is an unnecessary complexity that doesn't give you much.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.