USING THE DESIGN OF ABSTRACTUI::ML FOR IDL INTERFACES

Start Here | News | For Artists | For Developers | Products & Projects | Research & Articles | Entertainment | Company Profile | Contact

This is just a description of how the core APIs of AbstractUI::ML might be implemented in OMG IDL. This document has been written for the Berlin project. If you do not know what the Berlin project is and if you do not have any interest in CORBA interfaces, you are problably in the wrong place. The design of AbstractUI::ML is described in the AbstractUI::ML documentation so you will problably need to read that documentation too - and there's not that much to read. Also, trying out The Construct for yourself should make things a lot easier to understand.

The IDL interfaces

For creating user interface controls, an IDL interface with a single factory method should be enough. It is given the name of the control that is to be created. It should problably be implemented as a look and feel server which looks for the appropriate control to create. A proposed IDL interface is given in LFServer.idl.

The 'createControl' method should return a complete implementation of a user interface control with the returned node as the main node for the control and with appropriate parameter nodes connected to it as in AbstractUI::ML. The proposed IDL interface (pseudocode) for such a graph node is given in DGNode.idl.

Each node has a protocol - which in IDL is implemented by inheriting each protocol from the DGNode interface. Here are a few example protocols in IDL pseudocode: PString.idl, PInt.idl and PStrings.idl. Typecasting a node to it's appropriate protocol type is supported natively in CORBA.

The actual user interface object for the node returned by the 'createControl' method above should possibly not be constructed before the node has been connected appropriately to a parent and the boolean protocol of the parameternode called "Create" is set to the value true. Again, this is how it is currently done in AbstractUI::ML.

It should be noted that I already have plans for reducing the protocols in AbstractUI::ML to just a record of functions and make the implementation of user interface controls rely only on notifications. This will allow for runtime hotswapping of look and feels and also make the protocolnodes much more lightweight - but I'm not sure how to make such a lightweight "record of functions" in IDL. A restriction like saying that you can't override the methods of the interface and not change it's implementation would be fine for this. Relying only on notifications when implementing an IDL interface would also allow for hotswapping user interface controls without the application ever knowing - unless it wants to know of course... And I believe that this is what is most desirable.

Modified: 2023-05-19
E-mail: Contact