This article provides a short description of the main Lucy concepts. For each concept, extended documentation is available in other articles.

The services mechanism

The Lucy back-end (ILcyLucyEnv) provides a mechanism for sharing objects between different parts of Lucy without creating a hard dependency between those parts. This mechanism is called the service mechanism.

You can see it as a giant bag: you can put objects in the bag with ILcyLucyEnv.addService(Object), and remove them from the bag with ILcyLucyEnv.removeService(Object). It is also possible to request from the bag all objects that extend or implement a certain class or interface.

An example use case of why it is important to have such a mechanism involves the Lucy map add-on: the map add-on has an action to load data on the map, which needs to support a lot of data formats. Loading data on the map requires model decoders and layer factories. You can make those model decoders and layer factories available as services. By letting the loading action delegate to the model decoder and layer factory services, the action can support all data formats. You can add support for an extra data format without changing any action code, by adding new model decoders and layer factories to the services.

In this scenario, the data format add-ons are the suppliers of the services, and the open action of the map add-on a consumer of those services.

See ILcyLucyEnv.getServices(Class) for more information, and for an overview of all types of objects which are available as service.

Summary: the service mechanism allows add-ons to register objects with a central registry, which can be queried and used by other add-ons. Doing so prevents hard dependencies between the different add-ons.

See The services documentation for more information.

Working with data

Lucy comes with support for opening data in a large number of formats — SHP, GeoJson, Dted, GeoTIFF, and so on — and connecting to a number of geospatial services: WMS, WFS, WCS, and so on. You can load data using both the UI and the API.

Furthermore, you can extend the UI and API functionality with support for your own business data.

See the Opening data in Lucy and Supporting a custom data format in Lucy documentation for more information.

Tool bars, menu bars and popup menus

The Lucy UI contains a number of tool bars, menu bars and popup menus. In the Lucy API, those UI components are commonly referred to as action bars. You can add entries to the action bars, remove entries, or trigger the actions contained in there programmatically.

See the Action Bars documentation for more information.

The workspaces mechanism

Lucy users can store the state of the application in a so-called workspace. Later, they can return the application to the state in which they left off by re-loading the workspace.

They do not have to reset their GUI preferences, nor do they have to re-load their maps. The GUI layout is restored as it was in the previous session, maps are opened in their previous positioning, and additional data is reloaded as map layers.

See the Workspaces documentation for more information.

The map component concept

The maps in Lucy contain an ILcdView, but also:

  • A layer control that gives you an overview of which layers are currently loaded, allows you to re-order the layers, and so on.

  • A tool bar that contains buttons to activate different controllers, a combo box to change the projection of the view, and so on.

  • A menu bar that contains actions to print the map, open and save data, and so on.

All those concepts are bundled in an ILcyGenericMapComponent.

There are two types of map components in Lucy: one with a Lightspeed view, and one with a GXY view. For more information, see the Action bars documentation.