List of Services

Provides a clipboard service that also interacts with the system cliboard when possible. Multiple clipboard entries would be a nice feature to have too.

Stores parameters defined by the user (as screen resolution or controls configuration) and provides them to the other services and components.


Provides a GUI widget system. It uses the InputService for listening to the mouse and keyboard. For output, it needs to be able to draw rectangles with bitmap backgrounds, and draw text. Changing the mouse cursor, and animating a blinking text entry cursor and other gui elements (bitmaps) would also be nice. Can create various basic GUI Widgets, and connect them to listeners / data sources (of Data Model type?). The GUI widgets are themable, and have a method for setting the theme to use.

Internationalisation could also be supported, with a way to get internationalized strings from a key=value -type property file, based on an ID or default text of a label or other widget with text. I18n needs to be considered for components and other places where user output is produced too, and we need a way to provide variables to customize the internationalised text (similar to how printf allows you to insert numbers or string variables in a string). Perhaps we could have a service that manages I18n?

Also holds the root window (?).

Here's a list of different widgets that could be provided. Some are basic ones and needed soon, others are more advanced, and can be implemented later as they are needed. The difference between the terms Panel and Pane used here is that a Panel can contain many children, while a Pane contains only one child (and usually implements some special functionality).

A basic container that can contain other widgets. The other widgets are arranged by a layout manager, similar to the way Java Swing works. Initially BorderLayout and FlowLayout can be provided.

A text label, optionally with an icon above, to the left, to the right, or below. The icon is specified as a media reference, and could be perhaps be animated too. The font and font color is also possible to specify, although a default font and font color is provided by the theme.




This panel pops up above the normal UI. Used for tooltips, menus, floating components, and custom components of similar nature.

Contains a number of tabs at the top, bottom, or a side, that switch between several different widgets that can be shown.

Panel that can be dragged and dropped to any edge of another docking panel, or to an edge between two docking panels. Optionally; if dropped near the middle of another docking panel, a tab control is created, that has the old and the new docking panels as tabs (and the tabs can be dragged away and dropped somewhere else as normal docking panels).

Contains arow of buttons that will open pop up menus.

Shows a list of menu items. Used for both popup menus (context menus) and for menu bar menus.

A menu item with a caption, and optionally an icon.

Similar to a panel, but with scrollbars. Used for all scrolling of widgets.. -> needs a way to query the contained widget about it's size, and how big steps to scroll in, ec.

Shows a list of data objects or components (are components data objects too?). The list can be either vertical with equal sized cells, or grid like, with each object represented as an icon. The objects can be objects from a specific Data Model folder, or provided in a normal vector or similar. The list might also have many columns, showing different properties of the object..?

Used to show and edit objects (or components?) at certain positions and connections between them. Advanced control, to be implemented later for various in-game editors and for a visual script / layout editor.

A Command class would make life much easier when dealing with menu items, buttons, and similar. A Command has a name, description, information of wether it is enabled / available or not, and an execute method that optionally returns a command history entry used for implementing undo and redo (undo&redo would only be of use in in-game editors, but there it would be very nice to support). How could Commands be tied in with the Data Model, and custom Component functionality? Commands might also be provided by services, such as connect to a game, etc. A problem is that a command doesn't take any parameters, it should be able to decide what objects are being manipulated from things like currently selected objects. It can also be specific to only one dialog or component (pick a server to connect to -dialog, etc)..

Manages the input interface (with keyboard, mouse and/or others).

Manages logs of different dime processes.

Keeps a list of the known metaservers. Has API methods for retrieving a list of servers and their properties from all / one metaserver (and also to query individual servers, if the metaserver supports this?). Also provides API functions for adding and removing metaservers. The initial meta servers are also one thing that needs to be possible to red from a human editable configuration file?

Possibly publishes the list of metaservers in the datamodel too.

Keeps a list of servers and various properties about them, such as name, average ping, description, icon/logo, last known number of players, references to any accounts that the user has on them, the users notes and rating of them, public user rating or comments, and so on. Depending on if the server address has just been entered the address manually, retrieved it from a metaserver, queried the server, searched for information about it on possible server rating/comment sites, or logged in and played on the server, a different amount of this information is available/known.

The ServerService publishes the list of the servers and their properties in the data model (in /servers/ ?), and also provides API functions for querying a server for more information (?), and for adding notes and other extra information about servers (in an extra or similar folder under the server in the data model?).

This service is used for saving the internal data of different servers between sessions. The service povides an API that accepts a keyname for the data (typically the service name), and the data as a tree of atlas objects, or similar. It then saves them to disk, in a subfolder of the dime user specific data folder, as separate xml files, named after the keys. It might also have support for totally different sessions, by having a subfolder for each session (this way a default session with initial data can be saved to enable quick startup of an Acorn, Mason or other game, and allows restoration of defaults if the user or a script messes up the settings. The API supports loading in a similar way, the caller gives a key, and the persistence service returns an atlas object tree, or null/error data if no file was found. The PersistenceService could also have functions in the API for specifying what session to use (what subfolder to get the config scripts from).

This service only publishes the current session name (as read only) in the data model (in the /client or /user folder?).

Minimal service used for tests.