-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathjx.html
232 lines (222 loc) · 13.6 KB
/
jx.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
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />
<title>Windowing system of the future in the mirror of the present — Nothing special</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css" />
<link rel="stylesheet" type="text/css" href="_static/classic.css" />
<script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
<script src="_static/doctools.js"></script>
<script src="_static/sphinx_highlight.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="copyright" title="Copyright" href="copyright.html" />
</head><body>
<div class="related" role="navigation" aria-label="related navigation">
<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="nav-item nav-item-0"><a href="index.html">Nothing special</a> »</li>
<li class="nav-item nav-item-this"><a href="">Windowing system of the future in the mirror of the present</a></li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="windowing-system-of-the-future-in-the-mirror-of-the-present">
<h1>Windowing system of the future in the mirror of the present<a class="headerlink" href="#windowing-system-of-the-future-in-the-mirror-of-the-present" title="Permalink to this heading">¶</a></h1>
<p><em>This article is still being written.</em></p>
<p>Graphical windowing systems (also called GUI, though, technically, GUI can
be organized around different principles) are considered to be one of the
primary components in design of modern computer systems. Windows are used to
manage output of multiple applications sharing the same output device and allow
for considerable increase in interaction bandwidth between user and computer.</p>
<p>Roughly speaking, there are two kinds of windowing systems currently in
existence: those which were designed more than 20 years ago and those built
around so called “web technologies”. I shall argue, in this article, that it may
be about time to design a new windowing system, which departs from the
traditional approach by borrowing obviously successful concepts from web
interfaces. It so appears, that one step in right direction was already made
many years ago (<a class="reference external" href="http://en.wikipedia.org/wiki/NeWS">Sun NeWS</a> windowing
system), but it was not the right time, and probably, not the right
implementation approach for that system to be successful.</p>
<section id="basic-architecture-and-abilities-of-the-traditional-windowing-system">
<h2>Basic architecture and abilities of the traditional windowing system<a class="headerlink" href="#basic-architecture-and-abilities-of-the-traditional-windowing-system" title="Permalink to this heading">¶</a></h2>
<p>It worth remembering that graphical windowing systems were first developed when
workstations had essentially minuscule performance compared to what we used to
these days. It won’t be an exaggeration to say that for a personal workstation
of the early 1980’s drawing an user interface on the display was the most
demanding task, both in terms of latency and throughput. This performance issue
was there to last. Only lately, somewhere around 2005, graphical capabilities
of an average workstation started to conveniently exceed the actual demand for
graphical quality. For 25 years beforehand, windowing systems continuously
struggled for every additional mbps of throughput and every reduced millisecond
of latency. Slow and expensive inter-computer networking posed an additional
limiting factor in traditional windowing system design.</p>
<p>Because of the reason stated, traditional windowing systems feature a rather
messy and unusual programing interfaces. Most of the time, application
programs has no need to use them, as during the prolonged period of continuous
evolution, layers of helper toolkits were layered atop the basic interface,
hiding it almost completely. What the higher level toolkits can not do, however,
is to alter the basic traits of windowing system operation, which are fully
mandated by its foundation.</p>
<p>If we choose to to abstract ourselves from the particularities of the
specific programing interfaces, it will become clear that graphical applications
don’t do anything too unusual. Typical such application shall interact with
two important devices: output, behaving like a <a class="reference internal" href="iotraits.html#rm-dev"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">remote</span> <span class="pre">memory</span></code></a>
interface and input, of simple <a class="reference internal" href="iotraits.html#mp-dev"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">message</span> <span class="pre">passing</span></code></a> type.</p>
<section id="drawing-the-output">
<h3>Drawing the output<a class="headerlink" href="#drawing-the-output" title="Permalink to this heading">¶</a></h3>
<p>To conserve resources, traditional windowing system tried to maintain as little
output state, as possible. It worst case, only information about pixels actually
present in user visible display area was retained. Therefore, every user action
leading to change of the exposed window area requires the controlled application
to redraw the window, either partially or completely.</p>
</section>
<section id="getting-the-input">
<h3>Getting the input<a class="headerlink" href="#getting-the-input" title="Permalink to this heading">¶</a></h3>
<p>While output device operation is fairly straightforward, default input device
historically evolved into a rather curious beast. First, it way too often relies
on a set of custom, used only in context of graphic subsystem, programing
interfaces. Second, it delivers an assortment of rather unrelated information
packets, which cover some aspects of user/application interaction, but not
other.</p>
<p>Information packets delivered through the typical windowing system application
input fall into several broad categories:</p>
<dl>
<dt><strong>Output state notifications</strong></dt><dd><p>Packets of this type inform application of the changes in its output state.
Output window can be resized, hidden, obstructed or suffer some other mishap,
of which application must be made aware.</p>
</dd>
<dt><strong>Input state notifications</strong></dt><dd><p>Also known as focus tracking. Customarily, it is up to a windowing system to
decide which specific part of application window is expected to act as
receiver of user input.</p>
</dd>
<dt><strong>Keyboard events</strong></dt><dd><p>Keys, pressed by user on a keyboard have no spatial information associated
with them. That’s where input state comes handy - key presses are assumed to
be delivered to the part of application which owns the focus.</p>
<p>If there are multiple keyboard or keyboard-like devices available on the
given systems their input messages are merged into a single stream is such a
way as to make them indistinguishable from each other. Application, of course,
always has an option to bypass the windowing system altogether and obtain
its input directly from operating system interfaces, but this is complicated
and may lead to undesirable effects, especially in unforeseen scenarios.</p>
</dd>
<dt><strong>Pointer events</strong></dt><dd><p>Everything said about keyboard events applies to pointer events as well, with
the obvious distinction of pointer events do have absolute spatial coordinates
attached.</p>
</dd>
<dt><strong>Lots of other stuff</strong></dt><dd><p>Depending on a specific windowing system implementation there can be many more
message formats governing other interesting aspects of application/windowing
system interoperability.</p>
</dd>
</dl>
<p>Information, pouring into the application from its input interface is not only
heterogeneous in format, but also in behaviour. Windowing system may spend quite
an effort to manage packets in the application input queue, adding, removing
and merging them as necessary to help application behave consistently and
compatibly to user expectations.</p>
<p>Newly developed varieties of input devices or application interoperability
patterns inevitably present a complicated problem to windowing system
developers. Additional packet formats are being added to already messy input
interface specification, and preexisting packets must be synthesised
artificially for each new packet arriving to enable older applications to work
somehow, further cluttering the input interface. Yet, many common user actions
are never implemented with the help of common windowing system input queue,
forcing applications supporting them to revert to underlying OS’ generic device
access methods.</p>
</section>
<section id="networking">
<h3>Networking<a class="headerlink" href="#networking" title="Permalink to this heading">¶</a></h3>
<p>Because hardware of old used for initial design of traditional windowing systems
was barely fast enough to support even a single user session properly, the whole
windowing system state, including its input and output devices existed as a
unique global object. Application loader would utilise this object to create
a context for an application being invoked, so that it will be able to
immediately start operating its graphical interface, without too much additional
hassle. In our modern age, multiple windowing system context objects can exist
on the same system simultaneously (Microsoft calls such objects
“windows stations”), yet for the above historical reasons they must be local
to the application.</p>
<p>Surprisingly, the necessity to maintain graphical subsystem state on the
application host turned out to be an advantage, rather then detriment. Remote
access client (in Microsoft ecosystem known as “remote desktop”) needs only
to work with low level user input and graphic output information. All the
complicated activities of contents rendering and window management happen on
the application host, which retains the application state over intended and
accidental user disconnects. The only major drawback of this approach, not
counting inevitable visual quality degradation of the graphical data, is
inability to access individual remote applications on the client side like if
they were local. This is not a theoretical problem, but rather an artifact of
the particular functionality loaded upon the windowing system context object.</p>
</section>
</section>
<section id="the-failure-which-is-x11">
<h2>The failure which is X11<a class="headerlink" href="#the-failure-which-is-x11" title="Permalink to this heading">¶</a></h2>
<p>Even in the days of first graphical user interfaces, some people tried to
perceive the future. After couple of not so successful attempts, X11 was
created, to become first “natively” networked graphical windowing system.</p>
</section>
</section>
<div class="clearer"></div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<div>
<h3><a href="index.html">Table of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Windowing system of the future in the mirror of the present</a><ul>
<li><a class="reference internal" href="#basic-architecture-and-abilities-of-the-traditional-windowing-system">Basic architecture and abilities of the traditional windowing system</a><ul>
<li><a class="reference internal" href="#drawing-the-output">Drawing the output</a></li>
<li><a class="reference internal" href="#getting-the-input">Getting the input</a></li>
<li><a class="reference internal" href="#networking">Networking</a></li>
</ul>
</li>
<li><a class="reference internal" href="#the-failure-which-is-x11">The failure which is X11</a></li>
</ul>
</li>
</ul>
</div>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/jx.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</div>
<script>document.getElementById('searchbox').style.display = "block"</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li class="nav-item nav-item-0"><a href="index.html">Nothing special</a> »</li>
<li class="nav-item nav-item-this"><a href="">Windowing system of the future in the mirror of the present</a></li>
</ul>
</div>
<div class="footer" role="contentinfo">
© <a href="copyright.html">Copyright</a> 2010 - 2023, Alex Dubov <[email protected]>.
Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 6.1.3.
</div>
</body>
</html>