home contents changes options help

Colin Law 9/8/2005

This document describes our initial directory layout. Its a little incomplete, and out of date now, so I'll try clarify things, and add how we were building things.


Directory Layout

Project Files

There are some discrepancies in the naming of the project files and how they tie up to the various directories. Some are caused through changing things over time, others are were bad choices from the start, core, and sys were perhaps not the best choices for names.

We build various libs within glasgow, essentially the groups of related classes. Each of these is in its own directory, except the dag stuff. I was having dependency problems within the various dll's when I added this as its own project originally. I finally added it directly to the core project. Ideally, to maintain consistency with how each of the other libs is built, the dag stuff should also be separate.

gui obviously builds the cinepaint UI. This includes the sheet subdirectory for the spreadsheet, which was separated purely to keep related classes together within the filesystem, they are just another part of the UI.

image_tools should really be renamed. It is in fact the image operations core plug-ins, core-plug-ins/ops. All the plugins are built into one dll. ImageOps, or {Core|Default|Standard}ImageOps would be a better name.

tools is the other half of the core-plug-ins and creates a single dll from each of the tool plugins in core-plug-ins/tools. As these are our default set of tools, it would be a good idea to rename this to match whatever prefix is added to the image ops above.

fl_table builds a modified version of FL_Table required within the spreadsheet. Everything is under libs/Fl_Table

The Plugin projects are fairly easy. Everything is under the plugins directory, each plugin in its own directory.

the core and core_interfaces interfaces are slightly different. Everything within these two projects should fall under the lib/sys/ directory, and subdirectories. The difference between the two is that core is intended as the real guts of the CinePaint applications (without UI), whereas core_interfaces is intended as all the interfaces that external apps/plugins may need. IIRC, this separation arose due to the various dependencies between the dll's again. I'm not so sure this separation works particularly well anymore.

the cinepaint project pulls everything together into the CinePaint application.

I think these projects can be removed now, they don't actually contain any files do they? (I briefly checked inside the .proj file)


Glasgow is currently built differently under Win32 and Linux.

Under Linux, I build a libcinepaintg (added g to signify glasgow and avoid clashing with the current CinePaint) and a CinePaint application, which links to libcinepaintg. The CinePaint app is essentially main plus the UI.

We build several more dll's under Win32. The original intention was to allow other applications to link to only certain parts of CinePaint, the color handling classes for example. In theory this sounds fine, but I'm not sure if this is still a good model, or if it just creates more dependency problems, thoughts?