This section describes the format of the .server files used by applications to tell the Bonobo Activation daemon about the interfaces they support. Here follows a simple example of a minimalist .server file. <oaf_info> <oaf_server iid="OAFIID:Bonobo_CosNaming_NamingContext" type="exe" location="/usr/lib/bonobo-activation/bonobo-activation-server"> </oaf_server> </oaf_info> Each oaf_server entry conventionally has three mandatory properties: iid (the FAQ of the Bonobo API reference manual explains how to create an iid), type (can be exe, factory, or shlib) and location. If the type is exe, location is the name of the executable which creates the CORBA interfaces associated to this entry and registers them to Bonobo Activation. If the type is factory, location is the iid of the component which can create the corresponding CORBA server. If the type is shlib, location is the name of the library the code is in: libgmf for example. Don't include the .so suffix common on Linux systems in the location of a shlib component. Here follows a simple example of a component activated through a factory: <oaf_info> <oaf_server iid="OAFIID:Bonobo_Sample_Echo_Factory" type="exe" location="/usr/lib/bonobo-2.0/samples/bonobo-echo-2"> </oaf_server> <oaf_server iid="OAFIID:Bonobo_Sample_Echo" type="factory" location="OAFIID:Bonobo_Sample_Echo_Factory"> </oaf_server> </oaf_info> If you ask Bonobo Activation to activate the OAFIID:Bonobo_Sample_Echo component, Bonobo Activation will first check if it is a factory, make sure the corresponding factory compoenent is running (by activating it. Here, activating the factory component is a matter of launching the executable) and call create on the factory. It will return you that object. Defining servers is useful (that is what .goad files did light-years ago) but to use all the power of Bonobo Activation (i.e. queries ;-), you have to define oaf_attributes for each of those oaf_server entries. An example is worth all words. <oaf_info> <oaf_server iid="OAFIID:Bonobo_Sample_Echo_Factory" type="exe" location="/usr/lib/bonobo-2.0/samples/bonobo-echo-2"> <oaf_attribute name="repo_ids" type="stringv"> <item value="IDL:Bonobo/GenericFactory:1.0"/> </oaf_attribute> <oaf_attribute name="name" type="string" value="Echo component factory"/> <oaf_attribute name="description" type="string" value="Bonobo Echo server factory"/> </oaf_server> <oaf_server iid="OAFIID:Bonobo_Sample_Echo" type="factory" location="OAFIID:Bonobo_Sample_Echo_Factory"> <oaf_attribute name="repo_ids" type="stringv"> <item value="IDL:Demo/Echo:1.0"/> </oaf_attribute> <oaf_attribute name="name" type="string" value="Echo component"/> <oaf_attribute name="description" type="string" value="Bonobo Echo server sample program"/> </oaf_server> </oaf_info> Each oaf_server entry defines a set of attributes. Each attribute has a given name, type, and value. The types of the attributes are those defined in the Bonobo Activation query langage reference (). Type name should be non-caps. Values of type stringv are represented as follows: <oaf_attribute name="repo_ids" type="stringv"> <item value="IDL:Bonobo/Unknown:1.0"/> <item value="IDL:Bonobo/Control:1.0"/> </oaf_attribute> All other types' values are simply in the value field. A certain number of attributes have been normalized for GNOME. If a component uses any attribute from the list, it ought to have the meaning described here. Their list follows. Attribute name Type Signification repo_ids stringv the list of all IDL interfaces this component implements, including inherited interfaces. If Bonobo::Unknown is one of the interfaces, the list should include all interfaces for which a queryInterface operation on the component will succeed. description string a human readable string describing what the component can do name string a short name for the component, suitable for display to the end user, e.g. in a menu. bonobo:editable boolean if the component allows editing of its content no bonobo:supported_uri_schemes stringv a list of protocols this component knows how to handle. This only really makes sense if the component implements one of the following interfaces: Bonobo::PersistFile or Nautilus::View bonobo:supported_mime_types stringv a list of MIME types this component understands as input. In addition to specific MIME types, it is possible to include supertypes (e.g. image/* or text/*) or */* to indicate the component can display any MIME type. Specifying */* is only necessary if neither supported_uri_schemes nor additional_uri_schemes is not specified, otherwise */* is assumed. This only really makes sense if the component implements one of the following interfaces: Bonobo::PersistStream, Bonobo::PersistFile, or Nautilus::View. bonobo:additional_uri_schemes stringv a list of protocols this component knows how to handle. The component is applicable to any URI which uses such a protocol, even if its MIME type is not among supported_mime_types. This only really makes sense if the component implements one of the following interfaces: Bonobo::PersistFile or Nautilus::View bonobo:moniker stringv FIXME bonobo:moniker_extender stringv FIXME bonobo:environment stringv List of environment variables that must have the same values in both activator (client) and component. This is useful for exe type factories. If there is already a running process serving the component being activated, its environment variables are compared to the ones in the activator. If they match, a new reference from that process is returned. If not, a new process is started, which receives an evironment modified to match the one in the activator for the environment keys specified in this property. nautilus:view_as_name string a suitable name for use as a View as name. Several labels in Nautilus will be built from this value, see the following attributes. This must be present for any Bonobo Controls that can be used as Nautilus views. nautilus:view_as_label string a label (without keyboard mnemonic) for the component's menu item in Nautilus' View as list (next to the zoom control) as well as for its entry in the Open with Other Viewer window. It defaults to View as name where name is the value of the view_as_name attribute. It is discouraged to rely on this fallback because it makes correct translation impossible for some languages. nautilus:view_as_label_with_mnemonic string a label (with keyboard mnemonic) for the component's menu item in Nautilus' View menu. Thus the mnemonic must not clash with one from a built-in menu item. If omitted, the value of view_as_label will be used instead. nautilus:viewer_label string a label for the component's menu item in the Open With submenu of Nautilus' context menu for files and the File menu. It defaults to name Viewer where name is the value of the view_as_name attribute. It is discouraged to rely on this fallback because it makes correct translation impossible for some languages. nautilus:required_directory_content_mime_types stringv if the component is to be activated on a URI with MIME type special/directory, it is only really applicable if the directory contains a file with one of the MIME types listed in this attribute. As before, supertypes like audio/* are allowed. If this attribute is omitted, */* is assumed. nautilus:sidebar_panel_name string a suitable name for use as a sidebar panel label name. This must be implemented by any Bonobo Controls that can be used as a Nautilus sidebar view. nautilus:context_menu_handler nautilus:can_handle_multiple_files nautilus:property_page_name nautilusverb:verbname If bonobo:supported_uri_schemes or bonobo:additional_uri_schemes is specified but bonobo:supported_mime_types is not, it is assumed the component can handle any type of data that might come via that protocol. Some schemes may not even have an associated MIME type for any given URI, for instance irc: or news: If bonobo:supported_mime_types is specified but bonobo:supported_uri_schemes is not, the component is assumed to be able to handle all common URI schemes (possible definition: anything gnome-vfs can handle). If neither bonobo:supported_uri_schemes nor bonobo:additional_uri_schemes nor bonobo:supported_mime_types is specified, it is assumed the component cannot handle any data at all in a general way and should never be generically selected for such purposes. Nautilus considers a component as a view if it can handle the data from a URI and implements the Nautilus::View interface or Bonobo::Control and Bonobo::PersistStream or Bonobo::PersistFile.