| __init__.py |
0 |
0 |
0 |
100% |
| broadcast/__init__.py |
0 |
0 |
0 |
100% |
| broadcast/admin.py |
4 |
0 |
0 |
100% |
| broadcast/apps.py |
4 |
0 |
0 |
100% |
| broadcast/migrations/0001_initial.py |
8 |
0 |
0 |
100% |
| broadcast/migrations/0002_auto_20181127_0350.py |
7 |
0 |
0 |
100% |
| broadcast/migrations/__init__.py |
0 |
0 |
0 |
100% |
| broadcast/models.py |
14 |
3 |
0 |
79% |
| broadcast/urls.py |
3 |
0 |
0 |
100% |
| broadcast/views.py |
24 |
19 |
0 |
21% |
| features/environment.py |
9 |
0 |
0 |
100% |
| features/steps/add_task.py |
20 |
0 |
0 |
100% |
| features/steps/audit_task.py |
36 |
0 |
0 |
100% |
| features/steps/change_role.py |
10 |
0 |
0 |
100% |
| features/steps/chat.py |
39 |
0 |
0 |
100% |
| features/steps/common.py |
40 |
2 |
0 |
95% |
| features/steps/complete_task.py |
25 |
0 |
0 |
100% |
| features/steps/login.py |
16 |
0 |
0 |
100% |
| features/steps/peerhelp.py |
87 |
0 |
0 |
100% |
| features/steps/signup.py |
19 |
0 |
0 |
100% |
| features/steps/task_status.py |
35 |
0 |
0 |
100% |
| peerhelp/__init__.py |
0 |
0 |
0 |
100% |
| peerhelp/admin.py |
7 |
0 |
0 |
100% |
| peerhelp/apps.py |
4 |
0 |
0 |
100% |
| peerhelp/forms.py |
10 |
0 |
0 |
100% |
| peerhelp/migrations/0001_initial.py |
7 |
0 |
0 |
100% |
| peerhelp/migrations/0002_auto_20181111_2100.py |
7 |
0 |
0 |
100% |
| peerhelp/migrations/0003_auto_20181112_0307.py |
7 |
0 |
0 |
100% |
| peerhelp/migrations/0004_auto_20181112_0330.py |
6 |
0 |
0 |
100% |
| peerhelp/migrations/0005_auto_20181112_0331.py |
6 |
0 |
0 |
100% |
| peerhelp/migrations/0006_auto_20181112_0355.py |
5 |
0 |
0 |
100% |
| peerhelp/migrations/__init__.py |
0 |
0 |
0 |
100% |
| peerhelp/models.py |
40 |
3 |
0 |
93% |
| peerhelp/urls.py |
3 |
0 |
0 |
100% |
| peerhelp/views.py |
230 |
10 |
0 |
96% |
| privatemessages/__init__.py |
0 |
0 |
0 |
100% |
| privatemessages/admin.py |
4 |
0 |
0 |
100% |
| privatemessages/apps.py |
4 |
0 |
0 |
100% |
| privatemessages/migrations/0001_initial.py |
8 |
0 |
0 |
100% |
| privatemessages/migrations/__init__.py |
0 |
0 |
0 |
100% |
| privatemessages/models.py |
16 |
1 |
0 |
94% |
| privatemessages/urls.py |
3 |
0 |
0 |
100% |
| privatemessages/utils.py |
25 |
1 |
0 |
96% |
| privatemessages/views.py |
104 |
37 |
0 |
64% |
| tasks/__init__.py |
0 |
0 |
0 |
100% |
| tasks/admin.py |
5 |
0 |
0 |
100% |
| tasks/apps.py |
4 |
0 |
0 |
100% |
| tasks/forms.py |
14 |
0 |
0 |
100% |
| tasks/migrations/0001_initial.py |
6 |
0 |
0 |
100% |
| tasks/migrations/0002_researchtasks_worker_id.py |
7 |
0 |
0 |
100% |
| tasks/migrations/0003_auto_20181020_0515.py |
7 |
0 |
0 |
100% |
| tasks/migrations/0004_auto_20181020_0551.py |
5 |
0 |
0 |
100% |
| tasks/migrations/0005_auto_20181020_0600.py |
5 |
0 |
0 |
100% |
| tasks/migrations/0006_auto_20181020_0602.py |
5 |
0 |
0 |
100% |
| tasks/migrations/0007_auto_20181020_1706.py |
7 |
0 |
0 |
100% |
| tasks/migrations/0008_auto_20181028_0152.py |
5 |
0 |
0 |
100% |
| tasks/migrations/0009_audit.py |
7 |
0 |
0 |
100% |
| tasks/migrations/0010_auto_20181028_0621.py |
6 |
0 |
0 |
100% |
| tasks/migrations/0011_auto_20181028_0626.py |
5 |
0 |
0 |
100% |
| tasks/migrations/0012_auto_20181028_0658.py |
7 |
0 |
0 |
100% |
| tasks/migrations/0013_auto_20181028_1644.py |
5 |
0 |
0 |
100% |
| tasks/migrations/0014_auto_20181028_2258.py |
5 |
0 |
0 |
100% |
| tasks/migrations/0015_auto_20181119_1951.py |
5 |
0 |
0 |
100% |
| tasks/migrations/__init__.py |
0 |
0 |
0 |
100% |
| tasks/models.py |
46 |
2 |
0 |
96% |
| tasks/urls.py |
3 |
0 |
0 |
100% |
| tasks/views.py |
264 |
57 |
0 |
78% |
| test/__init__.py |
0 |
0 |
0 |
100% |
| test/factories/__init__.py |
0 |
0 |
0 |
100% |
| test/factories/user.py |
8 |
0 |
0 |
100% |
| users/UserRoles.py |
8 |
1 |
0 |
88% |
| users/__init__.py |
0 |
0 |
0 |
100% |
| users/active_user.py |
10 |
0 |
0 |
100% |
| users/admin.py |
3 |
0 |
0 |
100% |
| users/apps.py |
0 |
0 |
0 |
100% |
| users/changeRolesForm.py |
18 |
0 |
0 |
100% |
| users/context_processors.py |
38 |
4 |
0 |
89% |
| users/migrations/0001_initial.py |
10 |
0 |
0 |
100% |
| users/migrations/0002_auto_20181022_2047.py |
7 |
0 |
0 |
100% |
| users/migrations/0002_auto_20181022_2131.py |
5 |
0 |
0 |
100% |
| users/migrations/0003_merge_20181028_0051.py |
5 |
0 |
0 |
100% |
| users/migrations/0004_auto_20181028_2258.py |
6 |
0 |
0 |
100% |
| users/migrations/__init__.py |
0 |
0 |
0 |
100% |
| users/profile.py |
38 |
9 |
0 |
76% |
| users/settings.py |
38 |
0 |
0 |
100% |
| users/signUpForm.py |
11 |
0 |
0 |
100% |
| users/signup.py |
21 |
1 |
0 |
95% |
| users/templatetags/__init__.py |
0 |
0 |
0 |
100% |
| users/templatetags/extra_filters.py |
4 |
0 |
0 |
100% |
| users/urls.py |
6 |
0 |
0 |
100% |
| users/user.py |
107 |
19 |
0 |
82% |
| users/wsgi.py |
4 |
4 |
0 |
0% |


Writing your own story is one step for you to know yourself better.All you need to have is paper and pen to write down your thoughts, your feelings, and your experiences where you have learned a lot. You learn from your mistakes and you can freely admit to yourself what are the truth about you.
A simple note for your experiences and what you feel will evaluate you and tell you that there are more things that you need to do, there is still a long journey that you must take. You're writing a simple diary to jot down and pour all the things that you keep to yourself, the things that you cannot tell to other people and you can only expressed it when you write it down.
You can write your life story and be your master piece. Your life story tells all about who you are and the greatest obra that you can make is to map your own story.
I began writing
I started writing when I was still in elementary. I don't have many companions and friends because I prefer to stay alone. I usually leave my class because I don't want to stay in school. I always want to be absent because I don't want to be with other kids and I want a quiet environment.
I usually write when I am alone and make stories on my own. I love writing life stories and fiction stories. Whenever I'm sad, I'm happy, or I'm in trouble, I write. I 'm not so much in talking with other people that's and my best way to express my own thoughts is through writing.
"Better to write for yourself and have no public,
than to write for the public and have no self. -Cyril Connolly"
I know that in writing I can be myself. I can explore things that I cannot do in the physical world and through writing I can voice out what's in my mind.
"Quiet people have the loudest minds.-Stephen King"
I never dreamed to be writer
As far as I know I never dreamed to be a writer. I only start writing because I'm not that sociable and only paper listens. I tried to be as friendly as other children do but I just can't do the thing. I'm not as famous as any writers do but I'm being different in my own way of writing.
As one of the writers said, you can never start and learn how to write if you don't even try to write a word. They say, you can only learn how to write if you turn on the faucet. I was once like this, a person scared to write but eventually I learned how to write because I tried to do it. I made my life as my inspiration and I became honest to myself, admitting all my mistakes and what I really feel.
I may not be the best writer but I can proudly say that I'm unique as the other writers do. I have my own way of writing style, my own way of writing skills and through writing I became free.


The plugins searchable are provided by the issue tracker of the Franz plugin repository and Githubs search API. If you cant find what you're looking for you can always look yourself and use the add button manually.


This chapter describes the structure of GEOS and the various system components and services used by applications. Nearly all programmers will want at least to browse this chapter before continuing with GEOS application development. The structures and architectures of the 8088 and 80x86 processors are reviewed in Appendix A.
1 GEOS Overview
2 The System Architecture
2.1 Applications
2.2 Libraries
2.3 The Kernel
2.4 Device Drivers
2.5 The User Interface
3 Object-Oriented Programming
3.1 Objects, Messages, and Methods
3.2 Classes and Inheritance
4 Multitasking and Multithreading
5 The GEOS User Interface
5.1 The Generic User Interface
5.2 The Scalable User Interface
5.3 Windows and Window Management
5.4 Input
5.5 Menus and Dialog Boxes
5.6 Scrolling Views
5.7 Visible Object Classes
5.8 Geometry Manager
5.9 Lists
5.10 Other Gadgets
5.11 Managing Documents and Files
5.12 Multiple Document Interface
5.13 Clipboard and Quick-Transfer
5.14 General Change Notification
5.15 Help Object
6 System Services
6.1 Memory
6.2 Virtual Memory
6.3 Local Memory and Object Blocks
6.4 Item Databases
6.5 Graphics System
6.6 Text
6.7 Print Spooler and Printing
6.8 Timers
6.9 Communications
6.10 Math support
6.11 International Support
7 Libraries
8 Device Drivers
GEOS is a state-of-the-art graphical operating system combining the latest software technology with numerous innovations. Its tightly coded assembly language and object-oriented system turns the humblest 8088-based PCs with as little as 512 K of RAM into graphical workstations. On higher-end machines, GEOS is in a class by itself--performance on 80286, 80386, and 80486 machines with extended or expanded memory is exceptional.
Besides being coded entirely in object-oriented assembly language (a concept and language developed by Geoworks), GEOS is built on one of the most sophisticated operating system architectures available for PCs. Most of the GEOS kernel and system is composed of dynamically-linkable libraries; in addition, developers can create their own libraries to support entire generations of applications.
GEOS also includes true pre-emptive multitasking, multiple threads of execution within single applications, built-in outline font technology, and drivers for various devices such as printers, mice, video cards, file systems, keyboards, parallel and serial ports, task switchers, power management systems, and font engines. Development for GEOS is easy and quick; much code traditionally required by applications has been provided within the system software, thereby reducing time spent by application programmers on coding and debugging.
In addition, GEOS employs a breakthrough generic user interface. Applications specify their user interface needs, and the system dynamically chooses the proper manifestation of the UI at run-time through the use of specific UI libraries. Complex drawing and geometry are handled automatically by the UI library. The generic UI allows applications to work with various UI specifications without being recompiled. Users can choose the look and feel they want without burdening the application programmer with extra coding.
Among the other advanced features included in GEOS are a single imaging model providing true WYSIWYG (a single image is used both for drawing to the screen and for printing); automatic scaling and scrolling of displayed data; dynamic memory management and virtual memory; an item database manager; a graphic object library including support for resize, move and scale operations; complex and complete text formatting and editing; specialized generic controller objects providing standard user interface and functionality; and full network support. Several other mechanisms and libraries not mentioned here are also built into the system.
The following sections of this chapter describe many of these concepts and implementations, providing a quick-view of the GEOS system as a whole. More information may be found on individual topics elsewhere in this developer's kit. This chapter provides the background information necessary, however, to take full advantage of all that GEOS has to offer the application developer.
The GEOS system as a whole consists of several layers. The topmost layer contains applications. Users interact directly with these applications, which use dynamic libraries on the next layer. One of the major libraries is the User Interface Library, commonly known as the UI. Both the libraries and applications interact with the kernel, the heart of the operating system. The kernel communicates with device drivers, which function as the final GEOS interface to physical devices such as video screens, printers, and file systems.
A GEOS application can take advantage of the various kernel and UI mechanisms to provide some set of functionality to the user. An application is made up primarily of two parts: The first part defines the application's user interface using objects and functions provided by the User Interface Library. The second part consists of the code of the application including procedures, functions, and object-specific code.
GEOS libraries are bodies of code or collections of objects that are dynamically loaded into memory when called for by applications or by other libraries. The use of libraries reduces the amount of code within application resources and increases application performance. In addition, library routines and objects may be shared by several different applications at once, reducing duplicated code in memory.
Many standard libraries are provided with GEOS and are available to all developers. Among these are a text object library, a graphic object library, a an import/export library and others. In addition, developers can easily create their own libraries with the developer kit tools.
The GEOS kernel is the core of the operating system, providing all the basic services needed by the system. It provides multitasking, memory management, object creation and manipulation, windowing, process management, file system access, inter-application communication, message dispatching, and scores of basic graphic primitives. The kernel provides nearly 1000 routines usable by applications and libraries, though most applications will use only a portion of them.
GEOS device drivers isolate the system and applications from the specific needs and foibles of a user's hardware. Drivers translate the generic actions of an application (such as opening a file) into the specific needs of the hardware or system in use (such as the specific call to MS-DOS to open the file). By isolating the system from hardware specifics, drivers allow GEOS to be expanded in the future to use new devices and engines without recompiling applications.
Drivers are provided with the system for printers, video cards, mice, keyboards, serial and parallel ports, file systems, task switchers, power management hardware, and font engines. In the future, developers will be able to develop their own drivers for new hardware and file systems.
Most applications and libraries will access drivers through kernel calls. Drivers are also accessible to applications and libraries directly.
The GEOS User Interface (UI) is a special entity. While it consists primarily of dynamic libraries, it can be thought of as a user interface driver.
Applications define their UI needs in a high-level language (called Goc and developed by Geoworks) interpreted by a special C preprocessor. Applications in general do not have to manifest windows, scrollbars, buttons, menus, or dialog boxes; instead, they use generic objects from the provided UI object library. These generic objects have no inherent visual representation; instead, they have a strictly-defined functionality and API.
A Specific User Interface library, at run-time, determines the visual representation each object takes depending on its context. For example, a GenInteraction generic object may appear as a menu, a dialog box, or a merely a grouping of other generic UI gadgets. Additionally, a menu GenInteraction may be represented as a vertical menu in one Specific UI but as a horizontal bar of choices in another.
Although such a system may appear to take some control of the application's user interface away from the programmer, in actuality quite the opposite is true. The use of a generic UI frees the programmer to concentrate on other issues and features without worrying about whether the application conforms to one or more specifications. The programmer does not have to worry about window positioning or clipping areas (unless he or she wants to), and menus and dialog boxes are almost entirely automatic.
Additionally, the programmer can set
hints
for individual generic objects; hints can help the specific UI decide how the object should appear or be arranged on the screen. Not all hints are allowed in all specific UIs, so a particular specific UI may ignore certain hints while implementing others. For example, a dialog box that has three buttons within it may have the hint
HINT_ORIENT_CHILDREN_VERTICALLY
to indicate the buttons should appear in a column rather than a row.
Object-Oriented Programming (OOP) is a popular way of organizing programs, especially programs using graphical user interfaces. GEOS is an object-oriented system, programmed entirely in Object Assembly, a Geoworks innovation. This section describes the concepts behind OOP and how it is implemented in GEOS. If you are familiar with OOP concepts, you may skip this section; because terminology can differ from system to system, however, you will probably want to at least skim the rest of the section. (A full discussion of GEOS messaging and object manipulation can be found in the GEOS Programming chapter.)
Object-Oriented Programming is simply a way to organize code and data differently from traditional procedural programming. Anything done with procedural programming can be done in an object-oriented way and vice versa. However, OOP offers several significant advantages over procedural programming:
Objects, Messages, and Methods
Procedural programming uses routines that act with globally-accessible or locally-defined data. Those routines must know about other routines in the program and must understand the data structure and organization used by other routines. Although some amount of isolation is applied to each routine, in essence they are all part of the greater whole of the program.
Objects, in their simplest sense, consist of data ( instance data ) and routines ( methods ) that act on that data. Objects may interact with each other but may not alter other objects' instance data; this rule leads to strict modularity and cleaner program design. Objects do not need to understand how other objects work or how another object's instance data is arranged; instead, only the interface to the other object is required.
Objects interact with each other via messages . Messages may indicate status, provide notification, pass data, or instruct the recipient to perform an action. When an object receives a message, it executes an appropriate method . A method may change the object's instance data, send messages to other objects, call kernel routines, or perform calculations--anything that can be done in a normal program procedure can be done in a method. (Note that occasionally the term message handler is used for method .)
Every object is represented by an Object Pointer (optr), a data structure that uniquely identifies the object's location in the system. This data structure is a combination of two special memory handles that provide abstraction of the object's location--this allows the object to be moved in memory or swapped to disk, or even saved to and retrieved from files. Object pointers are used to identify objects in many situations, the most common being when a message is sent. The intended recipient of the message is indicated by its optr.
Objects may interact with each other even if they are in different threads of execution. This is made possible by message queues and the kernel's message dispatcher . When a message is sent, it is first passed to the kernel's dispatcher with the recipient's optr. The dispatcher then puts the message in the recipient object's message queue. If other messages have been sent to the recipient but not handled yet, then the message will wait in the queue until the others have been handled. Otherwise, the message will be handled immediately. (For timing-critical messages, the sender can indicate that the message must be handled immediately; this is important in a multithreaded system.)
A thread is a single entity that runs a certain set of code and maintains a certain set of data. Only one thread may be using the processor at any given time; when a context switch occurs, one thread loses the processor and another takes it over. Each thread may run code for many objects, and an application can have several threads.
As an example, the figure below shows the conceptual model of a Counter object. The Counter maintains a single instance data field,
currentCount
. It also has three predefined actions:
CounterIncrementCount()
This method handles the message
MSG_COUNTER_INCREMENT
. Its purpose is to increment the
currentCount
instance data field. When the count reaches the maximum (in this case, 100), then the counter resets itself.
CounterReturnCur()
This method handles the message
MSG_COUNTER_RETURN_CUR
. It returns the value of the
currentCount
instance data field.
CounterReset()
This method handles the message
MSG_COUNTER_RESET
. It sets the
currentCount
instance data field to zero.Messages can carry data (parameters) with them and can also have return values. For example, if the Counter in the example could be set to an arbitrary value (rather than reset to zero), the object sending the set message would have to indicate the value to be set. This would be passed in the same way as a normal C parameter.
If a message is supposed to return a value to the sender, the sender must make sure the message is handled immediately. In this case, the message acts like a remote routine call, blocking the thread of the caller until the message has been handled and the value returned.
Objects can also share data when necessary. Rather than share instance data, however, each object can have an instance data field containing the handle of a sharable block of memory holding the subject data. Then each object could access the shared block through the normal memory manager. Handles are offsets into a table maintained by the kernel; this table contains pointers to the actual memory. This abstraction of the pointer allows the kernel to move the memory block around without forcing everything else to update their pointers. Handles can also be passed as message parameters, allowing large blocks of data to be passed along from object to object.
The figure above shows an example of two objects interacting via messages. In this example, the Requestor object requires the Calculator object to perform a calculation given two numbers. However, since the timing of the calculation is not critical, the result is not returned but is instead sent back by the Calculator object in a subsequent message. This allows the Requestor object to continue with other tasks until the result is ready. (Note that if the Calculator object could be used by more than one requestor, it would have to also be passed the requestor's object pointer. Otherwise, it would have no idea where to send the return message. This example assumes the Calculator object is used by only the one requestor and inherently knows the requestor's optr.)
If every object had to be coded and debugged once for each time it was used, OOP would provide few benefits over standard procedural programming. Many objects share similar functionality and could easily make use of the same code over and over again. The concepts of class and inheritance allow objects with similar data structures and methods to use common code.
The class is actually where the functionality of objects is defined. Every object is simply an
instance
of a class, a manifestation of the instance data and methods defined for the class. For example, the Counter object of Objects, Messages, and Methods
could be an instance of a class called
CounterClass
. Other counters sharing the same characteristics would also be instances of
CounterClass
, each having its own value in its own instance data field.
A main benefit of the implementation of classes in GEOS is that objects can be created and destroyed during execution. Class definitions are stored separately from an individual instance's data; each instance knows where its class is located. Therefore, if two instances of a particular class exist, they both point to a single copy of the class definition. Since the code is stored in the class definition, the instances can use up only as much memory as their data fields require; each instance does not need to store its own method code.
Another, more powerful, benefit is gained through the implementation of inheritance. In many cases, objects will be similar but not identical. This means that their classes are also similar but not identical. Inheritance overcomes this problem through the use of superclasses and subclasses .
A class provides a certain set of instance data and methods. A subclass inherits all the instance data structures and methods of its superclass, modifying or enhancing them to provide some different functionality.
Take, for example, the class
CounterClass
. An instance of this class would provide a counter with certain features: The counter goes from zero to 100, it can be reset manually, it resets automatically when it reaches 100, and its value is retrieved with the use of a certain message. However, suppose we need a counter that does all those things
and
allows the counter to be set to an arbitrary value with the use of a new message.
Without inheritance, we would have to write all the code for
CounterClass
over again as a new class, adding the new method. However, by creating a subclass of
CounterClass
(let's call it
CounterSetClass
), we can inherit all the methods and data structures of
CounterClass
without recoding them. Instead, we simply add the new message and the code for the new method. (It is also possible to modify inherited methods in a subclass.) This example of
CounterClass
and
CounterSetClass
is shown in the figure above.
The inheritance implemented in GEOS is actually much more complex and sophisticated than this simple example shows. You may never need to know more than the above concepts, however.
GEOS classes may be of a special type known as a variant . Variant classes do not initially know what their superclass is; instead, the superclass is determined by context for each instance of the variant class. This is a complicated topic that is discussed later in the documentation.
Multitasking is the ability to have multiple processes running simultaneously on a single system. In actuality, PCs have only one processor and only one task can run at any given moment; the operating system must manage the processor and allocate time to all the different programs running at once.
A thread is a single entity that runs in the GEOS system. Threads may be event-driven or procedural. An event-driven thread runs objects and has a message queue (also called an event queue). The thread receives messages for its objects and is only active when the objects are handling the messages. If an event-driven thread never receives a message, it will never use the processor. Procedural threads execute sequential code such as functions or procedures in C. Procedural threads do not have a message queue and do not run objects.
Cooperative multitasking , used in some operating systems, requires all processes running to cooperate with the operating system. The system has a routine which each process must call periodically; this routine (called a Context Switch routine) checks if any other processes are waiting to run. If other processes are waiting, priorities are checked and the process with the highest priority takes over the processor.
GEOS uses preemptive multitasking , in which threads are given the illusion that they have nonstop access to the processor. A preemptive system periodically interrupts the thread running and checks for other waiting threads; if there are any, the system will switch context automatically. Programs do not have to call a context switch routine, a cumbersome requirement in many cases.
GEOS also maintains a knowledge of thread priority . Every thread (including the kernel and user interface) has a base priority and a current priority; the base priority rarely changes, while the current priority decreases with recent processor usage. GEOS maintains these priorities intelligently, making sure that no thread ever uses the CPU more than its share of the time.
Any application running in GEOS may have multiple threads. This is useful, for example, in a spreadsheet application, where complex and time-consuming calculations may be done by a background thread that wakes up only when calculations need to be made. Use of multiple threads can make the application appear to be extraordinarily fast; the user can continue to navigate menus and use other UI gadgetry while the application is also doing something else.
The GEOS User Interface (UI) maintains the interaction between each application and the user. It provides several necessary and many extra services for applications, relieving programmers from building much of the basic UI functionality into their applications. The structure, components, and services of the GEOS UI are outlined below.
A User Interface (UI) specification is, essentially, a set of rules and conventions used to determine the interaction between a user and an application. Over the years, UI specifications have evolved from basic command-line shells to the standard graphical and pen-based systems in use today. No doubt you have come across several graphical UI specifications currently in use--Macintosh, Open Look, Presentation Manager, and OSF/Motif are a few examples.
Each of these specifications represents a particular implementation of the basic functionality required for application-user interaction. The basic functions are similar; only the implementation is different. Therefore, each of these specifications is referred to as a Specific UI .
GEOS employs a Generic UI --an implementation-independent way of defining an application's user interface. To the user, this means a single application executable can be used in any of several specific UI implementations. To the developer, this means relief from many of the UI definition tasks normally associated with graphical user interfaces.
The Generic UI can be thought of as a UI driver--a layer of abstraction between the application and the UI implementation. The programmer defines his needs in terms of basic functionality and user involvement, leaving the actual implementation (decisions about color, shape, menu structure, etc.) up to the system at run-time.
The application defines its UI by selecting certain objects from the Generic UI Library. Each of these objects has certain
attributes
that determine its specific implementation. In addition, each generic object may be assigned
hints
. Hints help the Specific UI Library determine the proper context and subjective information required to fully flesh out the proper manifestation of each generic object (for example, a GenPrimary window object can have special sizing restrictions suggested with various hints such as
HINT_FIXED_SIZE
and
HINT_INITIAL_SIZE
).
Attributes represent objective information which does not change with the specific UI in use. In general, attributes determine the basic functionality of the object regardless of its manifestation on the screen. For example, a GenView may have its scrollable attribute set; this means that in all Specific UIs, the View will have some sort of scrollers. However, one Specific UI might implement the scrollers as bars and another might implement them as dials or cranks.
Attributes are always allocated space in an object's instance data regardless of whether the attribute it set. For example, all GenView objects have a bit specifying whether it is scrollable or not. Attributes are used, therefore, primarily for determining the object's functionality rather than its appearance.
Hints represent subjective or contextual information about objects. Hints are different from attributes in two main aspects: First, hints may be ignored by certain Specific UIs. Suppose, for example, that a given Specific UI only allowed horizontal ordering of components within dialog boxes. This specific UI would ignore the hint
HINT_ORIENT_CHILDREN_VERTICALLY
applied to any GenInteraction object implemented as a dialog box.
Second, hints are dynamically added to each object's instance data in a special format known as variable data . Variable data fields are not allocated within the object's instance data unless they are used. Thus, objects with fewer hints use less memory. Attributes, on the other hand, must exist in the object's instance data whether they are used or not, and they therefore require a given amount of memory.
The Generic UI Library contains a number of object classes that implement nearly all the UI functions an application will ever need. For a full description of the API of each of these classes, see the Objects Book. Some of the more common implementations (e.g. menus, dialog boxes, and scrolling views) of these objects are outlined in the sections below.
As application technology advances, applications gain more and more features. Despite recent improvements in user-friendliness, however, over-featured applications can sometimes intimidate and frustrate users.
GEOS therefore implements a Scalable User Interface , a system in which a single application's source code can be compiled into different versions of the application, each version at a different level of complexity. Scalability of applications is shown in Geoworks Pro--the appliances are all created from exactly the same source code as the advanced versions of those applications.
A window is an object that defines an area on the screen in which drawing and user interaction can occur. Windows may be resizable and movable, and automatically clip any drawing so it does not appear outside the window's edges.
The GEOS Window Manager maintains information about the size, shape, and visibility of all the windows in the system. In general, applications do not access the Window Manager directly; instead, generic UI objects and the kernel handle all window manipulation. Several different types of generic objects are "window" objects: GenPrimary is used as an application's primary window, GenInteraction is used for dialog boxes and menus, GenDisplay displays documents in a scrollable window, and GenView is used to create a scrollable graphics window into which an application can draw.
The Window Manager is closely tied to the GEOS Graphic System. These two parts of the system handle all window resizing, reshaping, drawing, and clipping automatically. They also interact with the User Interface's input mechanism to ensure that the proper windows receive the proper input. Applications do not need to know the shape, position, or size of a window when drawing inside it.
Applications can also allocate one or more windows in which they can present data (text, graphics, or other information). Each of these windows is called a View and is an instance of the GenView object (see below). The View manages all scrolling, scaling, sizing, and clipping automatically for the application; programmers don't have to worry about managing scrollbars or window size in order to ensure the proper portion of the data is drawn. Additionally, applications can modify any of the scrolling, scaling, or sizing behavior with a little effort to provide custom functionality.
GEOS has an input manager that tracks the mouse, gets keyboard input, and passes the input events on to the proper windows and objects on the screen. The input manager is part of the UI.
The UI keeps track of three different active objects in the system: the Focus, the Target, and the Model. The focus is the active object that should receive all keyboard input. The target is the currently selected object with which the user can interact. The model represents a non-visible "selection" that can be maintained by the application. These three active objects can be accessed directly by other objects (e.g. menu items); for example, a "change color" menu item may want to work on whatever object is currently active--it would want to change the color of the target object, and by contacting the target directly, it does not have to know what object is the target.
Any object in the system can grab mouse or keyboard events. When an object has been granted a mouse grab or keyboard grab, it will receive the events until it relinquishes the grab. This fact is most useful when dealing with visible object trees inside a View (see GenView, below)--generic objects handle input automatically (including the Text objects).
Applications may or may not need to handle input directly; complex applications likely will want to filter certain input or handle special cases. Simple applications or utilities will probably not have to deal with input (keyboard or mouse events) directly at all.
Among the generic objects of the GEOS UI library is GenInteraction. This object can be used to implement menus, dialog boxes, and error boxes, and it can also be used for grouping and arranging other generic objects (such as triggers, lists, etc.). It provides extreme flexibility and functionality, and experienced programmers can usually get a menu and dialog structure up on the screen quickly just by setting a few attributes.
Remember that because the Interaction is a generic object, the Generic UI and Specific UI libraries will translate it into its proper implementation at run-time. The Interaction serves the primary purpose of grouping objects; the grouping may be implemented in various ways (e.g. a menu or a dialog box) depending on the attributes and hints applied.
The sections below outline some of the practical functionality of these objects; for a full description of what these do and how they can be used, see the Object Reference Book.
Menus in GEOS are subject to the rules and conventions of the specific UI in use by the user. However, several basic concepts are supported.
Dialog boxes are standard ways of having an application interact with the user. For example, a dialog box may contain a number of controls that determine how the application displays its data.
Dialog boxes, like menus, are implemented through the use of GenInteraction objects. Applications may also call a kernel routine that will put up standard dialogs in certain situations (e.g. errors or warnings).
Several features of dialog boxes are implemented automatically with very little additional code in the application:
Although the basic generic objects provided by GEOS are powerful and useful in many situations, applications still need a way to display their own specific data. In most systems, this consists of allocating a window for the application's use and then implementing additional functionality for that window--scrolling, scaling, and document management.
The GenView generic object does all these things for an application. The application can allocate any number of views for its own use, and each view can display anything from regular graphics to hierarchies of visible objects.
Most applications will use at least one view. Its power and flexibility give programmers the opportunity to concentrate on their own application's functionality without having to worry about display issues such as scaling, clipping, and scrolling--they are all handled automatically. Some of the features of a view are listed below (see the GenView chapter for more detailed information):
Many applications will need to create objects that draw themselves and interact directly with the user. Rather than forcing the programmer to create each of his objects from scratch, GEOS offers several visible object classes that already understand several system services and constructs. When an application needs a visible object, it simply defines a subclass of one of these visible classes, thus ensuring that his object will handle all the UI messages that may be sent to it.
The GEOS User Interface includes a sophisticated Geometry Manager that does all the calculations for organization of objects on the screen. The Geometry Manager manages the positions of generic UI objects in dialog boxes and windows, for example, and it can be used to automatically position visible objects within a view.
The GenItem, GenItemGroup, GenBoolean, GenBooleanGroup, and GenDynamicList objects can be used to provide several different types and styles of lists. Lists may appear within menus or dialog boxes. The actual visual implementation of a list depends on the specific UI in use; however, there are several basic types of lists available (for complete information, see the Lists chapter):
Besides the objects listed above, the generic UI supplies a number of other gadgets. These include
Most applications will save data files. GEOS provides a convenient storage format for data files and an even more convenient mechanism for managing the files.
The Document Control objects interact with the GEOS file system and virtual memory system to implement the Open, Close, Save, Save-As, and Revert functions of the File menu as well as many other common document-related features. In fact, the Document Control also controls user interaction for these basic functions, creating and updating the File menu and putting up the proper dialog boxes for each operation.
The Document Control objects, like GenView and other components of GEOS, take basic functionality common to most applications and implement it in the system software. Using a Document Control for your data file management can save weeks of coding and debugging time.
Some applications may benefit from allowing the user to have multiple data files open at any given time. GeoWrite and GeoDraw, for example, allow the user to work with multiple documents at once. Each document appears within its own window; each of these windows is a GenDisplay object within a Display Control object.
The Display Control objects, like the Document Control objects, allow applications to use multiple data files with a minimum of extra coding. The Display Control works closely with the Document Control to ensure that the proper data files are being operated on at all times. The Display Control also creates and maintains the Window menu, just as the Document Control creates and maintains the File menu.
A common feature of GUIs is the Clipboard. Users can copy or cut data out of documents for pasting into other documents (or even the same document) later. When data is cut or copied, it is placed in a transfer item, a special data structure used by the Clipboard. All applications can access the Clipboard via Cut, Copy, and Paste; in addition, the Edit menu can be implemented automatically with the use of a GenEditControl object.
GEOS also offers another method of transferring data--the quick-transfer mechanism. In OSF/Motif, the user clicks the move/copy button (in most cases the right mouse button) over some selected data. He can then drag to another area and drop the selected data, either moving or copying it depending on certain contextual factors. Applications may or may not support the quick-transfer mechanism, though supporting it is not difficult and is strongly encouraged.
Both the Clipboard and the quick-transfer mechanism are supported automatically by all text edit and display objects. Applications may define their own custom data formats (transfer items) for use with both the Clipboard and the quick-transfer mechanism.
In a multithreaded system, one thread may change some information that another thread depends on. In this case, the thread that makes the change must notify all other users of the information that it has been changed and that they must update their status appropriately.
GEOS provides a mechanism for allowing all threads or objects to register for notification of certain events. For example, GeoManager is notified of all file system changes so it can update its display in real time. Although notification is automatically sent for certain system changes, applications can set up an automatic notification of custom changes. For example, if a multiuser network game depended on each user knowing a certain status flag, automatic notification could be set up to notify all the users whenever any user changed it.
On-line help is a convenient and powerful way to provide documentation to your users. Because graphical user interfaces are easy to understand, many users do not read documentation and prefer to discover an application's features on their own. On-line help can speed their learning process up.
GEOS provides an object that you can include in your User Interface that will automatically create a "Help" icon or menu item and display help text when that item is invoked. The help text displayed will be context-sensitive as defined by the application. The application simply has to provide the help text and a few other attributes of the help object, and the system will take care of displaying the help when the user requests it.
GEOS provides a number of services useful or necessary to applications. These services range from dynamic memory management to an item database to a sophisticated graphics system and a print spooler. Many of the most useful or integral services are described in this section.
Local Memory and Object Blocks
GEOS uses all RAM available to the system, even expanded and extended memory. Memory is managed by the kernel and is accessed in the segmented scheme implemented by the 8086 processor. (The protected mode of the more advanced processors is not supported in the Version 2.0 system software but is expected to be in future releases.)
The GEOS Memory Manager is sophisticated. It uses dynamic allocation and access of blocks on a global heap to provide high performance, optimized to run very efficiently even on systems with only 640 K.
GEOS maintains control of all the memory, objects, and other entities in the system through the Handle Table . The Handle Table is a section of memory set aside for kernel use, and it contains a number of entries, each 16 bytes that can contain various information about many different items in the system. These entries are accessed by handles , 16-bit offsets into the Handle Table. Applications and libraries may use handles but may not access the contents of a handle table entry. The data structure is opaque to all but the kernel.
Handles are used for many different things. They can reference threads, memory blocks, VM blocks, or files; they can represent data structures such as timers, queues, semaphores, or events (messages); and they can be used by the kernel for optimization (such as when several words of data are passed with a message).
Through the Preferences application, a user can set the number of handles in the Handle Table. However, the size of the table does not change during a single execution of GEOS. Applications and libraries may allocate handles dynamically for most of the above-mentioned purposes (e.g. memory and file reference).
A certain amount of memory is set aside for the file system (DOS, typically), the GEOS kernel (approximately 64 K), and any TSRs the user may have running on his system. Above this is the GEOS handle table. All RAM left (up to 1 megabyte) after these requirements are satisfied is used for the global heap (RAM over 1 megabyte is used as preferred swap space). The global heap is the space available to all the applications running in the system.
Applications allocate dynamic blocks of memory on the heap. Blocks may be of arbitrary size between 16 bytes and 64 K. Each block is designated a handle, an offset into the handle table where information about the block (such as size and location) is stored. Because blocks may be shuffled in the heap by the Memory Manager, applications must use handles as indirect references to the blocks; applications should not save pointers to specific locations in memory.
GEOS uses four basic types of blocks:
The GEOS kernel provides several routines to allocate memory. Some memory is allocated automatically, such as memory for code resources as they are loaded in. Other memory, however, must be allocated as it is needed during execution--for example, as the user types more and more text into a word processor. There are three basic ways to allocate memory on the heap:
MemAlloc()
This routine allocates a new block on the heap for an application's use.
MemReAlloc()
This routine reallocates a given block; this is useful for adding memory to a block already allocated.
malloc()
Although use of
malloc()
may help in porting previous C code to GEOS, it is discouraged. The
malloc()
routine will allocate small amounts of memory within a fixed resource. Extensive use of
malloc()
leads to large, fixed blocks on the heap, degrading system performance.
When an application is done with a memory block, it can free the block with the routine
MemFree()
. This will allow the Memory Manager to free up that memory space and re-use the block's handle if required.
If a block is allocated as fixed, an application can use a far pointer to access any byte within the block. However, because fixed blocks are not always allocated in the same portion of memory each time an application is loaded, applications should not save pointers as state information.
Non-fixed blocks, however, can not be accessed by far pointers without locking them into their position in memory.
MemLock()
will take a block's handle and lock the block, thereby assuring that the Memory Manager will not move it in the middle of an access.
MemLock()
provides its caller with a far pointer to the block. When access to the block is finished, the thread that locked the block must call
MemUnlock()
, which marks the block as unlocked so it may once again be moved or swapped.
GEOS implements a powerful virtual memory concept to accomplish both memory block swapping and data file storage. Virtual memory (VM) can be thought of as a disk-based heap--a VM file is segmented into blocks, each of which is designated a VM handle analogous to a global memory handle. When a VM block is required by an application, it is locked into memory from the file with a call to the kernel routine
VMLock()
, which loads the VM block into memory and locks it on the global heap.
VM is extremely useful for data file storage; indeed, the Document Control objects use it extensively.
Often applications will want to store large numbers of very small data items. In these cases, it's cumbersome and inefficient to allocate a global handle and a block on the global heap. For these situations, GEOS offers the concept of local memory (LMem).
Local memory can be thought of as a mini-heap within a memory block. Each individual unit allocated in this mini-heap is known as a chunk , and each chunk is designated a chunk handle . Thus, to access any piece of information within an LMem block, you need to have the block's global handle and the item's chunk handle.
Chunks may be allocated or freed, and any chunk may be moved within an LMem heap at any time (e.g. when the LMem heap is compacted). Locked LMem heaps may have chunks shuffled only when space is allocated within the heap. Access to chunks is gained by locking the LMem block and dereferencing the chunk handle. Chunks may be resized, and bytes may be added to or removed from chunks.
LMem blocks are used primarily for two purposes: Database files and object blocks. Database files are managed by the Item Database Library (see below). Object blocks are used extensively by the UI and applications; object blocks store objects in memory and often are attached to VM files.
Each object in an object block occupies one chunk. Thus, the combination of global handle and chunk handle of an object is known as the Object Pointer (optr) of the object. The optr is used to identify the object uniquely in the system for all types of access.
The GEOS database routines allows applications to use LMem heaps and VM files together easily and cleanly. The database routines allows applications to add a layer of abstraction to their data files.
An application may allocate database files, logical groups of items within those files, and individual items within the groups. The database library automatically manages the LMem and VM blocks that implement the database, keeping them desirable sizes and moving them into and out of memory as needed.
Additionally, items may be allocated as "ungrouped," in which case the database manager will intelligently distribute these items among the various VM blocks in the database file for efficient access.
The graphics system provided in the GEOS kernel is extremely powerful and is designed to make creating graphics simple and fast for applications. It includes some advanced concepts and state-of-the-art technology that make GEOS rise well above most other GUIs.
The GEOS graphics system uses a single imaging model like that used by PostScript. Applications and libraries draw their graphics on a generic rectangular grid with a resolution of 72 points per inch. When drawing to the screen or a printer, the graphics system will translate the graphics commands to the highest resolution of the output device, ensuring true WYSIWYG output. This system allows programmers to specify their graphics in real-world coordinates without worrying about the size of various resolution devices.
Normal graphics coordinates are represented by signed, 16-bit integers. Normal documents can be up to about nine feet on a side. Additionally, the graphics system allows applications to use an extended coordinate system (called the large document model ) of signed, 32-bit integers. Large documents can be up to 900 miles on a side! Large documents, however, can incur a certain amount of additional overhead; if you do not need to use large documents, you probably should not.
To simplify complex drawing, the graphics system maintains a graphics state , or GState . GStates can be created or destroyed dynamically to allow several different GStates for a given window (only one may be active at any given moment, however).
The GState is essentially a data structure that contains all the relevant information about the current state of a window. The GState's information includes current color, drawing position, angle of rotation, scale, translation in the coordinate space, line and fill attributes, clipping paths, text attributes, and other items.
Graphics commands are issued relative to a particular GState. For example, the command
GrDrawEllipse()
must be passed a GState so the kernel knows exactly how to draw the ellipse; if the current GState is rotated 45 degrees and has green as its current line color, a green-outlined ellipse will be drawn rotated 45 degrees.
Programs may apply transformations to GStates--rotation, translation, or scaling. You can also define custom transformation matrixes to apply to your GStates if complex operations (e.g. shearing) are required.
GEOS provides a complete set of graphics drawing primitives including lines, arcs, Bézier curves, splines, outline-defined text, rectangles, ellipses, polylines, polygons, and bitmaps.
A graphics path in GEOS is a continuous trail that defines the outline of an area. A path is an outline description of an arbitrarily shaped area, useful when an application must define a mathematically-precise shape. Paths may also be filled, combined with other paths, and scaled to any size without loss of resolution.
One example of the powerful application of paths is creation of arbitrary clipping regions. It is possible, for example, to clip drawings to an ellipse, to a bézier curve, or even to text.
Regions perform essentially the same function as paths--definition of an arbitrarily shaped area or clipping region. However, because regions are defined as resolution-dependent, they are typically used only for optimized drawing of UI gadgetry.
A
graphics string
(or
GString
) is a collection of graphics commands;
GStrings are useful for saving complex graphic operations and playing them back later. GStrings are created by calling a special routine and are then filled by executing graphics commands just as if you were drawing to the screen. GStrings may be pre-defined in source code as data resources to be played during execution.
GStrings are extremely useful for sharing graphic data between processes. For example, applications use GStrings to define their program icons, which may then be displayed by File Manager applications. The Clipboard supports the GString data format for cut, copy, and paste operations. GStrings are also flexible--they may contain comments and may be set up to be executed with parameters.
Bitmaps are pixel-by-pixel images defined at a specific resolution; they are automatically scaled to match the resolution of the display. Bitmaps are used in general to define complicated pictures, usually with many colors.
GEOS allows the creation of bitmaps with specified resolutions. Bitmaps can be created off-screen and may be edited with standard graphics system commands. Bitmaps are used mainly as monikers of generic objects and as icons for applications and data files.
GEOS allows applications to specify colors in two ways: with the system palette and with RGB values. The palette contains 256 entries, each of which is given a standard RGB value. If an application only uses 256 colors, it can modify the palette so it has the colors it needs. If an application uses more than 256 colors, it can specify any RGB value for any given graphics operation. The palette may also be expanded to support other color models. If the system palette is not sufficient, each application may create its own.
Text in GEOS is handled by the Text Object, a sophisticated and powerful object that is the base for both the GenText and the VisText classes. The Text Object handles more situations than most applications will ever face; only powerful word processors and text-formatting programs may require more functionality. Those that require additional features can subclass the text object and add those features.
The Text Object implements text editing, manipulation, and display for GEOS. It represents a major portion of the system software and as such should be used by all applications that plan on providing any text-editing features. Among its many features are
GEOS contains a print spooler that manages printing for all applications in the system. The spooler executes in its own threads and manages a print output queue for each printer connected to the system. The spooler also provides standard user interface components such as the print dialog box. Applications can customize the print dialog box by adding their own gadgetry for certain types of printing (such as the customizations in GeoDex and GeoPlanner).
For the application, printing is essentially the same task as drawing to the screen; all the same graphics commands are used. The only difference is that the output is sent to a spool file rather than to the screen.
If the paper size in a user's printer is different from the size of the document being printed, the spooler will do all the calculations and operations necessary to print the document properly. For example, a document eleven inches by seventeen inches will be rotated and printed on two standard-sized sheets of paper.
The GEOS kernel allows applications and libraries to set up different types of timers that can be used for various purposes. When a timer ticks, it calls a routine specified by the geode that initiated it. The different types of timers that can be set up include
Communications is becoming an increasingly important area of system services. GEOS provides programs with a number of means of communication, whether communicating with peripheral devices, other computers, or with another GEOS program.
GEOS has a number of routines that accomplish complex mathematical calculations. There are also routines that do matrix manipulation and complicated linear algebra operations. In addition, the system provides a library of routines to implement simple fixed-point math and complicated floating-point operations.
International markets are extremely important to Geoworks due to the large number of PCs in use in countries other than the United States. Therefore, localization of applications was made a priority when designing the system software.
GEOS provides a number of tools for localizing your code. The most important is the GEOS application ResEdit, which allows a programmer to edit data resources. When an application is programmed correctly, translation can easily be accomplished by a support team.
The GEOS kernel also contains a number of routines that allow applications to access different DOS character sets. These routines ensure that an English-language program will work on machines with different DOS character sets.
The use of dynamically-linkable libraries is key to the efficiency of GEOS applications. Several libraries are included in addition to the libraries provided by the kernel (such as the Graphic Object Library and the Database Library, discussed earlier):
GEOS does as much as possible to isolate applications from the hardware in use. Not only does this allow applications to run with thousands of different system configurations, but it also allows them to work properly with any new technology not yet developed--when a new device is introduced and a driver written for it, applications will automatically work with it (in most cases).
Device drivers are used by the kernel for all of the following:


ANTITRUST
Reviewed by Harvey Karten MGM Director: Peter Howitt Writer: Howard Franklin Cast: Ryan Phillippe, Tim Robbins, Rachael Leigh Cook, Claire Forlani, Tygh Runyan, Ned Bellamy, Douglas McFerran, Zahf Hajee
I have a pal, real nice fellow (call him Pete), who could easily pass for the all-American guy except that he's pro-Fidel Castro...thinks everything in Cuba would be just swell except that the American embargo keeps that island nation oppressed. During the election campaign just passed, I asked him how he could justify Castro's remaining in power without opposition for the past forty-one years, reaching fpr Queen Victoria's record and for the tenure of some pharaoh or other while in our democracy we have elections every two years, four years, six years. He replied that the U.S. has a government just as permanent as Fidel's and what's more this immutable power structure is far more reaching and undemocratic than anything you can find in Havana. Invoking former President Eisenhower who warned against the military-industrial complex, he insists that all 281 million of our residents are under the heel of the mega-corporations, who control most important aspects of our lives to say nothing of keeping the politicians dancing to their tune. Is it any wonder that Pete loved Peter Howitt's movie "AntiTrust"? For "AntiTrust" (one of those titles with a double meaning, as in "whom can you trust" and "hey that business of yours has squashed all competition") is a warning to all of us that the corporate structure in the United States is going to control our lives more than ever by dominating all aspects of communication. And what's more, a single company is going to do this without the help of any rivals.
If this scenario brings to mind the recent action of the Justice Department against the giant Microsoft corporation led by Bill Gates; and if Tim Robbins, who performs in the role of Gary Winston, head of the cutthroat company NURV, makes you think that we're already too late to head the communications giant off at the pass--then Howitt, giving scripter Howard Franklin's a taut, fast-paced and youthful evocation of an information-age message monopolizer, is on the money. Despite some occasionally stiff acting and just a smidgen of laughable dialogue, "AntiTrust" succeeds in making its portentous meaning more than reasonably entertaining. While the danger sometimes facing the world of computer geeks is not original--Irwin Winkler's 1995 movie "The Net" featuring Sandra Bullock as a mousy computer whiz whose identity is deleted by a group of weirdos more interested in a disc than in discotheques--"AntiTrust" is the first film that has ever represented sesame seeds as a murder weapon.
The movie centers on Milo (Ryan Philippe), a 23-year-old man so brilliant that NURV's CEO Gary Winston (Tim Robbins) counts on him to deliver a satellite-communications breakthrough ahead of the competition. He is given just forty-two days to accomplish the task, which signals to us that "AntiTrust" is going to have its characters racing against the clock--which they do not just once or twice during the film's 108 minutes. Best friend Teddy (Yee Jee Tso) is angry that Milo has even accepted a job with NURV and not because of envy: Teddy opposes the corporate giant's hegemony over so many aspects of communication because he is idealistic enough to believe that human knowledge belongs to all of us--it should be free--and Teddy remains in the proverbial garage pounding out programs in his attempt to break a code and deliver an information-age Shangri-La to the world. As Milo becomes suspicious of his boss' intentions and methods and begins to realize that billionaire Gary Winston may have bought off people in the Justice Department and even placed a spy in his own home, he puts his life in danger by working overtime to establish proof of his impressions.
Ryan Philippe looks "hot"--as the women in the critics' audience seem to feel, or so I gather from the looks on their faces. When not hititng the keyboard, the young thesp casts sexy glances at his girl friend Alice (Claire Forlani) and flirts with a strangely diffident coworker Lisa (Rachael Leigh Cook). Philippe turns in a convincing peerformance as a kid who looks as though he's just started shaving but whose cybergeek activities help him to save the world from a corporate behemoth. Tim Robbins is even better, given his need to show us that his agenda as head of a Microsoft-style business is in an ethical gray zone (if you can dismiss an occasional murder ordered at his behest). While he is certainly rich enough to retire to his yacht and take things easy, he gets his kicks from manipulating people and binary numbers; donating millions of dollars to art museums and thousands of computers to eager schoolchildren but also engaging in nefarious plots to be the first to perform a major communications breakthrough.
If the plot often seems to be as predictable as a computer going about its tasks without making a single surprising calculation, the movie itself adds up to an diverting vehicle. With pulsating music like "Son of Sam" and "Nietzsche" pumping up the action and some cool effects by Metrolight Studios spinning numbers across the screen, "AntiTrust" has enough suspense and cybertalk and sesame seeds to allow us to suspend disbelief, and could conceivably make Newt Gingrich and Malcolm Forbes question the ethics of capitalism for a couple of hours or so.
Rated PG-13. Running time: 108 minutes. (C) 2001 by Harvey Karten<EMAIL_ADDRESS>The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


{% extends "main/base.html" %} {% load staticfiles %} {% load dictionary_extras %} {% block head %} {% endblock %} {% block content %}
You have {{ request.session.reports|length }} reports remaining in this set.
{% endif %} {% include "main/message.html" %}{{ report.report_text }}
Your annotator request submit on {{ membership.created_at }} has status {{ membership.status }}.
{% else %} You don't have permission to annotate this collection. Please {% endif %}


Coordinating and planning road trips can be a pain. Cross-referencing different websites, writing down your itinerary, and tracking a budget on top of that? That's why we at mojamapa have come up with the perfect solution - let us handle the logistics!
We know you have places to be. And we want to be the ones to help you get there.
Look to us for the centralized source for planning the perfect road trip. Drop a pin to your intended destination, and find some neat spots along the way. Foodies, nature buffs, and obscure museum aficianados are all welcome to plan -- and what's more, plan around your own personal budget.


FCM toolbox
×
Settings
Firebase Cloud Messaging
(Required)
API Key
Ttl
Priority
High
Normal
Firebase Realtime Database
(Optional)
Url
Modification requires a page reload
×
Tutorial
How to send send payloads?
Select a
type
of payload to send
Fill the corresponding
input fields
Enter an device
token
or a
topic
Click the
Send
button or
Ctrl
+
⏎
How to add device tokens?
Fill the
token
input field
Click the
button
Or
Download
and
launch
the corresponding app on your device
Open the
dropdown
Click the
button next to the corresponding device
Ping
Text
Link
App
Raw
Test the reachability of a device
Title
Message
Clipboard
Title
URL
Open
Title
Package


Bulma
Actions
Filename
Size
Modify time
Owner
Permission
Type
filename
Size
Modify time
Owner
Permission
Type


23 Power and Proportions
23.1 Loading the Source Code for Love-boost.R
source("data/Love-boost.R")
Again, we’ll use this for the twobytwo
function I’ll demonstrate shortly.
23.2 Tuberculosis Prevalence Among IV Drug Users
Consider a study to investigate factors affecting tuberculosis prevalence among intravenous drug users. The original data source is Graham NMH et al. (1992) Prevalence of Tuberculin Positivity and Skin Test Anergy in HIV-1-Seropositive and Seronegative Intravenous Drug Users. JAMA, 267, 369-373.  To start, we’ll test the null hypothesis that the proportions of intravenous drug users who have a positive tuberculin skin test result are identical for those who share needles and those who do not.
twobytwo(24, 73, 28, 133,
"Sharing Needles", "Not Sharing",
"TB test+", "TB test-")
2 by 2 table analysis:
------------------------------------------------------
Outcome : TB test+
Comparing : Sharing Needles vs. Not Sharing
TB test+ TB test- P(TB test+) 95% conf.
Sharing Needles 24 73 0.2474 0.1717
Not Sharing 28 133 0.1739 0.1229
interval
Sharing Needles 0.3427
Not Sharing 0.2404
95% conf. interval
Relative Risk: 1.4227 0.8772 2.3073
Sample Odds Ratio: 1.5616 0.8439 2.8898
Conditional MLE Odds Ratio: 1.5588 0.8014 3.0191
Probability difference: 0.0735 -0.0265 0.1807
Exact P-value: 0.1996
Asymptotic P-value: 0.1557
------------------------------------------------------
What conclusions should we draw?
23.3 Designing a New TB Study
Now, suppose we wanted to design a new study with as many non-sharers as needle-sharers participating, and suppose that we wanted to detect any difference in the proportion of positive skin test results between the two groups that was identical to the data presented above or larger with at least 90% power, using a two-sided test and \(\alpha\) = .05. What sample size would be required to accomplish these aims?
23.4 Using power.prop.test
for Balanced Designs
Our constraints are that we want to find the sample size for a two-sample comparison of proportions using a balanced design, we will use \(\alpha\) = .05, and power = .90, and that we estimate that the non-sharers will have a .174 proportion of positive tests, and we will try to detect a difference between this group and the needle sharers, who we estimate will have a proportion of .247, using a two-sided hypothesis test.
power.prop.test(p1 = .174, p2 = .247, sig.level = 0.05, power = 0.90)
Two-sample comparison of proportions power calculation
n = 653.2876
p1 = 0.174
p2 = 0.247
sig.level = 0.05
power = 0.9
alternative = two.sided
NOTE: n is number in *each* group
So, we’d need at least 654 non-sharing subjects, and 654 more who share needles to accomplish the aims of the study.
23.5 How power.prop.test
works
power.prop.test
works much like the power.t.test
we saw for means.
Again, we specify 4 of the following 5 elements of the comparison, and R calculates the fifth.
- The sample size (interpreted as the # in each group, so half the total sample size)
- The true probability in group 1
- The true probability in group 2
- The significance level (\(\alpha\))
- The power (1 - \(\beta\))
The big weakness with the power.prop.test
tool is that it doesn’t allow you to work with unbalanced designs.
23.6 A Revised Scenario
Suppose we can get exactly 800 subjects in total (400 sharing and 400 non-sharing). How much power would we have to detect a difference in the proportion of positive skin test results between the two groups that was identical to the data presented above or larger, using a one-sided test, with \(\alpha\) = .10?
power.prop.test(n=400, p1=.174, p2=.247, sig.level = 0.10,
alternative="one.sided")
Two-sample comparison of proportions power calculation
n = 400
p1 = 0.174
p2 = 0.247
sig.level = 0.1
power = 0.8954262
alternative = one.sided
NOTE: n is number in *each* group
We would have just under 90% power to detect such an effect.
23.7 Using the pwr
library for Unbalanced Designs
The pwr.2p2n.test
function in the pwr
library can help assess the power of a test to determine a particular effect size using an unbalanced design, where \(n_1\) is not equal to \(n_2\).
As before, we specify four of the following five elements of the comparison, and R calculates the fifth.
-
n1
= The sample size in group 1 -
n2
= The sample size in group 2 -
sig.level
= The significance level (\(\alpha\)) -
power
= The power (1 - \(\beta\)) -
h
= the effect size h, which can be calculated separately in R based on the two proportions being compared:p1
andp2
.
23.7.1 Calculating the Effect Size h
To calculate the effect size for a given set of proportions, just use ES.h(p1, p2)
which is available in the pwr
library.
For instance, in our comparison, we have the following effect size.
pwr::ES.h(p1 = .174, p2 = .247)
[1] -0.1796783
23.8 Using pwr.2p2n.test
in R
Suppose we can have 700 samples in group 1 (the not sharing group) but only half that many in group 2 (the group of users who share needles). How much power would we have to detect this same difference (\(p_1\) = .174, \(p_2\) = .247) with a 5% significance level in a two-sided test?
pwr::pwr.2p2n.test(h = pwr::ES.h(p1 = .174, p2 = .247),
n1 = 700, n2 = 350,
sig.level = 0.05)
difference of proportion power calculation for binomial distribution (arcsine transformation)
h = 0.1796783
n1 = 700
n2 = 350
sig.level = 0.05
power = 0.7836768
alternative = two.sided
NOTE: different sample sizes
Note that the headline for this output actually reads:
difference of proportion power calculation for binomial distribution
(arcsine transformation)
It appears we will have about 78% power under these circumstances.
23.8.1 Comparison to Balanced Design
How does this compare to the results with a balanced design using only 1000 drug users in total, so that we have 500 patients in each group?
pwr::pwr.2p2n.test(h = pwr::ES.h(p1 = .174, p2 = .247),
n1 = 500, n2 = 500, sig.level = 0.05)
difference of proportion power calculation for binomial distribution (arcsine transformation)
h = 0.1796783
n1 = 500
n2 = 500
sig.level = 0.05
power = 0.8108416
alternative = two.sided
NOTE: different sample sizes
or we could instead have used…
power.prop.test(p1 = .174, p2 = .247,
sig.level = 0.05, n = 500)
Two-sample comparison of proportions power calculation
n = 500
p1 = 0.174
p2 = 0.247
sig.level = 0.05
power = 0.8091808
alternative = two.sided
NOTE: n is number in *each* group
Note that these two sample size estimation approaches are approximations, and use slightly different approaches, so it’s not surprising that the answers are similar, but not completely identical.


{% extends 'base.html' %} {% block content %}
No. of Units Booked: {{booking.units}}
Total Cost(Ksh): {{booking.cost}}
Check-in: {{booking.from_date}}
Check-out: {{booking.to_date}}
Edit Delete


hi.
my name is abdulwaheed,
and this is my portfolio.
about me
I am a programming student at Moringa School, still at the begginning of the course but
hopefully in the next couple of months I will have graduated from Moringa having acquired all the
skills needed to begin my career as a mobile app dvevloper.
I graduated high school on 2017 with a mean grade of B- and proceeded to join Riara University to study computer
science. but after a semester there I realised that I wasn't reaching my full potential and decided to leave and
start the Moringa prep program.
Tho I don't have that many skills I can assure you I am a hard worker and a team player and you will always get 120%
from me. People often describe me as a cinephile and I guess they are right. Nothing relaxes me more than sitting down and enjoying an entertaining story
coupled with great performances and visuals.
projects
As the name suggests, this is indeed the first website I have ever made and considering it was my first one, I think
it turned out pretty good.
It's just a basic website with a pink background, some text, some links and a photo of cookies because who
doesn't like cookies right?
I used both html and css to make this project.
I made this project a little while ago, trying out different css styles. It's basically a website with
a pink background and some text arranged in columns with a picture at the top.
I also used html and css to make this project.


| Dome Version | Dome version |
| Patrol Speed Level | A high value indicates a high speed. |
| Enable Adaptive Pan Speed | When this option is selected, the pan speed is adaptive. When you zoom in, the pan speed decreases. When you zoom out, the pan speed increases. |
| Go to Last Spot upon Power-on | When this option is selected, the camera goes to a spot when powered off and then on. To determine the spot, select an option from the When powered on drop-down list. Note: You need to configure presets before selecting the Go to a preset option. |
Restore Dome Default
|
Restore factory defaults for the dome. |
| Dome Upgrade | You need to upload *.bin files to upgrade the dome. Do not perform any operation during upgrades. |
| Pan Patrol | The pan patrol range is 0 ° - 180°. The Resumed In parameter specifies the time in which a patrol is resumed after being interrupted. The default value of this parameter is 1 minute. |
| Tilt Patrol | The tilt patrol range is 0 ° - 180°. The Resumed In parameter specifies the time in which a patrol is resumed after being interrupted. The default value of this parameter is 1 minute. |
| Load Preset | The camera goes to a preset when it does not receive any PTZ command for a period specified by theResumed In parameter. The default value for this parameter is 3 minutes. |
| Path Patrol | The camera patrols paths when it does not receive any PTZ command for a period specified by theResumed In parameter. The default value for this parameter is 1 minute. |
| Frame Patrol | The camera pans 90° upon receiving every other key frame. The Resumed In parameter specifies the time in which a patrol is resumed after being interrupted. The default value of this parameter is 1 minute. |
| Random Patrol | The camera randomly pans. The Resumed In parameter specifies the time in which a patrol is resumed after being interrupted. The default value of this parameter is 1 minute. |
| Panoramic Patrol | The camera pans from 0 ° to 360° and tilts from 0 ° to 180°. The Resumed In parameter specifies the time in which a patrol is resumed after being interrupted. The default value of this parameter is 1 minute. |
| Track Patrol | The camera patrols history tracks. The Resumed In parameter specifies the time in which a patrol is resumed after being interrupted. The default value of this parameter is 1 minute. |
To configure a preset:
1. Select a position using direction arrows.
2. Configure the focus and aperture.
3. Select an ID.
4. Name the preset.
5. Click Apply.
6. (Optional) Click Load to load the preset.
1. Move the camera to a position using the left direction arrows.
2. Click Left Border.
3. Move the camera to a position using the right direction arrows.
4. Click Right Border.
To clear all preset borders, click Clear Borders.
When Enable Manual Restrict Patrol Area is selected, the preset borders take effect when you move the camera to look around the area under surveillance.
When Enable Auto Restrict Patrol Area is selected, the presets borders take effect during a patrol.
1. Select a path from the Patrol Path drop-down list.
2. Click Add.
3. Specify parameters displayed in the Add dialog box.
4. Click Confirm.
1. Select a track from the Patrol Track drop-down list.
2. Click Start Recording.
3. Move the camera using PTZ control buttons.
4. Click Stop Recording. Note that each recording lasts for up to 10 minutes.
To preview a track, click Preview. To stop a preview, click Stop.
To remove all the recorded PTZ controls from a track, click Clear Records.
To schedule a task:
1. Select the Enable Scheduled Task check box.
2. Specify Resumed After. A scheduled task (for example, pan patrol) is occasionally interrupted by PTZ control operations. This parameter specifies the time after which the task is resumed.
3. Click Edit.
4. Select a day.
5. Select one or multiple durations.
6. Select a task from the Option drop-down list for each duration. For specific tasks, you need to specify ID.
7. (Optional) Copy the settings to other days.
8. Click Confirm.
1. Specify Horizontal Coordinate.
2. Click Horizontal Position.
3. Specify Vertical Coordinate.
4. Click Vertical Position.
Alternatively, specify Horizontal Coordinate and Vertical Coordinate, and then click Position.


Modal title
×
Modal body text goes here.
Home
Products
This Frontend is running on vSphere7
Best in Class Products to keep you fit
Showing
8
of
8
products
Show
12
24
All
products
Sort by
Price
Name


Whenever IntelliJ IDEA detects that your code can be modified or improved, a light bulb icon appears on the
current line in the editor:
for intention actions and for quick-fixes. Clear this checkbox if you don't
want to see these icons. You can still access the list of available actions and quick-fixes by pressing Alt+Enter.


Admin
Admin
Once you are done assigning User Rights Click on Save Button Above to Make those Rights Effective Immediately


Dear {UserLoginName},
OTP for your current Transaction is {OTP}
The information transmitted is for the use of the intended recipient only and may contain confidential and/or legally privileged material. If you have received this message in error, please notify Vana. Please do not respond to this e-mail. Responses sent to this e-mail address are not monitored.


--- layout: layout title: Service ---
I have contributed as reviewer for NLP, computer science and bioinformatics conferences and workshops:
I also co-organized the GO consortium 2018 meeting.


--- layout: page title: Contact nav_title: Contact nav_order: 4 hide: false show-title: true ---
Follow me on Twitter!


Academics
Autumn Semester 2017-18
- CS101 : Computer Programming and Utilization
- EE111 : Introduction to Electrical Systems
- MA105 : Calculus
- CH105 : Organic & Inorganic Chemistry
- CH107 : Physical Chemistry
- PH107 : Quantum Physics and application
- PH117 : Physics Lab
- ME113 : Workshop Practice
- NSO : Tabla
Spring Semester 2017-18
- EE112 : Introduction to Electronics
-
MA108 : Differential Equations
- MA106 : Linear Algebra
- PH108 : Basics of Electricity & Magnetism
- BB101 : Biology
-
CH117 : Chemistry Lab
- ME 119 : Engineering Graphics & Drawing
- NSO : Tabla
Autumn Semester 2018-19
- CS207 : Discrete Structures
- CS213 : Data Structures and Algorithms
- CS215 : Data Analysis and Interpretation
- CS251 : Software Systems Lab
- CS293 : Data Structures and Algorithms Lab
- HS101 : Economics
- SI417: Introduction to Probability Theory
My Timetable
|
8:30-9:00 |
9:00-9:30 |
9:30-10:00 |
10:00-10:30 |
10:30-11:00 |
11:00-11:30 |
11:30-12:00 |
12:00-12:30 |
12:30-1:00 |
1:00-1:30 |
1:30-2:00 |
2:00-2:30 |
2:30-3:00 |
3:00-3:30 |
3:30-4:00 |
4:00-4:30 |
4:30-5:00 |
5:00-5:30 |
5:30-6:00 |
6:00-6:30 |
6:30-7:00 |
| Monday |
CS207 |
HS101 |
|
CS213 |
| Tuesday |
|
CS207 |
HS101 |
|
CS251 |
| Wednesday |
|
SI417 |
CS215 |
|
SI417 |
| Thursday |
|
CS207 |
HS101 |
|
CS213 |
| Friday |
|
SI417 |
CS215 |
|
CS293 |


Project templates provider by Maven's genapp plugin. (See http://maven.apache.org/reference/plugins/genapp for details.)


All C++ programs are composed of the following two fundamental elements:
Program statements (code): This is the part of a program that performs actions and they are called functions.
Program data: The data is the information of the program which affected by the program functions.
Encapsulation is an Object Oriented Programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse. Data encapsulation led to the important OOP concept of data hiding.
Data encapsulation is a mechanism of bundling the data, and the functions that use them and data abstraction is a mechanism of exposing only the interfaces and hiding the implementation details from the user.
C++ supports the properties of encapsulation and data hiding through the creation of user-defined types, called classes. We already have studied that a class can contain private, protected and public members. By default, all items defined in a class are private. For example:
class Box { public: double getVolume(void) { return length * breadth * height; } private: double length; // Length of a box double breadth; // Breadth of a box double height; // Height of a box };
The variables length, breadth, and height are private. This means that they can be accessed only by other members of the Box class, and not by any other part of your program. This is one way encapsulation is achieved.
To make parts of a class public (i.e., accessible to other parts of your program), you must declare them after the public keyword. All variables or functions defined after the public specifier are accessible by all other functions in your program.
Making one class a friend of another exposes the implementation details and reduces encapsulation. The ideal is to keep as many of the details of each class hidden from all other classes as possible.
Any C++ program where you implement a class with public and private members is an example of data encapsulation and data abstraction. Consider the following example:
#include <iostream> using namespace std; class Adder{ public: // constructor Adder(int i = 0) { total = i; } // interface to outside world void addNum(int number) { total += number; } // interface to outside world int getTotal() { return total; }; private: // hidden data from outside world int total; }; int main( ) { Adder a; a.addNum(10); a.addNum(20); a.addNum(30); cout << "Total " << a.getTotal() <<endl; return 0; }
When the above code is compiled and executed, it produces the following result:
Total 60
Above class adds numbers together, and returns the sum. The public members addNum and getTotal are the interfaces to the outside world and a user needs to know them to use the class. The private member total is something that is hidden from the outside world, but is needed for the class to operate properly.
Most of us have learned through bitter experience to make class members private by default unless we really need to expose them. That's just good encapsulation.
This wisdom is applied most frequently to data members, but it applies equally to all members, including virtual functions.


The Maharashtra coup: What happened in 24 hours
The surprise announcement of Fadnavis as the CM of Maharashtra, and Ajit Pawar as the deputy CM has ended a month long dilemma in Maharashtra, here's how it came about.
by ET OnlineThe month-long political impasse in Maharashtra ended dramatically with Devendra Fadnavis returning as the state's chief minister again, backed by NCP leader Ajit Pawar, who was sworn-in as the deputy chief minister at Raj Bhavan early Saturday.
Nationalist Congress Party (NCP) chief Sharad Pawar, however, clarified that the decision of going with BJP to form the government in Maharashtra was of his nephew (Ajit Pawar).
"Ajit Pawar's decision to support the BJP to form the Maharashtra Government is his personal decision and not that of the Nationalist Congress Party (NCP). We place on record that we do not support or endorse this decision of his," Sharad Pawar tweeted.
The political stunner came at a time when deliberations between Congress, NCP and Shiv Sena seemingly reached the final stage on Friday. Earlier, NCP supremo Sharad Pawar had claimed that there was a consensus on Sena chief Uddhav Thackeray as chief minister of the alliance government.
Here's what happened:
Friday:
Sometime around 11.45 p.m.: Ajit Pawar-BJP Deal finalised.
11.55 pm.: Fadnavis speaks to party and requests for swearing-in before anyone in Sena-NCP-Congress comes to know and stakes claim.
Saturday:
12.30 a.m.: Governor who was to travel out of Mumbai to New Delhi, cancels his travel
02.10 a.m: Secretary to Governor told to submit revocation order at 5.47 and arrange swearing in at 6.30 a.m.
02.30 a.m.: Secretary informs he will submit file within two hours and advises 7.30 a.m. for swearing in as arrangements have to be made early on Saturday.
05.30 a.m.: Both Ajit Pawar and Fadnavis arrive at Raj Bhavan.
05.47 a.m.: President's Rule revoked.
07.50 a.m.: Swearing in starts by Governor B.S. Koshiyari.
08.40 a.m.: PM Modi congratulates new CM and Deputy CM.


OpenGL integration
These functions are declared in the following header file:
#include <allegro5/allegro_opengl.h>
al_get_opengl_extension_list
ALLEGRO_OGL_EXT_LIST *al_get_opengl_extension_list(void)
Returns the list of OpenGL extensions supported by Allegro, for the given display.
Allegro will keep information about all extensions it knows about in a structure returned by al_get_opengl_extension_list
.
For example:
if (al_get_opengl_extension_list()->ALLEGRO_GL_ARB_multitexture) {
use it
}
The extension will be set to true if available for the given display and false otherwise. This means to use the definitions and functions from an OpenGL extension, all you need to do is to check for it as above at run time, after acquiring the OpenGL display from Allegro.
Under Windows, this will also work with WGL extensions, and under Unix with GLX extensions.
In case you want to manually check for extensions and load function pointers yourself (say, in case the Allegro developers did not include it yet), you can use the al_have_opengl_extension and al_get_opengl_proc_address functions instead.
al_get_opengl_proc_address
void *al_get_opengl_proc_address(const char *name)
Helper to get the address of an OpenGL symbol
Example:
How to get the function glMultiTexCoord3fARB that comes with ARB's Multitexture extension:
// define the type of the function
ALLEGRO_DEFINE_PROC_TYPE(void, MULTI_TEX_FUNC,
(GLenum, GLfloat, GLfloat, GLfloat));
// declare the function pointer
MULTI_TEX_FUNC glMultiTexCoord3fARB;
// get the address of the function
glMultiTexCoord3fARB = (MULTI_TEX_FUNC) al_get_opengl_proc_address(
"glMultiTexCoord3fARB");
If glMultiTexCoord3fARB is not NULL then it can be used as if it has been defined in the OpenGL core library.
Note: Under Windows, OpenGL functions may need a special calling convention, so it's best to always use the ALLEGRO_DEFINE_PROC_TYPE macro when declaring function pointer types for OpenGL functions.
Parameters:
name - The name of the symbol you want to link to.
Return value:
A pointer to the symbol if available or NULL otherwise.
al_get_opengl_texture
GLuint al_get_opengl_texture(ALLEGRO_BITMAP *bitmap)
Returns the OpenGL texture id internally used by the given bitmap if it uses one, else 0.
Example:
bitmap = al_load_bitmap("my_texture.png");
texture = al_get_opengl_texture(bitmap);
if (texture != 0)
glBindTexture(GL_TEXTURE_2D, texture);
al_get_opengl_texture_size
void al_get_opengl_texture_size(ALLEGRO_BITMAP *bitmap, int *w, int *h)
Retrieves the size of the texture used for the bitmap. This can be different from the bitmap size if OpenGL only supports power-of-two sizes or if it is a sub-bitmap. 0's are returned if the bitmap is not an OpenGL bitmap.
al_get_opengl_texture_position
void al_get_opengl_texture_position(ALLEGRO_BITMAP *bitmap, int *u, int *v)
Returns the u/v coordinates for the top/left corner of the bitmap within the used texture, in pixels.
al_get_opengl_fbo
GLuint al_get_opengl_fbo(ALLEGRO_BITMAP *bitmap)
Returns the OpenGL FBO id internally used by the given bitmap if it uses one, otherwise returns zero. No attempt will be made to create an FBO if the bitmap is not owned by the current display.
The FBO returned by this function will only be freed when the bitmap is destroyed, or if you call al_remove_opengl_fbo on the bitmap.
Note: In Allegro 5.0.0 this function only returned an FBO which had previously been created by calling al_set_target_bitmap. It would not attempt to create an FBO itself. This has since been changed.
See also: al_remove_opengl_fbo, al_set_target_bitmap
al_remove_opengl_fbo
void al_remove_opengl_fbo(ALLEGRO_BITMAP *bitmap)
Explicitly free an OpenGL FBO created for a bitmap, if it has one. Usually you do not need to worry about freeing FBOs, unless you use al_get_opengl_fbo.
See also: al_get_opengl_fbo, al_set_target_bitmap
al_have_opengl_extension
bool al_have_opengl_extension(const char *extension)
This function is a helper to determine whether an OpenGL extension is available on the given display or not.
Example:
bool packedpixels = al_have_opengl_extension("GL_EXT_packed_pixels");
If packedpixels is true then you can safely use the constants related to the packed pixels extension.
Returns true if the extension is available; false otherwise.
al_get_opengl_version
uint32_t al_get_opengl_version(void)
Returns the OpenGL or OpenGL ES version number of the client (the computer the program is running on), for the current display. "1.0" is returned as 0x01000000, "1.2.1" is returned as 0x01020100, and "1.2.2" as 0x01020200, etc.
A valid OpenGL context must exist for this function to work, which means you may not call it before al_create_display.
See also: al_get_opengl_variant
al_get_opengl_variant
int al_get_opengl_variant(void)
Returns the variant or type of OpenGL used on the running platform. This function can be called before creating a display or setting properties for new displays. Possible values are:
- ALLEGRO_DESKTOP_OPENGL
Regular OpenGL as seen on desktop/laptop computers.
- ALLEGRO_OPENGL_ES
Trimmed down version of OpenGL used on many small consumer electronic devices such as handheld (and sometimes full size) consoles.
See also: al_get_opengl_version
al_set_current_opengl_context
void al_set_current_opengl_context(ALLEGRO_DISPLAY *display)
Make the OpenGL context associated with the given display current for the calling thread. If there is a current target bitmap which belongs to a different OpenGL context, the target bitmap will be changed to NULL.
Normally you do not need to use this function, as the context will be made current when you call al_set_target_bitmap or al_set_target_backbuffer. You might need if it you created an OpenGL "forward compatible" context. Then al_get_backbuffer only returns NULL, so it would not work to pass that to al_set_target_bitmap.
OpenGL configuration
You can disable the detection of any OpenGL extension by Allegro with a section like this in allegro5.cfg:
[opengl_disabled_extensions]
GL_ARB_texture_non_power_of_two=0
GL_EXT_framebuffer_object=0
Any extension which appears in the section is treated as not available (it does not matter if you set it to 0 or any other value).