Windowing Systems and Architectures

Detailed specifications outline interactive application requirements, which programmers translate to hardware-operating machine code.
Programming tools offer higher-level abstractions, enabling programmers to code in terms of interaction objects rather than hardware details.
These abstractions integrate input and output intuitively, even if hardware separates them.

Bass and Coutaz identify three potential architectures for windowing system roles, separating device drivers from applications:
- Application-Level Management: Each application manages its processes independently, but synchronisation with shared hardware is complex and reduces portability.
- Kernel-Level Management: The operating system kernel centralizes process management, reducing burden, but tailoring applications to operating system specifics is required.
- Separate Management Application (Client-Server): A dedicated app manages, using a consistent generic interface, which enhances portability across systems.

Interactive application behavior is driven by user input.
- Two paradigms manage application flow control independent of windowing systems:
  - Read-Evaluation Loop: Used internally. Server sends structured user inputs to the client app, which processes events and responses based on its needs. Server directs the event to the correct client. This approach gives the app full control over event processing but can be cumbersome. Tools like MacApp can automate tedious tasks.
  - Notification-Based Programming: Uses a centralized notifier to manage event processing. The notifier filters events based on app interests and invokes corresponding callback procedures. Centralizes control for the app but can make tasks like implementing a pre-emptive dialog box more complex.

In WIMP interfaces, input and output are linked to visual elements, creating an illusion of interactive objects (buttons, etc).
Toolkits provide a higher level of abstraction, with predefined interaction objects (widgets) and built-in behaviors, simplifying development.
Toolkits allow customisation but still require significant programming for desired effects.

Toolkits have limitations, necessitating advanced systems, like UIMS.
UIMS focus on enhancing service quality (beyond toolkits) by separating presentation from application logic:
- Conceptual Architecture: Segregates application logic from presentation.
- Implementation Techniques: Ensures a clear link between application and presentation, managing them independently.
- Support Techniques: Aids in managing, implementing, and evaluating interactive environments at runtime.. Some consider the term "User Interface Development Systems" more encompassing.

Separating application semantics from user interface is a key issue in interactive systems. This benefits:
- Portability: The same application runs on different systems.
- Reusability: Components can be reused with less cost
- Multiple Interfaces: Creation of various, flexible interfaces for the same application.
- Customisation: Allows designers and users to customise the interface to enhance effectiveness without modifying core application code.
Dialog control (communication between application and presentation) is crucial. This can be challenging to implement.

Two main dialog control approaches:
- Read-Evaluation Loop: Application manages dialog internally using interface procedures for input and output.
- Notification-Based Programming: External control over dialog. User actions invoke application procedures.
Most UIMS use notification-based approaches to better separate presentation from logic, though not all use toolkits.

Seeheim model is a conceptual architecture to support separation of presentation, dialog control, and application semantics. Components are presentation, dialog control, and application interface
Model separated presentation from application and dialog components to improve efficiency and bypass explicit dialog control. However, it may not be well suited to guiding future UIMS design. This model has been criticised (due to certain flaws in structuring UIMS).

Improves design of large interactive systems
Model (represents app semantics), View (graphical outputs), and Controller (handles user input).
Components implemented as general classes, supporting inheritance and customisation, allowing reuse and adaptation of existing elements.

Offers another multi-agent architecture.
Key components are Abstraction (app semantics), Presentation (input and output), and Control (overseeing consistency between abstraction/presentation).
PAC differs from MVC by combining input/output in presentation, and assigning consistency management to the control component, making it more of a conceptual framework (versus programming environment dependent) with more flexibility.

Conceptual architecture is distinct from implementation details.
Implementation requires defining components' realization.
Several techniques for modeling and structuring dialogues within UIMS:
- Menu Networks, Grammar Notations, State Transition Diagrams, Event Languages, Declarative Languages, Constraints, and Graphical Specifications.

Windowing systems abstract away hardware details (screens, keyboards, mouse) to enable applications' portability across different hardware.
Use a generic language for communication between applications/devices, making programming simpler.
Imaging models use primitives to describe images efficiently, including text images (general font definitions).
Essential roles include coordinating processes, allocating and managing overlapping screen regions for active terminals.