-
Notifications
You must be signed in to change notification settings - Fork 0
/
MVPDesign.html
530 lines (486 loc) · 29.3 KB
/
MVPDesign.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>MVP Design</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="_static/bootstrap-sphinx.css?v=fadd4351" />
<link rel="stylesheet" type="text/css" href="_static/custom.css?v=77160d70" />
<script src="_static/documentation_options.js?v=a8da1a53"></script>
<script src="_static/doctools.js?v=9bcbadda"></script>
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="MVP Tutorial" href="MVPTutorial/index.html" />
<link rel="prev" title="Running Sanitizers" href="RunningSanitizers.html" />
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-59110517-1', 'auto');
ga('send', 'pageview');
</script>
</head><body>
<div id="navbar" class="navbar navbar-default ">
<div class="container">
<div class="navbar-header">
<!-- .btn-navbar is used as the toggle for collapsed navbar content -->
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="http://www.mantidproject.org">
</a>
<span class="navbar-text navbar-version pull-left"><b>main</b></span>
</div>
<div class="collapse navbar-collapse nav-collapse">
<ul class="nav navbar-nav">
<li class="divider-vertical"></li>
<li><a href="index.html">Home</a></li>
<li><a href="https://download.mantidproject.org">Download</a></li>
<li><a href="https://docs.mantidproject.org">User Documentation</a></li>
<li><a href="http://www.mantidproject.org/contact">Contact Us</a></li>
</ul>
<form class="navbar-form navbar-right" action="search.html" method="get">
<div class="form-group">
<input type="text" name="q" class="form-control" placeholder="Search" />
</div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<p>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="nav-item nav-item-0"><a href="index.html">Documentation</a> »</li>
<li class="nav-item nav-item-this"><a href="">MVP Design</a></li>
</ul>
</div> </p>
</div>
<div class="container">
<div class="row">
<div class="body col-md-12 content" role="main">
<section id="mvp-design">
<span id="mvpdesign"></span><h1>MVP Design<a class="headerlink" href="#mvp-design" title="Link to this heading">¶</a></h1>
<nav class="contents local" id="contents">
<ul class="simple">
<li><p><a class="reference internal" href="#summary" id="id3">Summary</a></p></li>
<li><p><a class="reference internal" href="#mvp-model-view-presenter" id="id4">MVP (Model View Presenter)</a></p>
<ul>
<li><p><a class="reference internal" href="#model" id="id5">Model</a></p></li>
<li><p><a class="reference internal" href="#view" id="id6">View</a></p></li>
<li><p><a class="reference internal" href="#presenter" id="id7">Presenter</a></p></li>
<li><p><a class="reference internal" href="#testing-mvp-components" id="id8">Testing MVP Components</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#mvp-template-tool" id="id9">MVP Template tool</a></p>
<ul>
<li><p><a class="reference internal" href="#python" id="id10">Python</a></p></li>
<li><p><a class="reference internal" href="#c" id="id11">C++</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#visual-design" id="id12">Visual Design</a></p>
<ul>
<li><p><a class="reference internal" href="#qt-designer" id="id13">Qt Designer</a></p></li>
<li><p><a class="reference internal" href="#reusable-widgets" id="id14">Reusable Widgets</a></p></li>
<li><p><a class="reference internal" href="#icons" id="id15">Icons</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#id1" id="id16">Python</a></p>
<ul>
<li><p><a class="reference internal" href="#id2" id="id17">Designer</a></p></li>
</ul>
</li>
</ul>
</nav>
<section id="summary">
<h2><a class="toc-backref" href="#id3" role="doc-backlink">Summary</a><a class="headerlink" href="#summary" title="Link to this heading">¶</a></h2>
<p>This page describes guidelines that should be followed when
implementing an interface in MantidWorkbench. The aim is to encourage a
consistent approach to developing interfaces.</p>
</section>
<section id="mvp-model-view-presenter">
<span id="mvpdesignintro"></span><h2><a class="toc-backref" href="#id4" role="doc-backlink">MVP (Model View Presenter)</a><a class="headerlink" href="#mvp-model-view-presenter" title="Link to this heading">¶</a></h2>
<p>GUIs in Mantid aim to use the MVP pattern. The MVP pattern is a
generic concept for how to structure GUI code. MVP allows components
of the GUI to be tested separately and automatically. It also allows
for greater flexibility. Decoupling the model and view means that if
the developer wants to experiment with, for example, a different GUI
toolkit, or a different method of doing their calculations, then it is
easy and safe to swap out components. A description of each component
is given below.</p>
<p>To illustrate MVP, a simple example of a calculator GUI has been
created using Python (the concepts of MVP can be applied to any
programming language). This example can be found in
<a class="reference internal" href="MVPTutorial/CalculatorExample/index.html#mvpcalculatorguiexample"><span class="std std-ref">MVP Calculator GUI Example</span></a>, and you can run it with
<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">Calculator.py</span></code>.</p>
<p>It is good practice to have model, view or presenter (as appropriate)
at the end of the name for each file (e.g. FFTView, FFTModel,
FFTPresenter), and each component should be a class in its own
right. Within the MVP pattern the model and view never exchange any
information directly.</p>
<section id="model">
<h3><a class="toc-backref" href="#id5" role="doc-backlink">Model</a><a class="headerlink" href="#model" title="Link to this heading">¶</a></h3>
<p>The model is where the ‘hard sums’ take place within GUI. Any Mantid
algorithms should be run in the model, as well any other calculations
that may need to be performed.</p>
<p>It is possible that a presenter may have multiple models. For example
if two GUIs require the same calculation (e.g. mean) but not all
of the model (one GUI may need standard deviation and the other the
median), then it would be sensible for there to be three models (with
the mean model being shared). This prevents code duplication and makes
maintenance easier.</p>
<p>It is important to note that the values used in the calculations
should be received from the presenter (more of which below).</p>
</section>
<section id="view">
<span id="mvpdesignview"></span><h3><a class="toc-backref" href="#id6" role="doc-backlink">View</a><a class="headerlink" href="#view" title="Link to this heading">¶</a></h3>
<p>The view determines the look of the GUI. In passive-view MVP, there
will generally be very little logic in the view. A view should define
the following sections:</p>
<ul class="simple">
<li><p>The look of the GUI (often this will be defined in a Qt <code class="docutils literal notranslate"><span class="pre">.ui</span></code> file
instead)</p></li>
<li><p><strong>Get</strong> methods to return values from the widgets (text input,
checkbox etc)</p></li>
<li><p><strong>Set</strong> methods to update the output from the GUI (eg. plot some
data, fill in some text boxes)</p></li>
</ul>
<p>A view will probably also contain <strong>connections</strong>. A detailed
explanation of signals and slots can be foud <a class="reference external" href="http://doc.qt.io/archives/qt-4.8/signalsandslots.html">here</a>. Briefly, a
widget may emit <strong>signals</strong>. For example QPushButton emits the signal
<code class="docutils literal notranslate"><span class="pre">clicked</span></code> when it is clicked. In order to handle the button being
clicked, the view will implement a <strong>slot</strong> method. This method does
whatever we need for a button click. To ensure that this method is
called whenever the button is clicked, we connect the <code class="docutils literal notranslate"><span class="pre">clicked</span></code>
signal of our button to the <code class="docutils literal notranslate"><span class="pre">handleButtonClick</span></code> slot of our view.</p>
<p>The view should have a parent - this will be the widget containing
it. An example of a parent would be a main window containing tabs -
the children of the main window would be the tabs, and the children of
the tabs would be the widgets contained within the tabs.</p>
</section>
<section id="presenter">
<h3><a class="toc-backref" href="#id7" role="doc-backlink">Presenter</a><a class="headerlink" href="#presenter" title="Link to this heading">¶</a></h3>
<p>The presenter acts as a ‘go-between’. It receives data from the view,
passes it to the model for processing, receives it back from the model
and passes it to the view to be displayed to the user. The presenter
generally should contain relatively simple logic (though it will be
more complex than the view).</p>
<p>The model and the view are stored as members of the presenter
class. These should be passed into the presenter at initialisation.</p>
<p>It is important to note that the model and view should have as little
access as possible to the presenter. Presenter-model communication is
simple - the presenter generally just calls methods on the
presenter. Presenter-view communication is slightly more
involved. There are two ways of doing it:</p>
<ul class="simple">
<li><p><strong>Connections</strong> - the presenter may contain connections as well as
the view. You may choose to define custom signals in your view, such
as a <code class="docutils literal notranslate"><span class="pre">plotRequested</span></code> signal to announce that the user has asked to
plot some data, probably by clicking a button. The presenter will
need to implement a slot (let’s call it <code class="docutils literal notranslate"><span class="pre">handlePlotRequested</span></code>) to
handle this, which gets the relevant data from the model and passes
it to the view. We then need to connect the signal to the slot in
the presenter’s constructor. It is also possible for a signal
emitted by a view to be caught in the presenter of a parent view. In
order to communicate by connections using Qt in C++ the presenter
must inherit from <code class="docutils literal notranslate"><span class="pre">QObject</span></code>. It’s generally considered good
practice to avoid having Qt in the presenter, so this method works
best for GUIs written in Python (or another language with a more
relaxed type system).</p>
<ul>
<li><p>Note that is good practice to handle all signals in the presenter
if you can, even if it is possible to just handle them in the
view. This is because by going through the presenter we can unit
test the handling of the signals.</p></li>
</ul>
</li>
<li><p><strong>Notify</strong> - the presenter may instead allow the view to ‘notify’
it. This can be achieved by implementing a set of possible
notifications (in C++ an enum class works well) and a method
<code class="docutils literal notranslate"><span class="pre">notify(notification)</span></code> on the presenter. In the above example,
<code class="docutils literal notranslate"><span class="pre">handlePlotRequested</span></code> is still needed, but now <code class="docutils literal notranslate"><span class="pre">notify</span></code> invokes
it whenever it is passed a <code class="docutils literal notranslate"><span class="pre">plotRequested</span></code> notification. This
method requires the view to have a pointer to the presenter, which
introduces a circular dependency and leaks information about the
presenter to the view. The leak can be resolved by having the
presenter implement an interface which exposes <strong>only</strong> the
<code class="docutils literal notranslate"><span class="pre">notify</span></code> method, and having the view keep a pointer to
this.</p></li>
</ul>
<p>Doing presenter-view communication with connections is the cleaner of
the two, so this method should be used unless writing a GUI in
C++. You’ll notice that, in both cases, the view never passes data
(for example, the input from a text box) directly to the presenter,
instead it justs tells the presenter that something needs to be
done. In passive-view MVP the presenter, in handling this, gets any
data it needs from the view using the view’s <strong>get</strong> methods.</p>
</section>
<section id="testing-mvp-components">
<h3><a class="toc-backref" href="#id8" role="doc-backlink">Testing MVP Components</a><a class="headerlink" href="#testing-mvp-components" title="Link to this heading">¶</a></h3>
<p>MVP allows us to write automated tests for a large amount of the
GUI. We can write independent tests for the presenter and model, but
usually not the view (for this reason, the view should be as simple as
possible, ideally containing no logic at all).</p>
<p><strong>Mocking</strong> is very useful tool for testing the presenter. Mocking
allows us to return a predefined result from a method of either the
view or the model.</p>
<p>It is useful to mock out the model because, providing that we’ve
written adequate tests for it, we don’t care what the output is in the
tests for the presenter - we just care that the presenter handles it
correctly. The model may perform time-consuming calculations, such as
fitting, so by returning a dummy value from the fitting method we cut
down the time our tests take to run. We can also potentially change
how the model works - if the GUI uses an algorithm which undergoes
some changes, such as applying a different set of corrections, the
tests for the presenter will be unaffected.</p>
<p>It’s useful to mock out the view because we don’t want to have to
manually input data every time the unit tests are run - instead we can
mock the <strong>get</strong> methods to simulate the user entering data.</p>
<p>Using <a class="reference external" href="https://github.com/google/googletest/tree/main/googlemock">GMock</a>
in C++, or <a class="reference external" href="https://docs.python.org/3/library/unittest.mock.html">unittest.mock</a> in Python, we
can set expectations in the unit tests for certain methods to be
called, and with certain arguments.</p>
</section>
</section>
<section id="mvp-template-tool">
<h2><a class="toc-backref" href="#id9" role="doc-backlink">MVP Template tool</a><a class="headerlink" href="#mvp-template-tool" title="Link to this heading">¶</a></h2>
<p>The <a class="reference external" href="https://github.com/mantidproject/mantid/blob/main/tools/MVP/template.py">template.py script</a>
provides a tool which is designed to generate initial files for an MVP-based
widget written in either Python or C++. These generated files serve as a
foundation or template for creating any widget using the MVP design pattern.
It can also be used to create the necessary files when refactoring an existing
widget which is not currently using MVP. The script is designed to be run from
within a <cite>mantid-developer</cite> Conda environment.</p>
<section id="python">
<h3><a class="toc-backref" href="#id10" role="doc-backlink">Python</a><a class="headerlink" href="#python" title="Link to this heading">¶</a></h3>
<p>To generate files for a Python widget with name “Example”, run:</p>
<div class="highlight-sh notranslate"><div class="highlight"><pre><span></span>python<span class="w"> </span>tools/MVP/template.py<span class="w"> </span>--name<span class="w"> </span>Example<span class="w"> </span>--language<span class="w"> </span>python<span class="w"> </span>--include-setup<span class="w"> </span>--output-dir<span class="w"> </span><span class="nv">$PWD</span>/..
</pre></div>
</div>
<p>This command will generate five python files including <cite>example_model.py</cite>, <cite>example_view.py</cite>,
,`example_presenter.py` and <cite>example_guiwidget.ui</cite>. These files will be saved in the provided output directory,
as specified by <cite>$PWD/..</cite>. An additional file named <cite>launch.py</cite> will be generated if the
<code class="docutils literal notranslate"><span class="pre">--include-setup</span></code> flag is provided to the script. This can be used to open the widget as
follows:</p>
<div class="highlight-sh notranslate"><div class="highlight"><pre><span></span>python<span class="w"> </span><span class="nv">$PWD</span>/../launch.py
</pre></div>
</div>
</section>
<section id="c">
<h3><a class="toc-backref" href="#id11" role="doc-backlink">C++</a><a class="headerlink" href="#c" title="Link to this heading">¶</a></h3>
<p>To generate files for a C++ widget with name “Example”, run:</p>
<div class="highlight-sh notranslate"><div class="highlight"><pre><span></span>python<span class="w"> </span>tools/MVP/template.py<span class="w"> </span>--name<span class="w"> </span>Example<span class="w"> </span>--language<span class="w"> </span>c++<span class="w"> </span>--include-setup<span class="w"> </span>--output-dir<span class="w"> </span><span class="nv">$PWD</span>/..
</pre></div>
</div>
<p>This command will generate nine files including <cite>ExampleModel.cpp</cite>, <cite>ExampleModel.h</cite>,
<cite>ExampleView.cpp</cite>, <cite>ExampleView.h</cite>, <cite>ExamplePresenter.cpp</cite>, <cite>ExamplePresenter.h</cite> and
<cite>ExampleGUIWidget.ui</cite>.
An additional file named <cite>main.cpp</cite> and a <cite>CMakeLists.txt</cite> will be generated if the
<code class="docutils literal notranslate"><span class="pre">--include-setup</span></code> flag is provided to the script. These files can be used to build
the widget as follows:</p>
<div class="highlight-sh notranslate"><div class="highlight"><pre><span></span>mkdir<span class="w"> </span>buildmvp
<span class="nb">cd</span><span class="w"> </span>buildmvp
cmake<span class="w"> </span>..
cmake<span class="w"> </span>--build<span class="w"> </span>.
</pre></div>
</div>
<p>The example widget can then be opened with:</p>
<div class="highlight-sh notranslate"><div class="highlight"><pre><span></span><span class="nb">cd</span><span class="w"> </span>buildmvp
<span class="c1"># On a Unix system</span>
./launch
<span class="c1"># On a Windows system from a shell or bash</span>
./Debug/launch.exe
</pre></div>
</div>
<p>The <cite>main.cpp</cite> and a <cite>CMakeLists.txt</cite> files are intended as an example for how you can
build, and then instantiate your widget. If you are refactoring or creating a new
widget for Mantid, the headers and cpp files should be included in the relevant
CMakeLists file elsewhere in the project.</p>
</section>
</section>
<section id="visual-design">
<h2><a class="toc-backref" href="#id12" role="doc-backlink">Visual Design</a><a class="headerlink" href="#visual-design" title="Link to this heading">¶</a></h2>
<section id="qt-designer">
<h3><a class="toc-backref" href="#id13" role="doc-backlink">Qt Designer</a><a class="headerlink" href="#qt-designer" title="Link to this heading">¶</a></h3>
<p>The layout of all interfaces and reusable widgets should be done by
using the Qt’s <a class="reference external" href="http://qt-project.org/doc/qt-4.8/designer-manual.html">Designer</a> tool. This
has several advantages:</p>
<ul class="simple">
<li><p>immediate visual feedback of what the widget/interface will look
like</p></li>
<li><p>far easier to maintain, e.g. moving a control is a simple drag and
drop</p></li>
<li><p>reduces the amount of hand-written code required</p></li>
</ul>
<p>If it is felt that the design must be hand coded then this should be
discussed with a senior developer.</p>
</section>
<section id="reusable-widgets">
<h3><a class="toc-backref" href="#id14" role="doc-backlink">Reusable Widgets</a><a class="headerlink" href="#reusable-widgets" title="Link to this heading">¶</a></h3>
<p>Many interfaces will require similar functionality. For example, the
ability to enter a filename string to search for a file along with a
‘Browse’ button to select a file from the filesystem. This type of
behaviour should be captured in a new composite widget that can be
reused by other components.</p>
<p>The new widget should be placed in the MantidWidgets plugin and a
wrapper created in the DesignerPlugins plugin so that the new widget
type can be used from within the Qt Designer.</p>
<p>The current set of reusable items are:</p>
<table class="docutils align-default">
<thead>
<tr class="row-odd"><th class="head"><p>Class Name</p></th>
<th class="head"><p>Parent Class</p></th>
<th class="head"><p>Abiltity</p></th>
</tr>
</thead>
<tbody>
<tr class="row-even"><td><p>AlgorithmSelectorWidget</p></td>
<td><p>QWidget</p></td>
<td><p>A text box and tree widget to select an algorithm</p></td>
</tr>
<tr class="row-odd"><td><p>CatalogSearch</p></td>
<td><p>QWidget</p></td>
<td><p>An interface interface to the catalog system</p></td>
</tr>
<tr class="row-even"><td><p>CatalogSelector</p></td>
<td><p>QWidget</p></td>
<td><p>Displays the available catalog services</p></td>
</tr>
<tr class="row-odd"><td><p>CheckBoxHeader</p></td>
<td><p>QHeaderView</p></td>
<td><p>Enables checkboxes to exist in the table header</p></td>
</tr>
<tr class="row-even"><td><p>ColorBarWidget</p></td>
<td><p>QWidget</p></td>
<td><p>Show a color bar that can accompany a colored bidimensional plot</p></td>
</tr>
<tr class="row-odd"><td><p>DataSelector</p></td>
<td><p>MantidWidget</p></td>
<td><p>A box to select if input is from a file or workspace along with the appropriate widget to choose a workspace or file.</p></td>
</tr>
<tr class="row-even"><td><p>DisplayCurveFit</p></td>
<td><p>MantidWidget</p></td>
<td><p>A plot to display the results of a curve fitting process</p></td>
</tr>
<tr class="row-odd"><td><p>FindReplaceDialog</p></td>
<td><p>QDialog</p></td>
<td><p>A dialog box to find/replace text within a ScriptEditor</p></td>
</tr>
<tr class="row-even"><td><p>FitPropertyBrowser</p></td>
<td><p>QDockWidget</p></td>
<td><p>Specialisation of QPropertyBrowser for defining fitting functions</p></td>
</tr>
<tr class="row-odd"><td><p>FunctionBrowser</p></td>
<td><p>QWidget</p></td>
<td><p>Provides a wiget to alter the parameters of a function</p></td>
</tr>
<tr class="row-even"><td><p>InstrumentSelector</p></td>
<td><p>QCombobox</p></td>
<td><p>A selection box populated with a list of instruments for the current facility</p></td>
</tr>
<tr class="row-odd"><td><p>LineEditWithClear</p></td>
<td><p>QLineEdit</p></td>
<td><p>A QLineEdit with a button to clear the text</p></td>
</tr>
<tr class="row-even"><td><p>MessageDisplay</p></td>
<td><p>QWidget</p></td>
<td><p>Display messages from the logging system</p></td>
</tr>
<tr class="row-odd"><td><p>FileFinderWidget</p></td>
<td><p>MantidWidget</p></td>
<td><p>Provides a line edit to enter filenames and a browse button to browse the file system</p></td>
</tr>
<tr class="row-even"><td><p>MWView</p></td>
<td><p>QWidget</p></td>
<td><p>A colored, bidimensional plot of a matrix workspace</p></td>
</tr>
<tr class="row-odd"><td><p>ProcessingAlgoWidget</p></td>
<td><p>QWidget</p></td>
<td><p>A composite widget that allows a user to select if a processing step is achieved using an algorithm or a Python script. It also provides a script editor.</p></td>
</tr>
<tr class="row-even"><td><p>ScriptEditor</p></td>
<td><p>QsciScintilla</p></td>
<td><p>The main script editor widget behind the ScriptWindow</p></td>
</tr>
<tr class="row-odd"><td><p>WorkspaceSelector</p></td>
<td><p>QComboBox</p></td>
<td><p>A selection box showing the workspaces currently in Mantid. It can be restricted by type.</p></td>
</tr>
</tbody>
</table>
</section>
<section id="icons">
<h3><a class="toc-backref" href="#id15" role="doc-backlink">Icons</a><a class="headerlink" href="#icons" title="Link to this heading">¶</a></h3>
<p>Icons are a contentious subject as they can in some cases cause more
confusion and hinder more than they help. The NHS came up with a
good set of rules for what icons should be used and this could be
useful to designers, check out this <a class="reference external" href="https://digital.nhs.uk/blog/transformation-blog/2019/icons-avoid-temptation-and-start-with-user-needs">article.</a>. It may fit a situation more to have a text button
instead of an icon.</p>
<p>Whilst having too many icons will confuse the average user there are
cases where many cases where it would help, for example if a button does a
similar thing to another button somewhere else in the program then
it should have the same icon. Have a look to see if the need you has
an icon in Mantid by look at this handy <a class="reference internal" href="MantidUsedIconsTable.html#mantidusediconstable"><span class="std std-ref">Mantid Icon Table</span></a>.</p>
</section>
</section>
<section id="id1">
<h2><a class="toc-backref" href="#id16" role="doc-backlink">Python</a><a class="headerlink" href="#id1" title="Link to this heading">¶</a></h2>
<p>Interfaces can also be created in Python using the <a class="reference external" href="https://pypi.org/project/QtPy/">qtpy</a> package. The code for the
interface should be placed in a Python <a class="reference external" href="https://docs.python.org/2/tutorial/modules.html#packages">package</a> under the
<code class="docutils literal notranslate"><span class="pre">Code/Mantid/scripts</span></code> directory. It should be named after the interface
name (without spaces). The code within the package should be
structured to avoid placing all of the code in a single file,
i.e. separate files for different classes etc. Sub packages are
recommended for grouping together logical sets of files.</p>
<p>For the interface to appear from within MantidWorkbench, create a startup
python file under the <code class="docutils literal notranslate"><span class="pre">Code/Mantid/scripts</span></code> directory. Assuming the code
for the interface is in a directory called foo_app then the startup
file would look like:</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">foo_app</span> <span class="kn">import</span> <span class="n">FooGUI</span>
<span class="n">app</span> <span class="o">=</span> <span class="n">FooGUI</span><span class="p">()</span>
<span class="n">app</span><span class="o">.</span><span class="n">show</span><span class="p">()</span>
</pre></div>
</div>
<p>where <code class="docutils literal notranslate"><span class="pre">FooGUI</span></code> is the <code class="docutils literal notranslate"><span class="pre">MainWindow</span></code> for the interface. Some more
detailed documentation on creating GUIs in Python can be found at
<a class="reference internal" href="QtDesignerForPython.html#qtdesignerforpython"><span class="std std-ref">Qt Designer for Python</span></a>.</p>
<section id="id2">
<h3><a class="toc-backref" href="#id17" role="doc-backlink">Designer</a><a class="headerlink" href="#id2" title="Link to this heading">¶</a></h3>
<p>As with the C++ GUI the Qt Designer should be used for layouts of all
widgets and the main interface. It is recommended that the <code class="docutils literal notranslate"><span class="pre">.ui</span></code>
files be placed in a <code class="docutils literal notranslate"><span class="pre">ui</span></code> subdirectory of the interface package. To
generate PyQt code from the UI xml you will need to run the <code class="docutils literal notranslate"><span class="pre">pyuic5</span></code>
program that ships with PyQt5. It is also recommended that the output
file is named, using the <code class="docutils literal notranslate"><span class="pre">-o</span></code> argument, <code class="docutils literal notranslate"><span class="pre">ui_[widgetname].py</span></code> and
placed in the <code class="docutils literal notranslate"><span class="pre">ui</span></code> subdirectory.</p>
</section>
</section>
</section>
</div>
</div>
</div>
<footer class="footer">
<div class="container">
<ul class="nav navbar-nav" style=" float: right;">
<li>
<a href="RunningSanitizers.html" title="Previous Chapter: Running Sanitizers"><span class="glyphicon glyphicon-chevron-left visible-sm"></span><span class="hidden-sm hidden-tablet">« Running Sanitizers</span>
</a>
</li>
<li>
<a href="MVPTutorial/index.html" title="Next Chapter: MVP Tutorial"><span class="glyphicon glyphicon-chevron-right visible-sm"></span><span class="hidden-sm hidden-tablet">MVP Tutorial »</span>
</a>
</li>
<li><a href="#">Back to top</a></li>
</ul>
<p>
</p>
</div>
</footer>
</body>
</html>