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
|
<html>
<head>
<LINK REL="stylesheet" HREF="styles.css" TYPE="text/css">
<title>FOX-Toolkit</title>
<!-- HTML Copyright 2001 Paul Laufer -->
</head>
<body bgcolor=#ffffff link=#990033 vlink=#4a73ad alink=#ed004f text=#000000>
<!--header-->
<table align=center border=0 cellpadding=0 cellspacing=0 width=100% >
<tr><td bgcolor=silver colspan=5 align=right height=50><img src=art/oul_grey.gif align=left valign=top width=8 height=8><img src=art/foxlogo.png valign=bottom alt="FOX Toolkit" height=50 width=500 border=0 ></td>
<td bgcolor=#557faa valign=top align=right><img src=art/our.gif width=8 height=8></td>
</tr>
<!-- end header -->
<tr>
<td bgcolor=#557faa colspan=2 valign=top align=left> </td>
<td bgcolor=#557faa colspan=3><font color=#ffffff size=+1><center>
<!-- Page Title -->
Documentation: The Application Class
<!-- End Page Title -->
</center></font></td>
<td bgcolor=#557faa valign=top align=right> </td>
</tr>
<tr>
<td bgcolor=#557faa colspan=2> </td>
<td bgcolor=#ffffff valign=top align=left><img src=art/iul.gif width=8 height=8></td>
<td bgcolor=#ffffff> </td>
<td bgcolor=#ffffff valign=top align=right><img src=art/iur.gif width=8 height=8></td>
<td bgcolor=#557faa width=15> </td>
</tr>
<tr>
<td width=8 bgcolor=#557faa> </td>
<td valign=top bgcolor=#557faa link=#ffffff width=150>
<!-- start navbar content -->
<a href=fox.html><font color=#ffffff>Home</font></a><br>
<a href=news.html><font color=#ffffff>News</font></a><br>
<a href=download.html><font color=#ffffff>Download</font></a><br>
<a href=goals.html><font color=#ffffff>Goals & Approach</font></a><br>
<a href=doc.html><font color=#ffffff>Documentation</font></a><br>
<a href=faq.html><font color=#ffffff>FAQ</font></a><br>
<a href=rex.html><font color=#ffffff>FXRex</font></a><br>
<a href=screenshots.html><font color=#ffffff>Screenshots</font></a><br>
<br>
<a href=adie.html><font color=#ffffff>Adie</font></a><br>
<a href=pathfinder.html><font color=#ffffff>PathFinder</font></a><br>
<a href=calc.html><font color=#ffffff>FOX Calculator</font></a><br>
<br>
<a href=projects.html><font color=#ffffff>Projects</font></a><br>
<br>
<a href='http://fxpy.sourceforge.net'><font color=#ffffff>FXPy</font></a><br>
<a href='http://fxruby.sourceforge.net'><font color=#ffffff>FXRuby</font></a><br>
<a href='http://eiffelfox.sourceforge.net'><font color=#ffffff>EiffelFox</font></a><br>
<a href='http://eevolved.com/foxhole/'><font color=#ffffff>The FOX Hole</font></a><br>
<a href='http://takahr.dhis.portside.net/cgi-bin/rwiki.cgi?cmd=view;name=FOX+FAQ'><font color=#ffffff>Japanese Docs</font></a><br>
<br>
<center>
<a href="http://www.eff.org/br"><img SRC="art/freespeach.gif" border=0></a>
<p>
<a href="http://www.slashdot.org"><img SRC="art/slingerzbutton1.gif" border=0></a>
</center>
<!-- end navbar content -->
</td>
<td bgcolor=#ffffff> </td>
<td valign=top>
<!-- start main window content -->
<center><img src='art/foxstart.png'>
<BR><B>Documentation: The Application Class</B>
</center>
<p>
<p>
<b>The FXApp Class</b>
<hr>
The application object manages the message queue,
timers, chores, GUI updating, and other system facilities. Each FOX
application will have exactly one application instance.<br>
Every FOX application will start by constructing
one FXApp object prior to building the GUI. Usually, the FXApp object
is the last object to be deleted as well.
<p>Using the code below, the application object
will be constructed on the stack and hence is automatically destroyed when
the program terminates. Also, when the application object is
destroyed, all the windows and other resources it knows about are destroyed
as well.<br>
<center>
<table BORDER CELLSPACING=0 COLS=1 WIDTH="90%" BGCOLOR="#FFF8E1" NOSAVE >
<tr>
<td>
<br><tt>int main(int argc,char *argv[]){</tt>
<p><tt> // Make application</tt>
<br><tt> FXApp application("ApplicationName","VendorName");</tt>
<p><tt> // Open display</tt>
<br><tt> application.init(argc,argv);</tt>
<p><tt> // Make window</tt>
<br><tt> MainWindow* mainwindow=new MainWindow(&application);</tt>
<p><tt> // Create it</tt>
<br><tt> application.create();</tt>
<p><tt> // Show Window</tt>
<br><tt> mainwindow->show();</tt>
<p><tt> // Run</tt>
<br><tt> return application.run();</tt>
<br><tt> }</tt>
<br> </td>
</tr>
</table>
</center>
<p>In the first line of code above, an application
object is constructed. The constructor has two parameters, the application
name, and the vendor name. The application name and vendor name are
used to determine the applications registry settings.
<p>The next line of code initializes the application
object, passing in the command line arguments of the process. The
application object parses its own arguments and removes them, but leaves
the remaining arguments alone.
<p>The next line creates a toplevel window, passing
in a pointer to the application object.
<p>The call to the application object's create()
function realizes the entire widget tree, i.e. creates the necessary resources
in the system (X Server or Windows GDI), to turn what was up till that
point a collection of C++ data structures into a real-life application
which is able to
<br>receive events and draw on the screen.
<p>The final call to run() starts the toplevel event
loop. A typical application will not return from this loop until
the user closes the application.
<p>
<p>
<b>Event Loops</b>
<hr>Most GUI applications have something called an <b>event loop</b> or <b>message loop</b>.
Unlike batch-oriented programs which read a datafile, perform some processing, and then produce an
output file, a GUI driven application spends almost all its time in an event loop, waiting
for user input, determining where that input came from, and then dispatching
it to the proper function to perform some processing.
<br>Unlike batch oriented programs, these functions are typically very short, and mostly take
only very little time to execute, and so the user is in complete control of the application
most of the time.
<p>The events a GUI program processes can be of different
types:
<ul>
<li>Keyboard input;</li>
<li>Mouse movements;</li>
<li>Mouse buttons;</li>
<li>Inputs from other sources (e.g. network sockets, timers, signals, and so on);</li>
<li>Changes in selection and clipboard ownership;</li>
<li>Drag and drop events;</li>
<li>Window repaint events;</li>
<li>And other things which can happen to a window.</li>
</ul>
The application object is solely responsible for
coordinating all these events and dispatching them to the proper destination
where they are handled.
<p>FXApp performs delayed repaints on windows, i.e.
almost all events are prioritized over repaint events so as to delay expensive
redrawing as much as possible. Because of this, repainting can never
fall behind more than one repaint, and needless repaints are avoided as
much as possible. Also FXApp combines repaint rectangles so as to
minimize the video card hardware setup and teardown time relative to the
number of pixels drawn.
<p>
<p>
<b>Event Queues</b>
<hr>Certain devices, such as a moving mouse, can generate
events faster than some programs can process them. To prevent losing
events, events are commonly queued up, so programs can catch up as fast
as they can.
<br>Likewise, the drawing commands a GUI program
generates as its trying to draw buttons and other controls on the screen
are also queued up, so that the X server (or GDI on Windows) can take its
time to catch up.
<p>Finally, the X server may have its own event queue
and drawing queue, making for a total of <b>four queues</b>. All
these queues allow for much faster performance of applications, as bigger
chunks of data can be transmitted between the application and the X server,
and fewer context switches of video card and cpu hardware are needed.
<p>From the point of programming in FOX, the existence
of these queues is for the most part hidden, but in a few cases some special
functions are available that you may need to call:<br><br>
<blockquote>
<b><u>FXApp::flush(sync)</u></b>
<p>This function flushes the output queue, i.e. the
commands which have been already performed are pushed to the X server,
where they are executed.
<p>If we want to make sure that the display shows
the correct picture, however, just pushing the commands to the X server
is not enough:- sometimes we need to make sure that these commands
have been executed before we continue!
<p>When a TRUE is passed for the sync parameter,
the X server is forced to execute these commands.
</blockquote><br>
Sometimes, we want to check if there are any events,
but continue to do some processing if no events are available. Under
normal circumstances, returning to the event loop will cause our process
to block until there are events; but if there is stuff we may want to do,
this is of course not desirable. We have just the right solution
for this problem:<br><br>
<blockquote>
<b><u>FXApp::peekEvent()</u></b>
<p>This function will return TRUE if there are any
events ready to process, and FALSE if there are none. The peekEvent()
function can be used when we are doing a long calculation and we want to
check if the user has hit the STOP button.
</blockquote>
<p>
<p>
<b>Types of Event Loops</b>
<hr>There are several types of event loops supported,
each of them is appropriate for certain sistuations; most commonly, application
developers will however only call:<br><br>
<blockquote>
<b><u>FXApp::run()</u></b>
<p>This is the <i>top level </i>event loop, and it
will only terminate when the application is ready to call it quits.
When <b>run() </b>finally returns, its return value is the exit value passed
to <b>stop()</b> earlier.
<p><b><u>FXApp::stop(code)</u></b>
<p>This function terminates the top level event loop,
but also terminates all nested event loops which have been directly or
indirectly invoked from this top level loop. Each nested loop is
terminated with a code of <b><i>zero (0),</i></b> but the top level
event loop is terminated with the given <b><i>code</i></b>.
<p><b><u>FXApp::runOneEvent()</u></b>
<p>As the name implies, this function reads and then
processes <b><i>one (1) </i></b>single event, and then returns. It
is primarily interesting to use in combination with <b>peekEvent(),</b>
as <b>peekEvent() </b>returns TRUE if there is <i>at least one </i>event
ready to be processed.
<br>If there is no event ready, <b>runOneEvent()</b>
will block until there is at least one event.
<p><b><u>FXApp::runUntil(condition)</u></b>
<p>This function processes events until the variable
<b>condition</b>, which is passed as a reference, becomes non-zero.
</blockquote><br>
<b><i>Modal dialogs</i></b> are dialog panels which
block interaction with the rest of the application until they are completed.
For example, while trying to open a file, the application is unable to
interact in other way with the user until some file is selected and loaded
in.
<p>In FOX, the <i>only</i> difference between normal
dialogs and modal dialogs is <i>how</i> they are run:- modal dialogs are
run by calling:<br><br>
<blockquote>
<b><u>FXApp::runModalFor(window)</u></b>
<p>This function runs a <i>nested or recursive invocation</i>
of the event loop, i.e. it re-enters an event loop and processes events
for a while, and returns only when stopModal() or stop() is called.
<br>As long as runModalFor() is running, user-input
events to all other windows, except for window and its children, are being blocked:-
no interaction with other windows is possible until runModalFor() returns.<br>
When it returns, it returns the value passed to the stopModal() function, or 0 if stop()
is called to terminate the application.<br>
However, it is quite possible, and in fact common,
that one modal dialog invokes another. In that case, only the most
recently invoked dialog can be interacted with.
<p><b><u>FXApp::runModalWhileShown(window)</u></b>
<p>The function<b> runModalWhileShown()</b> runs
until either <b>stopModal()</b> is called or the specified window becomes
hidden. This is of interest when running popup menus or other temporary
windows.
<p><b><u>FXApp::stopModal(window,code)</u></b>
<p>Calling stopModal() causes the modal event loop
with the matching window to terminate with code. However, stopModal()
also causes all modal event loops which are nested more deeply to terminate
with code <b><i>zero (0).</i></b><b><u></u></b>
<p><b><u>FXApp::isModal(window)</u></b>
<p>This function returns TRUE if a modal loop is
in effect for the given window.
</blockquote><br>
<p>Modal dialogs are always run with runModalFor().
Because it is so common to construct a dialog on the stack, run it modally,
and then process the inputs thus obtained, there is a convenience member
function <b>FXDialogBox::execute() </b>which calls <b>create(),</b> <b>show(),</b>
and then <b>runModalFor() </b>in turn.
<p>The FXDialogBox also understands several messages,
for example ID_ACCEPT, ID_CANCEL, and SEL_CLOSE which call stopModal()
returning a code 1, 0, and 0 respectively.
<p>The return <b><i>code 0</i></b> for <b>FXDialogBox::execute()</b>
should <b><i>never</i></b> cause any <b><i>action</i></b> to be performed
as it is the code returned when the dialog box is cancelled or closed!!<br>
<p>
<p>
<b>GUI Updating</b>
<hr>As has been discussed before, the event loop blocks
when no events are available. Prior to blocking, all windows which
have been marked as dirty are repainted. One other thing that happens
just prior to blocking is the GUI update process, which periodically refreshes
all widgets by interrogating the application state. Each GUI update
takes only a little time, yet the total number of widgets may be large.
<br>The GUI update is peformed just prior to blocking,
so at the time it is being performed there is really nothing else for the
application process to do (or it would be doing it!).
<p>The GUI update is normally started by calling:
<br>
<blockquote>
<b><u>FXApp::refresh()</u></b>
<p>This function reschedules another GUI update to
be performed in the future.
<p><b><u>FXApp::forceRefresh()</u></b>
<p>Calling this function will cause an immediate
GUI update pass to be performed. Unlike the normal GUI update, which
takes place unobstrusively one and a time, prior to blocking, forceRefresh()
will not return until all windows have been refreshed.
<p>It is therefore quite expensive, and should be
used only when strictly necessary.
</blockquote><br>
<p>The GUI update has no impact on the perceived
speed of an application because between each pair of GUI updates performed,
a check for events is performed.
<br>
<p>
<p>
<b>Visuals</b>
<hr>
An FXVisual is a description of the pixel organization
on the display. For example, some high-quality graphics cards can do 24
bits per pixel; other graphics cards may be limited to 16, 15 bits per
pixel, or even just 8 bits/pixel. FOX programs can even work on 4
bit/pixel (VGA mode) and 1 bit/pixel (monochrome), although it wouldn't
be as much fun!
<p>Besides depth (number of bits/pixel), there are
also other characteristics which come into play describing the pixel organization,
such as colormaps, and wether or not a colormap can be written or not,
and the byte and bit organization.
<p>Colormaps are commonly used on 8-bit/pixel systems.
Most hardware only supports one hardware colormap, and this must be shared
among all programs on the display. Because legacy toolkits such as
Motif do not deal with full colormaps very gracefully, FOX applications
deliberately do not try to grab all 256 colors from the colormap, but only
125 colors. Images and Icons are dithered to get the best possible
rendering given the number of colors available.
<p>You can improve the look of your program quite
easily, however, as the maximum number of colors which the default visual
tries to allocate can be easily changed using a command line argyment;
for example, <b>"myapp -maxcolors 256"</b> will start myapp
in such a way as to attempt to acquire all 256 colors from the colormap.
<p>Because other programs may already be running,
the desired gamut of colors may not be available. If the exact color
can not be obtained, FOX will try to find the <i>closest color </i>available
and use that.
<p>Normally, the FXVisual a window uses is copied
from its parent. You can change this visual for each window, or you
can call:<br>
<blockquote>
<b><u>FXApp::setDefaultVisual(visual)</u></b>
<p>This function will change the default visual to
be used for all toplevel windows; the child-windows will simply inherit
the visual from their parent.
</blockquote><br>
Alternatively, the maximum number of colors can also
be set via the registry, using the <b>maxcolors</b> key under <b>[SETTINGS]
</b>any number less than or equal to 256 colors may be specified, FXVisual
will determine the best gamut to pick from the allowable number of colors.<br>
<p>
<p>
<b>Wait Cursors</b>
<hr>Sometimes, an application needs to undertake a
long task, such as e.g. loading a big file. In such cases, it is
good form to present the user with some feedback to indicate that the application
may be temporarily unresponsive. Common ways to do this are progress
bars and changing the cursor shape to a stopwatch, or hourglass, or something
like that.
<p>FXApp supports this by means of the following
functions:<br>
<blockquote>
<b><u>FXApp::beginWaitCursor()</u></b>
<p>This will change the cursor shape for all windows
to the stopwatch cursor, or the cursor designated by <b>setWaitCursor().
</b>Calls to <b>beginWaitCursor() </b>and <b>endWaitCursor() </b>can be
nested in a stack-like fashion, with only the first call to <b>beginWaitCursor()
</b>and last call to <b>endWaitCursor() </b>actually changing the cursor
shape.
<p><b><u>FXApp::endWaitCursor()</u></b>
<p>A matching call to <b>endWaitCursor() </b>will
restore the original cursor for each window.
<p><b><u>FXApp::setWaitCursor(cursor)</u></b>
<p>This will change the cursor shape used in during
a beginWaitCursor() endWaitCursor() pair.
<p><b><u>FXApp::getWaitCursor()</u></b><b><u></u></b>
<p>This returns the current FXCursor being used as
hourglass or stopwatch cursor.
</blockquote><br>
The beginWaitCursor() and endWaitCursor() calls can
be nested pairwise, so that a functions which bracket a long calculation
by means of a beginWaitCursor/endWaitCursor pair can call upon each other.
<br>
<p>
<p>
<a name="DRAGTYPE"><b>Drag Types</b></a>
<hr>Exchanging data via the Primary Selection, the Clipboard, or by means of Drag and Drop
requires that all applications agree with the type of data being exchanged.<br>
This is done by registering a <b>Drag Type</b>. In most cases, the name being
registered should be a mime-type, such as <b>"text/plain"</b> or <b>"image/gif"</b>.
<p>
Manipulating drag types is done with the following API's:<p>
<blockquote>
<p><b><u>FXApp::registerDragType(name)</u></b>
<p>This will register a new drag type based on the mime type name.
<p><b><u>FXApp::getDragTypeName(dragtype)</u></b>
<p>Obtain the name of a previously registered drag type.
</blockquote><br>
<p>
<!-- end main window content -->
</td>
<td bgcolor=#ffffff> </td>
<td bgcolor=#557faa width=15> </td>
</tr>
<tr>
<td colspan=2 bgcolor="#557faa" align=center>
</td>
<td bgcolor=#ffffff valign=bottom align=left><img src=art/ill.gif width=8 height=8></td>
<td bgcolor=#ffffff> </td>
<td bgcolor=#ffffff valign=bottom align=right><img src=art/ilr.gif width=8 height=8></td>
<td bgcolor=#557faa width=15> </td>
</tr>
<tr>
<td valign=bottom align=left bgcolor=#557faa><img src=art/oll.gif width=8 height=8></td>
<td colspan=4 bgcolor=#557faa> </td>
<td valign=bottom align=right bgcolor=#557faa><img src=art/olr.gif width=8 height=8></td>
</tr>
</table>
<address>Copyright 1997-2002 <a href=mailto:jeroen@fox-toolkit.org>Jeroen van der Zijp</a></address>
<!-- Created: Mon Apr 10 11:20:32 CEST 2000 -->
<!-- hhmts start -->
<!-- hhmts end -->
</body>
</html>
|
