| [View Updates][View Threads][View Files][SVN Log][SVN Submitters]| Title: | BOOPSI Menu Class |  | Synopsis:
A BOOPSI wrapper class to program Intuition/Gadtools menus the object-oriented way.
| | Status: | Closed | | Priority: | High As prioritized by the OS4 development team | | Category: | system/reaction | | Description: | THE SITUATION
Currently, the menu system is the oldest component of AmigaOS' user interface - it hasn't changed since 2.0 times. As far as functionality is concerned, it is a well-proven concept that needs few improvements. However, from the programmer's standpoint, it is a nightmare because:
- data structures are used and manipulated directly, which makes the menu system prone to unnecessary trouble;
- programming dynamic menu content is clumsy and tedious;
- it leaves the AmigaOS GUI programming framework in a mess: whereas windows, requesters, gadgets and images have been programmed as BOOPSI objects for quite some time, with menus the programmer has to stick to a completely different (and inferior) API.
PROJECT GOALS
The project will produce a BOOPSI class to wrap robust object-oriented code around the existing Intuition/Gadtools menu system. Internals will be hidden inside the class. All public menu attributes will be set, updated and accessed via tags and methods.
As Amiga menus are always tied to a window, the Window Class and the Menu Class will communicate internally to avoid possible problems. For example, if the window changes screen after using Window Class' jump-to-screen feature, the Menu Class will be informed accordingly to relayout the menu for the new visual context (thus sparing the programmer from doing this).
IMPLEMENTATION
(still evolving and subject to change)
Each type of menu element - the menu strip, the menu, the menu item - will be represented by an object (an instance of Menu Class). Creating a menu for your application will, therefore, entail instantiating several hierarchically-arranged objects.
As the resulting menu strip will in fact be a standard Intuition menu, input events from it will of course be sent to the window (class). So for the programmer, there will be no change in menu input handling. (There's really no point in Menu Class implementing its own input handling method.) Programmers will keep using WM_HANDLEINPUT as they did before. | | Created by: | trixie | | Created at: | 20091109 17:53 | | Deadline: | Not set | | Finished at: | Not finished | | Last update: | 20190705 14:39 | | Assigned to: | trixie | | Suggested by: | Trixie |
| Task list for this project |
| ID | Title | Assigned | Progress | Updated | Created by |
|
|
|
