Changes in colorscheme handling about qtconsole

[joonro]

It seems that the way you pass those arguments changed in jupyter4.

Instead of c.IPythonQtConsoleApp.stylesheet, use c.JupyterQtConsoleApp.stylesheet, and instead of c.IPythonWidget.syntax_style, use c.JupyterWidget.syntax_style in your ~/.jupyter/jupyter_qtconsole_config.py file. The stylesheet should be applied correctly.

[anntzer]

Actually, I had already made this change, and this is not enough.

[anntzer]

Note that the docs page at http://jupyter.org/qtconsole/stable/#colors-and-highlighting are quite wrong now -- there is the same issue of illegible backtraces with the pygments builtin schemes used as an example (so it's not an issue with zenburn); moreover, jupyter qtconsole -h does not print out a list of pygments style names, and the %colors magic is no more (if I understand correctly).

[anntzer]

Kindly bumping the issue.

[minrk]

The issue is that it is now separate configuration how IPython colors its tracebacks and how the qtconsole colors what it's in control of. The problem stems from the fact that IPython hardcodes the colors of outputs, which it shouldn't. The InteractiveShell.colors = "linux" configuration in IPython changes IPython's coloring to expect a dark background (%colors linux at runtime). This is the same as picking a dark or light background in your terminal emulator - IPython doesn't know what color the terminal is, you have to tell it what colors to produce. QtConsole is a peer of the terminal emulator in this regard, and IPython must be told what colors to send.

QtConsole could use a different ANSI color table when the background is dark. That might alleviate the situation somewhat.

[anntzer]

I don't know much about the architecture here but perhaps it would make sense for the kernel to output some kind of markup'd text and let the frontend use that markup for coloring?

[anntzer]

OK, I made some progress there, and found that this is actually a PyQt4 vs PyQt5 issue.
Basically, JupyterWidget._style_sheet_changed (called also at the beginning, when the style sheet is set) calls AnsiCodeProcessor.set_background_color with the new background color; if the background color is "light" (V <= 127) then "bright" colors are folded into "normal" colors (which sounds reasonable).
The background color is obtained via bg_color = self._control.palette().window().color(); unfortunately, when the backend in PyQt5, this returns white (which is interepreted as a "light" color and thus disables "bright" text) instead of the actual background color. Not sure why, though.

[anntzer]

On a related topic, it would be nice to indicate how the config items JupyterQtConsoleApp.stylesheet and JupyterWidget.style_sheet interact. It seems that they are basically interchangeable (except that one takes a path and the other the file's contents, until one chooses to embed the QtConsole in a Qt app; then JupyterQtConsoleApp.instance(config=config).init_colors(widget) only uses JupyterWidget.style_sheet.

[ekipmanager]

Hey guys, is there any workaround of this? I have the same problem and whatever I tried in both jupyter config and ipython config, I was still not able to tell the AnsiCodeProcessor to use dark background. I have c.InteractiveShell.colors = 'linux' in ipyton_config file and c.JupyterWidget.syntax_style = "monokai" in jupyter but that does not help. Is there anyway to call self._ansi_processor.set_background_color(bg_color) with a dark color (basically with an ibject that has a .value() method that returns some number less than 127) in any of the config files?

[wmvanvliet]

@anntzer @ekipmanager can you help me test PR #195? Does it fix the issue for you?

[anntzer]

FWIW I cannot reproduce the issue locally anymore -- not sure why, though.

[wmvanvliet]

@anntzer are you running qt4 or qt5?

[wmvanvliet]

@anntzer more importantly: do things still work fine for you after merging #195?

[anntzer]

qt5, and yes.

[ekipmanager]

@wmvanvliet Sorry for the delay. I checked and it solves my problem. I rolled back to the current master and the problem was back again so this PR is definitely working 👍