UBUNTU 14.04/16.04 resolution

I too had been having this octave command window problem using both Ubuntu 14.04 and 16.04: Octave works fine when launched from the console, but remotely using Putty (with X forwarding) or ssh -X, the command window is blank. 

I was able to resolve the problem comparing the shell environments (printenv) from my ssh -X session (resulting in octave command window blank), and that from my console (octave command window visible).

The minimal environmental change that I required to get octave to function under ssh -X (or Putty with X forwarding) on a Ubuntu 14.04 or 16.04 system are below.  These changes may be added to the configuration script .bashrc, but their impact on other X applications has not been evaluated.

export GTK_MODULES=gail:atk-bridge:unity-gtk-module
export GNOME_DESKTOP_SESSION_ID=this-is-depricated

-William

I could reproduce the bug with a third machine, also running
openSUSE 13.1. ssh-ing into my desktop machine and running octave gui, or ssh-ing into the server machine and running octave gui reproduced the bug. I also tried connecting from my desktop to the third machine - the same thing happened. I updated all three machines to octave 3.8.2 (from 3.8.1) and tried everything all over again, but the problem persists. The TERM variable is xterm in all three cases and I could not see any errors logged in /var/log/messages or Xorg.0.log.

Finally, I tried using octave on the server from a fourth machine, this one running openSUSE 12.3 (i586). The problem persisted.

No luck reproducing the issue on a CentOS 5 X client.

I even brought up an Octave instance on both machines at the same time, forcing the TERM variables to be identical (xterm-256color), and looking at the environment before running octave. I doubt there is anything interesting here, but FYI, here's the dump from the Mac session:

XDG_SESSION_ID=19
COMP_WORDBREAKS=
"'><;|&(:
TERM=xterm-256color
SHELL=/bin/bash
XDG_SESSION_COOKIE=38987f7e1ebf3d2a0c1f716a5165ac9c-1423245494.805414-1292460863
SSH_CLIENT=65.36.82.183 50128 22
SSH_TTY=/dev/pts/8
USER=mcgrant
MAIL=/var/mail/mcgrant
PATH=/opt/octave/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
QT_QPA_PLATFORMTHEME=appmenu-qt5
PWD=/home/mcgrant
LANG=en_US.UTF-8
SHLVL=1
HOME=/home/mcgrant
LOGNAME=mcgrant
SSH_CONNECTION=65.36.82.183 50128 171.64.92.38 22
XDG_RUNTIME_DIR=/run/user/1006
DISPLAY=localhost:12.0
_=/usr/bin/env

For whatever its worth, I did one more test:

I tried connecting to the same server with ssh, then reconnecting to my desktop machine via ssh and running octave. So now I had my own desktop running it (version 3.8.1 this time), but tunneling the output there and back to the other machine. The bug showed up just as it had before - the command window was empty, but everything else was functional.

Yes, the problem persists with version 3.8.2

I tried switching fonts in Preferences, but it didn't help.
I also tried redirecting the errors by launching with the command:
octave --force-gui &>errs.txt
but the file remained empty.

I tried to build a version from the development sources, but I did not succeed. First I had various libraries missing, which I could fix easily. Then libraries for openGL and Qt were not located by the configure script (though some were installed), so I added some more I thought may help. Eventually the configure script did mark the GUI for compilation, but the process stopped with an error.
I have attached the output of the configure script and the
last few lines of the output that make produced.

The problem is, that there are a lot of Qt and openGL related packages that I can install from the opensuse repositories and I am really confused about what is necessary, what is unnecessary and perhaps what is outright detrimental. If you can give me tips on what I should install and what not, I'll give it another shot.



(file #33017, file #33018)

@Gabor: Your report is interesting because if the ssh session was between two identical Linux systems there really shouldn't be an issue.  Is there still a problem for you today with 3.8.2?  And do you have the ability to build a version from the development sources in Mercurial?

The GUI command window is running a terminal emulator and it needs to know what kind of terminal to strive for.  On my Linux machine, the TERM variable is set to xterm, and everything works fine.  If I set the TERM variable to aquaterm in my .tcshrc file then tcsh complains and falls back to using "dumb terminal settings".  When I run the GUI with this set-up I still get text displayed, but when I type 'ls' I get 'WARNING: terminal is not fully functional'.  

So the terminal is important, but I don't know if that is the real problem here.

There is an acceptable workaround so I'm not going to require that this be fixed ahead of the 4.0 release (http://wiki.octave.org/Bug_Fix_List_-_4.0_Release).

Other things you might play with, is it just a color issue of white text on white background?  You might try changing the preferences for colors in the Terminal tab of File->Preferences.

There might also be some environment variable about the terminal that needs to get set when running cross-platform.  For instance, the TERM variable seems to be forwarded from the client to the server.  But that won't work well if your client is a Mac and has a terminal like aquaterm.  The Linux server wants something like xterm or vt100.

See http://earthwithsun.com/questions/725853/what-environment-variables-are-set-when-i-use-ssh.

I'm afraid this one's a bit of a challenge because it's a remote machine I don't have local access to. I'll see if I can reproduce this with a Linux X11 client.

Running --no-gui-libs works fine, including the plot command, which again doesn't surprise me given that all other windows work.

Good idea about the stable version. I don't have access to 3.8.2, but I did install 3.8.1 from using apt-get. It looks like the same problem occurs there as well.

I'm afraid not. More details:

- the cursor appears in the top left corner of the window. (as shown in the screenshot). I changed the cursor type and color, and it was updated properly.
- I also tried keeping the window docked but separated from the editor & documentation.
- Changing the colors doesn't seem to matter.

Indeed, given that the cursor remains in the proper place, it seems like the failure is not in rendering, but in the delivery of the text to the window.

I checked out the Mercurial repo, bootstrapped, and built on 64-bit Linux (Ubuntu 14.04.1 LTS). Compilation proceeded without incident.

To test, I executed ./run-octave over an SSH connection with X forwarded to my local machine (Mac OSX 10.10.2, Xquartz 2.7.7). The command window is blank, no matter whether it is docked or undocked. It still accepts input, however. All other windows seem to render properly.

Attached is a screenshot. I typed blind, and ran some code that generated a couple of plots, so you can see that the directory, history, workspace, and plot windows all render properly. If you'll take my word for it, the editor and documentation windows work fine too.