/usr/share/doc/gnat-gps/programmers_guide/intermodule_communication.html is in gnat-gps-doc 5.3dfsg-1ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>6. Intermodule communication — GPS Programer's Guide 5.3.0w documentation</title>
<link rel="stylesheet" href="_static/sphinxdoc.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: './',
VERSION: '5.3.0w',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<link rel="shortcut icon" href="_static/favicon.ico"/>
<link rel="top" title="GPS Programer's Guide 5.3.0w documentation" href="index.html" />
<link rel="next" title="7. Documenting your module" href="documenting.html" />
<link rel="prev" title="5. The GPS Kernel" href="kernel.html" />
</head>
<body>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="documenting.html" title="7. Documenting your module"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="kernel.html" title="5. The GPS Kernel"
accesskey="P">previous</a> |</li>
<li><a href="index.html">GPS Programer's Guide 5.3.0w documentation</a> »</li>
</ul>
</div>
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/adacore_transparent.png" alt="Logo"/>
</a></p>
<h4>Previous topic</h4>
<p class="topless"><a href="kernel.html"
title="previous chapter">5. The GPS Kernel</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="documenting.html"
title="next chapter">7. Documenting your module</a></p>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/intermodule_communication.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="intermodule-communication">
<h1>6. Intermodule communication<a class="headerlink" href="#intermodule-communication" title="Permalink to this headline">ΒΆ</a></h1>
<p>As described above, GPS is organized into largely independent
modules. For instance, the various views, browsers, help, vcs
support,... are separate modules, that can either be loaded at startup
or not.</p>
<p>When they are not loaded, the correspondings features and menus are not
available to the user.</p>
<p>These modules need to communicate with each other so as to provide the
best possible integration between the tools. There currently exists a
number of ways to send information from one module to
another. However, some of these technics depend on Ada-specific types,
and thus makes it harder to write modules in different languages like
C or Python.</p>
<p>The following communication technics are currently provided:</p>
<ul>
<li><p class="first">Direct calls
A module can explicitly specify that it depends on another one. This
is done by changing the project file, and adding the necessary “with”
statements in the code. This technics is highly not recommended, and
should never be used when one of the other technics would do the job,
since it defeats the module independency. The only place it is
currently used at is for direct calls to the Register_* commands.
Most of the time, these Register_* subprograms are also available through
XML customization files, and thus limit the direct dependencies between
modules, while providing greated extensibility to the final user.</p>
</li>
<li><p class="first">Shell calls
Each module can register new shell commands for the interactive shell
window. Any other module can call these commands. There is no direct
dependency on the code, although this means that the module that
provide the command must be loaded before the other module. This
technics is used for instance for the codefix module, that needs a
high degree of integration with the source editor module. It will also
be used for communicating with Emacs.</p>
</li>
<li><p class="first">Addition to contextual menus
A module is free to add entries to the main menu bar or to any
contextual menus within GPS.</p>
<p>Most of the time, a module will decide to add new entries depending on
what the contextual menu applies to (the current context), although it
might also decide to do that based on what module is displaying the
contextual menu. Modules are identified by their name, which can
easily be tested by other menus.</p>
</li>
<li><p class="first">Context changes
Every time a new MDI child is selected, or when a module chooses to
emit such a signal, a context change is reported via a gtk+ signal. A
context is an Ada tagged type, created by the currently active
module. There exists different kinds of contexts, some for files
(directories and project), others for entities (same as before, but
with an entity name in addition, other for a location (adding line and
column),... New types of contexts can be created by the modules
without impacting the rest of GPS. All callbacks must test that the
context they receive matches what they can handle.</p>
<p>These contexts are also used for the contextual menus</p>
<p>A module can choose to emit the signal to report changes to its
context by emitting the signal. Other modules can they update their
content accordingly. This is how the switches editor updates the
project/directory/file it is showing when a new selection is done in
the project view.</p>
</li>
<li><p class="first">hooks and action hooks
Hooks are similar to the usual gtk+ signals.
Each hook is a named collection of subprograms to be called when the hook is
executed. Such hooks are executed by various parts of GPS when some actions
take place, like reloading the project, loading a file,...</p>
<p>These are the most powerful way for a module to react to actions taking place
in other parts of GPS, and to act appropriately.</p>
<p>In most cases, all the subprograms in a hook are executed in turn, and thus
they all get a chance to act.</p>
<p>However, in some other cases, the subprograms are only executed until one of
them indicates that it has accomplished a useful action, and that no other
subprogram from this hook should be called. These are called <strong>action hooks</strong>.
This is the fundamental mechanism used by GPS to request for instance the
edition of a file: the module that wishes to display a file executes the
hook “open_file_action_hook” with the appropriate argument. At this point, all
subprograms bound to this hook are executed, until one of them acknowledge that
it knows how to edit this file (and hopefully opens an editor). Then no other
subprogram from this hook is called, so that the file is not open multiple
times.</p>
<p>This mechanism is used for instance by the module that handles the external
editors. It is setup so that it binds to the “open_file_action_hook” hook. Any
time a file needs to be open, the callback from this module is called first.
If the user has indicated that the external editor should always be used, this
external editors module opens the appropriate editor, and stops the execution
of the hook. However, if the user didn’t wish to use an external editor, this
module does nothing, so that the callback from the source editor module is
called in turn, and can thus open the file itself.</p>
<p>See <tt class="file docutils literal"><span class="pre">gps-kernel-hooks.ads</span></tt> for more information on hooks.</p>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="documenting.html" title="7. Documenting your module"
>next</a> |</li>
<li class="right" >
<a href="kernel.html" title="5. The GPS Kernel"
>previous</a> |</li>
<li><a href="index.html">GPS Programer's Guide 5.3.0w documentation</a> »</li>
</ul>
</div>
<div class="footer">
© Copyright 2001-2015, AdaCore.
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.3.
</div>
</body>
</html>
|