Introduction

The Solid Fluid project manager is an application framework scheme for organising disk file objects into virtual structures independent of their actual location on disk. The project manager allows these objects to be launched by the application, or by an external one. The project manager tool pane is shown below;

The project manager is actually composed of two discrete parts. The library is a tree in the same form as that of a project, the other part. The library is a persistent part of the application, stored with the application configuration settings, and is loaded when the application starts. By contrast the project is an optional component, loaded like a file or document in the main window of the application.

Overall the tree structure is virtual. Although the contained files must all exist somewhere in permenant storage, the folder structure only exists within the actual file used to store the library or project. In practice this means that the structure on disk does not have to represent that of the library or project. This is an important capability when dealing with large numbers of files.

Often, and especially in programming source code files, the structure on disk is manadted by external factors, like the programming language. When working with these files however, it is often the case that the way the user thinks of them is different from that mandatory structure. Being able to work with files in this way means that a user can organise files such that they are convenient to find and work with, and still use a disk structure which is mandated by external factors.

Four ways of working with libraries and projects are envisaged;

• Library oriented - Where the library is used for organising and accessing files which are common to a number of different projects. Because the libraries are loaded with the application and are always there, working with these files is always possible. At the project level, each group of files is different, and their content is likely to reference that of the libraries. The project is loaded at the users discretion, and within the scope of the application, both the libraries and project are accessible. Since the libraries are always there, when a new project is created, there is no need to add all of the necassary libraries to the new project.
  
  
• Project oriented - Where a library is considered a superproject. In this approach, it is possible to contain different projects within the library structure. There isn't that much to say about this approach, except that it greatly simplifies the process of finding and launching projects.
  
  
• Pick and mix - In practice there is nothing to prevent a user working in both these ways at once.
  
  
• Simplified - If you only have just a few files, and that's all you're ever going to work with, then you can forget about the project, and use the library manager as a project manager. Unlike a typical embedded project manager working in this way saves you ever having to find your project files on disk.
  
  

None of these schemes is anything other than a way to think about, and use, the project/library manager. Without the persistence of the library mechanism it's not possible to work in any of these ways.

As you can see in the screenshot above, selecting projects and libraries for manipulation is simply a matter of clicking the appropriate tab at the bottom of the toolpane.

We find the capability of the project manager to launch files in external applications is very useful. The example shown above is the developing drawing of the LBSCR B1 "Gladstone" discussed elswhere on this site. In this instance we are using an external 2D CAD system to actually do the drawings. From our Osmium application we can organise and call upon the CAD drawings, and our research/reference data. Not only this, but we can use the Osmium editor to provide commentary, notes and documentation for the actual development and decision making used in this work.