Show More
@@ -1,331 +1,341 b'' | |||
|
1 | 1 | .. _qtconsole: |
|
2 | 2 | |
|
3 | 3 | ========================= |
|
4 | 4 | A Qt Console for IPython |
|
5 | 5 | ========================= |
|
6 | 6 | |
|
7 | 7 | We now have a version of IPython, using the new two-process :ref:`ZeroMQ Kernel |
|
8 | 8 | <ipythonzmq>`, running in a PyQt_ GUI. This is a very lightweight widget that |
|
9 | 9 | largely feels like a terminal, but provides a number of enhancements only |
|
10 | 10 | possible in a GUI, such as inline figures, proper multiline editing with syntax |
|
11 | 11 | highlighting, graphical calltips, and much more. |
|
12 | 12 | |
|
13 | 13 | .. figure:: ../_static/qtconsole.png |
|
14 | 14 | :width: 400px |
|
15 | 15 | :alt: IPython Qt console with embedded plots |
|
16 | 16 | :align: center |
|
17 | 17 | :target: ../_static/qtconsole.png |
|
18 | 18 | |
|
19 | 19 | The Qt console for IPython, using inline matplotlib plots. |
|
20 | 20 | |
|
21 | 21 | To get acquainted with the Qt console, type `%guiref` to see a quick |
|
22 | 22 | introduction of its main features. |
|
23 | 23 | |
|
24 | 24 | The Qt frontend has hand-coded emacs-style bindings for text navigation. This |
|
25 | 25 | is not yet configurable. |
|
26 | 26 | |
|
27 | 27 | .. tip:: |
|
28 | 28 | |
|
29 | 29 | Since the Qt console tries hard to behave like a terminal, by default it |
|
30 | 30 | immediately executes single lines of input that are complete. If you want |
|
31 | 31 | to force multiline input, hit :key:`Ctrl-Enter` at the end of the first line |
|
32 | 32 | instead of :key:`Enter`, and it will open a new line for input. At any |
|
33 | 33 | point in a multiline block, you can force its execution (without having to |
|
34 | 34 | go to the bottom) with :key:`Shift-Enter`. |
|
35 | 35 | |
|
36 | 36 | ``%loadpy`` |
|
37 | 37 | =========== |
|
38 | 38 | |
|
39 | 39 | The new ``%loadpy`` magic takes any python script (must end in '.py'), and |
|
40 | 40 | pastes its contents as your next input, so you can edit it before |
|
41 | 41 | executing. The script may be on your machine, but you can also specify a url, |
|
42 | 42 | and it will download the script from the web. This is particularly useful for |
|
43 | 43 | playing with examples from documentation, such as matplotlib. |
|
44 | 44 | |
|
45 | 45 | .. sourcecode:: ipython |
|
46 | 46 | |
|
47 | 47 | In [6]: %loadpy http://matplotlib.sourceforge.net/plot_directive/mpl_examples/mplot3d/contour3d_demo.py |
|
48 | 48 | |
|
49 | 49 | In [7]: from mpl_toolkits.mplot3d import axes3d |
|
50 | 50 | ...: import matplotlib.pyplot as plt |
|
51 | 51 | ...: |
|
52 | 52 | ...: fig = plt.figure() |
|
53 | 53 | ...: ax = fig.add_subplot(111, projection='3d') |
|
54 | 54 | ...: X, Y, Z = axes3d.get_test_data(0.05) |
|
55 | 55 | ...: cset = ax.contour(X, Y, Z) |
|
56 | 56 | ...: ax.clabel(cset, fontsize=9, inline=1) |
|
57 | 57 | ...: |
|
58 | 58 | ...: plt.show() |
|
59 | 59 | |
|
60 | 60 | Pylab |
|
61 | 61 | ===== |
|
62 | 62 | |
|
63 | 63 | One of the most exciting features of the new console is embedded matplotlib |
|
64 | 64 | figures. You can use any standard matplotlib GUI backend (Except native MacOSX) |
|
65 | 65 | to draw the figures, and since there is now a two-process model, there is no |
|
66 | 66 | longer a conflict between user input and the drawing eventloop. |
|
67 | 67 | |
|
68 | 68 | .. image:: figs/besselj.png |
|
69 | 69 | :width: 519px |
|
70 | 70 | |
|
71 | 71 | .. display: |
|
72 | 72 | |
|
73 | 73 | :func:`display` |
|
74 | 74 | *************** |
|
75 | 75 | |
|
76 | 76 | An additional function, :func:`display`, will be added to the global namespace |
|
77 | 77 | if you specify the ``--pylab`` option at the command line. The IPython display |
|
78 | 78 | system provides a mechanism for specifying PNG or SVG (and more) |
|
79 | 79 | representations of objects for GUI frontends. By default, IPython registers |
|
80 | 80 | convenient PNG and SVG renderers for matplotlib figures, so you can embed them |
|
81 | 81 | in your document by calling :func:`display` on one or more of them. This is |
|
82 | 82 | especially useful for saving_ your work. |
|
83 | 83 | |
|
84 | 84 | .. sourcecode:: ipython |
|
85 | 85 | |
|
86 | 86 | In [5]: plot(range(5)) # plots in the matplotlib window |
|
87 | 87 | |
|
88 | 88 | In [6]: display(gcf()) # embeds the current figure in the qtconsole |
|
89 | 89 | |
|
90 | 90 | In [7]: display(*getfigs()) # embeds all active figures in the qtconsole |
|
91 | 91 | |
|
92 | 92 | If you have a reference to a matplotlib figure object, you can always display |
|
93 | 93 | that specific figure: |
|
94 | 94 | |
|
95 | 95 | .. sourcecode:: ipython |
|
96 | 96 | |
|
97 | 97 | In [1]: f = figure() |
|
98 | 98 | |
|
99 | 99 | In [2]: plot(rand(100)) |
|
100 | 100 | Out[2]: [<matplotlib.lines.Line2D at 0x7fc6ac03dd90>] |
|
101 | 101 | |
|
102 | 102 | In [3]: display(f) |
|
103 | 103 | |
|
104 | 104 | # Plot is shown here |
|
105 | 105 | |
|
106 | 106 | In [4]: title('A title') |
|
107 | 107 | Out[4]: <matplotlib.text.Text at 0x7fc6ac023450> |
|
108 | 108 | |
|
109 | 109 | In [5]: display(f) |
|
110 | 110 | |
|
111 | 111 | # Updated plot with title is shown here. |
|
112 | 112 | |
|
113 | 113 | .. _inline: |
|
114 | 114 | |
|
115 | 115 | ``--pylab=inline`` |
|
116 | 116 | ****************** |
|
117 | 117 | |
|
118 | 118 | If you want to have all of your figures embedded in your session, instead of |
|
119 | 119 | calling :func:`display`, you can specify ``--pylab=inline`` when you start the |
|
120 | 120 | console, and each time you make a plot, it will show up in your document, as if |
|
121 | 121 | you had called :func:`display(fig)`. |
|
122 | 122 | |
|
123 | 123 | |
|
124 | 124 | .. _saving: |
|
125 | 125 | |
|
126 | 126 | Saving and Printing |
|
127 | 127 | =================== |
|
128 | 128 | |
|
129 | 129 | IPythonQt has the ability to save your current session, as either HTML or |
|
130 | 130 | XHTML. If you have been using :func:`display` or inline_ pylab, your figures |
|
131 | 131 | will be PNG in HTML, or inlined as SVG in XHTML. PNG images have the option to |
|
132 | 132 | be either in an external folder, as in many browsers' "Webpage, Complete" |
|
133 | 133 | option, or inlined as well, for a larger, but more portable file. |
|
134 | 134 | |
|
135 | 135 | The widget also exposes the ability to print directly, via the default print |
|
136 | 136 | shortcut or context menu. |
|
137 | 137 | |
|
138 | 138 | |
|
139 | 139 | .. Note:: |
|
140 | 140 | |
|
141 | 141 | Saving is only available to richtext Qt widgets, which are used by default, |
|
142 | 142 | but if you pass the ``--plain`` flag, saving will not be available to you. |
|
143 | 143 | |
|
144 | 144 | |
|
145 | 145 | See these examples of :download:`png/html<figs/jn.html>` and |
|
146 | 146 | :download:`svg/xhtml <figs/jn.xhtml>` output. Note that syntax highlighting |
|
147 | 147 | does not survive export. This is a known issue, and is being investigated. |
|
148 | 148 | |
|
149 | 149 | Colors and Highlighting |
|
150 | 150 | ======================= |
|
151 | 151 | |
|
152 | 152 | Terminal IPython has always had some coloring, but never syntax |
|
153 | 153 | highlighting. There are a few simple color choices, specified by the ``colors`` |
|
154 | 154 | flag or ``%colors`` magic: |
|
155 | 155 | |
|
156 | 156 | * LightBG for light backgrounds |
|
157 | 157 | * Linux for dark backgrounds |
|
158 | 158 | * NoColor for a simple colorless terminal |
|
159 | 159 | |
|
160 | 160 | The Qt widget has full support for the ``colors`` flag used in the terminal shell. |
|
161 | 161 | |
|
162 | 162 | The Qt widget, however, has full syntax highlighting as you type, handled by |
|
163 | 163 | the `pygments`_ library. The ``style`` argument exposes access to any style by |
|
164 | 164 | name that can be found by pygments, and there are several already |
|
165 | 165 | installed. The ``colors`` argument, if unspecified, will be guessed based on |
|
166 | 166 | the chosen style. Similarly, there are default styles associated with each |
|
167 | 167 | ``colors`` option. |
|
168 | 168 | |
|
169 | 169 | |
|
170 | 170 | Screenshot of ``ipython qtconsole --colors=linux``, which uses the 'monokai' |
|
171 | 171 | theme by default: |
|
172 | 172 | |
|
173 | 173 | .. image:: figs/colors_dark.png |
|
174 | 174 | :width: 627px |
|
175 | 175 | |
|
176 | 176 | .. Note:: |
|
177 | 177 | |
|
178 | 178 | Calling ``ipython qtconsole -h`` will show all the style names that |
|
179 | 179 | pygments can find on your system. |
|
180 | 180 | |
|
181 | 181 | You can also pass the filename of a custom CSS stylesheet, if you want to do |
|
182 | 182 | your own coloring, via the ``stylesheet`` argument. The default LightBG |
|
183 | 183 | stylesheet: |
|
184 | 184 | |
|
185 | 185 | .. sourcecode:: css |
|
186 | 186 | |
|
187 | 187 | QPlainTextEdit, QTextEdit { background-color: white; |
|
188 | 188 | color: black ; |
|
189 | 189 | selection-background-color: #ccc} |
|
190 | 190 | .error { color: red; } |
|
191 | 191 | .in-prompt { color: navy; } |
|
192 | 192 | .in-prompt-number { font-weight: bold; } |
|
193 | 193 | .out-prompt { color: darkred; } |
|
194 | 194 | .out-prompt-number { font-weight: bold; } |
|
195 | 195 | |
|
196 | 196 | Fonts |
|
197 | 197 | ===== |
|
198 | 198 | |
|
199 | 199 | The QtConsole has configurable via the ConsoleWidget. To change these, set the |
|
200 | 200 | ``font_family`` or ``font_size`` traits of the ConsoleWidget. For instance, to |
|
201 | 201 | use 9pt Anonymous Pro:: |
|
202 | 202 | |
|
203 | 203 | $> ipython qtconsole --ConsoleWidget.font_family="Anonymous Pro" --ConsoleWidget.font_size=9 |
|
204 | 204 | |
|
205 | 205 | Process Management |
|
206 | 206 | ================== |
|
207 | 207 | |
|
208 | 208 | With the two-process ZMQ model, the frontend does not block input during |
|
209 | 209 | execution. This means that actions can be taken by the frontend while the |
|
210 | 210 | Kernel is executing, or even after it crashes. The most basic such command is |
|
211 | 211 | via 'Ctrl-.', which restarts the kernel. This can be done in the middle of a |
|
212 | 212 | blocking execution. The frontend can also know, via a heartbeat mechanism, that |
|
213 | 213 | the kernel has died. This means that the frontend can safely restart the |
|
214 | 214 | kernel. |
|
215 | 215 | |
|
216 | 216 | Multiple Consoles |
|
217 | 217 | ***************** |
|
218 | 218 | |
|
219 | 219 | Since the Kernel listens on the network, multiple frontends can connect to it. |
|
220 | 220 | These do not have to all be qt frontends - any IPython frontend can connect and |
|
221 | 221 | run code. When you start ipython qtconsole, there will be an output line, |
|
222 | 222 | like:: |
|
223 | 223 | |
|
224 | 224 | [IPKernelApp] To connect another client to this kernel, use: |
|
225 | 225 | [IPKernelApp] --existing --shell=60690 --iopub=44045 --stdin=38323 --hb=41797 |
|
226 | 226 | |
|
227 | 227 | Other frontends can connect to your kernel, and share in the execution. This is |
|
228 | 228 | great for collaboration. The `-e` flag is for 'external'. Starting other |
|
229 | 229 | consoles with that flag will not try to start their own, but rather connect to |
|
230 | 230 | yours. Ultimately, you will not have to specify each port individually, but for |
|
231 | 231 | now this copy-paste method is best. |
|
232 | 232 | |
|
233 | 233 | By default (for security reasons), the kernel only listens on localhost, so you |
|
234 | 234 | can only connect multiple frontends to the kernel from your local machine. You |
|
235 | 235 | can specify to listen on an external interface by specifying the ``ip`` |
|
236 | 236 | argument:: |
|
237 | 237 | |
|
238 | 238 | $> ipython qtconsole --ip=192.168.1.123 |
|
239 | 239 | |
|
240 | 240 | If you specify the ip as 0.0.0.0, that refers to all interfaces, so any |
|
241 | 241 | computer that can see yours can connect to the kernel. |
|
242 | 242 | |
|
243 | 243 | .. warning:: |
|
244 | 244 | |
|
245 | 245 | Since the ZMQ code currently has no security, listening on an |
|
246 | 246 | external-facing IP is dangerous. You are giving any computer that can see |
|
247 | 247 | you on the network the ability to issue arbitrary shell commands as you on |
|
248 | 248 | your machine. Be very careful with this. |
|
249 | 249 | |
|
250 | 250 | |
|
251 | 251 | Stopping Kernels and Consoles |
|
252 | 252 | ***************************** |
|
253 | 253 | |
|
254 | 254 | Since there can be many consoles per kernel, the shutdown mechanism and dialog |
|
255 | 255 | are probably more complicated than you are used to. Since you don't always want |
|
256 | 256 | to shutdown a kernel when you close a window, you are given the option to just |
|
257 | 257 | close the console window or also close the Kernel and *all other windows*. Note |
|
258 | 258 | that this only refers to all other *local* windows, as remote Consoles are not |
|
259 | 259 | allowed to shutdown the kernel, and shutdowns do not close Remote consoles (to |
|
260 | 260 | allow for saving, etc.). |
|
261 | 261 | |
|
262 | 262 | Rules: |
|
263 | 263 | |
|
264 | 264 | * Restarting the kernel automatically clears all *local* Consoles, and prompts remote |
|
265 | 265 | Consoles about the reset. |
|
266 | 266 | * Shutdown closes all *local* Consoles, and notifies remotes that |
|
267 | 267 | the Kernel has been shutdown. |
|
268 | 268 | * Remote Consoles may not restart or shutdown the kernel. |
|
269 | 269 | |
|
270 | 270 | Qt and the QtConsole |
|
271 | 271 | ==================== |
|
272 | 272 | |
|
273 | 273 | An important part of working with the QtConsole when you are writing your own |
|
274 | 274 | Qt code is to remember that user code (in the kernel) is *not* in the same |
|
275 | 275 | process as the frontend. This means that there is not necessarily any Qt code |
|
276 | 276 | running in the kernel, and under most normal circumstances there isn't. If, |
|
277 | 277 | however, you specify ``--pylab=qt`` at the command-line, then there *will* be a |
|
278 | 278 | :class:`QCoreApplication` instance running in the kernel process along with |
|
279 | 279 | user-code. To get a reference to this application, do: |
|
280 | 280 | |
|
281 | 281 | .. sourcecode:: python |
|
282 | 282 | |
|
283 | 283 | from PyQt4 import QtCore |
|
284 | 284 | app = QtCore.QCoreApplication.instance() |
|
285 | 285 | # app will be None if there is no such instance |
|
286 | 286 | |
|
287 | 287 | A common problem listed in the PyQt4 Gotchas_ is the fact that Python's garbage |
|
288 | 288 | collection will destroy Qt objects (Windows, etc.) once there is no longer a |
|
289 | 289 | Python reference to them, so you have to hold on to them. For instance, in: |
|
290 | 290 | |
|
291 | 291 | .. sourcecode:: python |
|
292 | 292 | |
|
293 | 293 | def make_window(): |
|
294 | 294 | win = QtGui.QMainWindow() |
|
295 | 295 | |
|
296 | 296 | def make_and_return_window(): |
|
297 | 297 | win = QtGui.QMainWindow() |
|
298 | 298 | return win |
|
299 | 299 | |
|
300 | 300 | :func:`make_window` will never draw a window, because garbage collection will |
|
301 | 301 | destroy it before it is drawn, whereas :func:`make_and_return_window` lets the |
|
302 | 302 | caller decide when the window object should be destroyed. If, as a developer, |
|
303 | 303 | you know that you always want your objects to last as long as the process, you |
|
304 | 304 | can attach them to the QApplication instance itself: |
|
305 | 305 | |
|
306 | 306 | .. sourcecode:: python |
|
307 | 307 | |
|
308 | 308 | # do this just once: |
|
309 | 309 | app = QtCore.QCoreApplication.instance() |
|
310 | 310 | app.references = set() |
|
311 | 311 | # then when you create Windows, add them to the set |
|
312 | 312 | def make_window(): |
|
313 | 313 | win = QtGui.QMainWindow() |
|
314 | 314 | app.references.add(win) |
|
315 | 315 | |
|
316 | 316 | Now the QApplication itself holds a reference to ``win``, so it will never be |
|
317 | 317 | garbage collected until the application itself is destroyed. |
|
318 | 318 | |
|
319 | 319 | .. _Gotchas: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/gotchas.html#garbage-collection |
|
320 | 320 | |
|
321 | 321 | Regressions |
|
322 | 322 | =========== |
|
323 | 323 | |
|
324 | 324 | There are some features, where the qt console lags behind the Terminal |
|
325 | frontend. We hope to have these fixed by 0.11 release. | |
|
325 | frontend: | |
|
326 | 326 | |
|
327 | 327 | * !cmd input: Due to our use of pexpect, we cannot pass input to subprocesses |
|
328 |
launched using the '!' escape |
|
|
328 | launched using the '!' escape, so you should never call a command that | |
|
329 | requires interactive input. For such cases, use the terminal IPython. This | |
|
330 | will not be fixed, as abandoning pexpect would significantly degrade the | |
|
331 | console experience. | |
|
332 | ||
|
333 | * Use of ``\b`` and ``\r`` characters in the console: these are control | |
|
334 | characters that allow the cursor to move backwards on a line, and are used to | |
|
335 | display things like in-place progress bars in a terminal. We currently do | |
|
336 | not support this, but it is being tracked as issue 629_. | |
|
337 | ||
|
338 | .. _629: https://github.com/ipython/ipython/issues/629 | |
|
329 | 339 | |
|
330 | 340 | .. [PyQt] PyQt4 http://www.riverbankcomputing.co.uk/software/pyqt/download |
|
331 | 341 | .. [pygments] Pygments http://pygments.org/ |
General Comments 0
You need to be logged in to leave comments.
Login now