Toronto

I moved to Toronto to start my Ph.D. in department of computer science at University of Toronto.

For my recent academic activities, please refer to my homepage.

Gnome-Screen: Integrated Gnome Terminal and GNU Screen

The integration part between gnome-terminal and screen program is done. Now any command/data can be transfered between screen, vte, and gnome-terminal.
Here are some screen shots:

1) Creating a new screen session

2) Create a new screen tab:

This will generates a new screen session in a new tab.

The last updated source/patch files are available at:

• gnome-terminal patch file
• vte patch file
• screen patch file
• gscreen.c
• gscreen.h (updated)

Scrollable screen

Finally, scrollable screen is out. #:-S ! Here is a screen shot:

As shown, a GNU Screen program is loaded inside vte and scrolling the screen content is transparent to vte. Scrolling is done using my implemented functions in screen and the pipe protocol described in gscreen design.

Source/Patch files:

• vte patch file
• screen patch file
• gscreen.c
• gscreen.h

There are some minor updating issues, specially when the content is selected by mouse, that I’m working on.

Toward gscreen

In order to use our pipe protocol described in gscreen design, a number of functions has been implemented in screen code so far:

•  :new (generates a new screen session)
•  :switchTo n (switches to screen session number n)
•  :showWindows (returns a list of current screen sessions)
•  :copy (enables copy mode, and returns the marked data)
•  :paste data (pastes the data in current screen session)
•  :scroll +n (scroll down n lines)
•  :scroll -n (scroll up n lines)
•  :scroll n (go to line n in scroll buffer)
•  :getlinedata n (returns the content of line n of scroll buffer)
•  –control-fds = fdnumber (adds the fdnumber to the list of fds that screen listens to their events)

The Gobject based gscreen class is implemented too. In this class two pipes are created, one from g-t/vte to screen and the other from screen to g-t/vte. The pipes are created in the gscreen_session_fork_command method and after that screen program with –control-fds option equal to created pipes is forked. gscreen will be called inside vte_terminal_fork_command in vte.c file.

I’ve hacked g-t a little bit and added a new menu item called “New screen Session”. By clicking on it, a new screen session , using our pipe protocol and :new command, will be generated.

An animation of screen’s usage

These days I’ve been looking at most of the webpages that have some info related to screen program. I found this animation very interesting:

Source

gscreen design

In order to make screen and gnome-terminal communicate with each other, we first decided to change the screen program’s code to expose a library interface. However since:

1) screen’s code is old fashioned. i.e. it has many global variables which is not desirable for a shared library and

2) screen and g-t are under different licenses.

It is not feasible to make the screen program as a shared library object.

Thus we decided to have a third program as the messenger between g-t and screen. ”Pipes” (or file descriptors) are going to be used to read/write commands from/to screen. 

The flow would be:

When g-t is loaded, it will create an instance of screen with the pipe fd as its parameter. Screen would be modified so that each time a command is written to the pipe, it would react properly.Each terminal would have one instance of the screen fd. Each screen fd can have multiple sub-screens.

To make the pipe bidirectional we actually need two file descriptors:·  

screen –> g-t for:

o        Scroll back buffer contents,

o        Copy,

o        Get current screens,·

g-t –> screen for:

o        Create a new screen,

o        Switch screen,

o        Search,

 o        Paste,

o        Show tab for current screens

Notes: 

Semaphores will be used to prevent deadlock.

A protocol is also needed to make the communication happen.One endpoint of a pipe will write a command to it, the command will be read and interpreted by the other endpoint and proper reaction would be performed.

Protocol initial design:·

:newScreen  options (readonly/writeonly) \r\n· 

:switchTo  screenID \r\n·        

:copy numberOfChars \r\n data data ….data \r\n·

:paste numberOfChars \r\n data data … data \r\n·        

:find searchLiteral \r\n·        

:getScreens \r\n·        

:showTab screen1 options \r\n screen2 options \r\n  …

(To send commands to screen ‘-X’ option can be used.) 

Ottawa Linux Symposium

I spent last week at OLS. It was GREAT.I had the chance to work on my project’s design issues with the help of my two incredible mentors: Behdad and Kosai.  The most useful part for me was the tutorial sections. Here is the list of talks that I enjoyed: 

• Write a real, working Linux driver
  • I’m still playing around with my USB device.
• A Step by Step Introduction to Writing a Linux Filesystem
• Debugging Linux kernel using Kdump
  • If Kosai wasn’t there, I wouldn’t have understood much!
• Xen 3.1 and the Art of Virtualization
  • Very interesting.
• GIT – A Stupid Content Tracker
  • Well presented.
• I’d love the idea behind Reverse Engineering USB Drivers
• There was a BOF about Women in Linux: Speed Mentoring in which they “made” all the participants (including students and mentors) to talk to each other for about 10 minutes (not less, not more !). I met great mentors there.
• Why Userspace Sucks – (Or, 101 Really Dumb Things Your App Shouldn’t Do), I recommend everyone to read the abstract here. I’ll try to get the slides too.
• Wow:  3 myths, 2 lies, and 5 truths about Linux kernel development.

 P.S.1. I have slides and sample code for the first three tutorials. Please contact me if you wish to receive a copy. 
P.S.2. Ottawa is very beautiful in summer. Here is a picture of Parliament Light Show.
 

Kosai: If you want high quality picture, please let me know.

Progress in screen code

I’ve been looking at GNU screen’s code yesterday. As behdad has mentioned already, the source code is not modular and there are many global variables.

One of the goals of my project is to have a menu of current screen sessions that choosing one will attach the terminal into it. There are some images in bug page regarding this feature and I’m uploading one.

I modified the code to add my own escape character (ctrl+a j) to show a list of current screens (like ctrl+a w). While the list of screens is shown, if user enters a number between zero and number of screens -1, the program will attach the terminal to that screen (like ctrl+a index of screen). In other words, in current screen program if user wants to attach the terminal to another screen, there is a need for crtl+a w and then ctrl+a index of that particular screen. Using my new escape character ,ctrl+a j, the user sees a list of current screens and can enters the index of screen to attach the terminal to it right away (saving one ctrl+a ). This is a very simple illustration of this part of my project without menus of course, but helps me to go through screen code without worrying about integration with g-t. (Coding didn’t take more than half an hour actually but digging screen code to find where everything is took more time). For adding menus I plan to look at GTK library and gnome-terminal code. 

I also realized that the version of FC5’s screen program and the one I checked out from GNU csv are different. I mentioned it to behdad though and he believes it’s OK.

As a side note: In the project’s wiki page there are separated items/goals marked as easy and hard and it’s been said that those marked hard need g-t to communicate with screen. I think this is also the case for that first item that I’ve been looking at which is marked easy. Also I would suggest to change the easy/hard notion to something more self explanatory (like interacting/non interacting or integrating/non integrating ?? ).

I’m trying to make screen code a neat and software engineered code   then we make it as a shared library object and it will expose a library interfaces to be called in vte/g-t.  

Discussion

(08:17:58 PM) Behdad Esfahbod: Kosai, Monia: I was thinking today, a great way to make the screen integration happen
(08:18:12 PM) Behdad Esfahbod: Kosai, Monia: is to develop screen to expose a library interface
(08:18:31 PM) Behdad Esfahbod: that should be /very/ easy, and makes all the hard items in my list very trivial
(08:21:42 PM) Kosai: Ooh.
(08:22:25 PM) Behdad Esfahbod: Kosai: so, you just call screen_session_show_screen_number (session, 4) to switch to the fourth tab
(08:22:46 PM) Behdad Esfahbod: which is just what the magic keybindings are doing right now
(08:23:00 PM) Behdad Esfahbod: nothing to implement in screen, just expose them.
(08:23:14 PM) Monia: right
(08:24:04 PM) Kosai: Woo.
(08:24:27 PM) Behdad Esfahbod: so we don’t have to do any magic in vte/g-t to send control sequences to screen to change to another tab
(08:24:47 PM) Behdad Esfahbod: (which is possible in the case of tab switching, but not for copy/paste, search, …)
(08:25:10 PM) Kosai: Yup.  Sounds perfect.
(08:25:17 PM) Behdad Esfahbod: in the long term, if that looks robust enough
(08:25:26 PM) Behdad Esfahbod: we can tear the scrolling support off vte
(08:25:52 PM) Behdad Esfahbod: and since screen allows for attaching to a session (readonly / readwrite), we get model/view separation for free
(08:26:04 PM) Kosai: And have a hard dep on screen?
(08:26:07 PM) Behdad Esfahbod: yeah
(08:26:13 PM) Kosai: Cool.
(08:26:13 PM) Behdad Esfahbod: that’s for the long term
(08:26:50 PM) Behdad Esfahbod: screen is probably a lot smarter than g-t in handling odd sequences
(08:27:01 PM) Behdad Esfahbod: so we are just piggybacking on it
(08:28:43 PM) Kosai: Sounds like we get to ditch a lot of g-t code.
(08:30:03 PM) Behdad Esfahbod: not g-t really, vte mostly.
(08:30:17 PM) Behdad Esfahbod: kinda “use screen as a backend” feature in vte
(08:30:24 PM) Kosai: right.
(08:30:30 PM) Behdad Esfahbod: that’s of course for the “implicit” part
(08:30:39 PM) Behdad Esfahbod: for explicit, we need some menus in g-t
(08:31:16 PM) Behdad Esfahbod: but if we go that route, then g-t doesn’t really have to create new widgets for each tab
(08:31:21 PM) Behdad Esfahbod: and can use screen’s tab support
(08:31:29 PM) Behdad Esfahbod: but that may not be feasible
(08:31:40 PM) Behdad Esfahbod: maybe as long as tabs are using the same profile
(08:32:14 PM) Behdad Esfahbod: or better yet, we can add the notion of tab into vte itself
(08:32:32 PM) Kosai: Yeah, gets confusing if the user has some local terminals (implicitly inside screen) and some remote ones inside a non-vte screen.
(08:32:57 PM) Behdad Esfahbod: yeah, got to decide what to do there
(08:34:55 PM) Behdad Esfahbod: in the mean time we can actually import our hacked screen in vte
(08:35:04 PM) Behdad Esfahbod: so, no dependency, no upgrades
(08:35:22 PM) Kosai: Hm.
(08:35:43 PM) Behdad Esfahbod: and when we are satisfied with the screen api, we can start pushing it upstream
(08:36:05 PM) Kosai: *nod*

July 09

http://live.gnome.org/GnomeTerminal/ScreenIntegration