Edit detail for Glasgow Project Layout revision 1 of 1

1
Editor: 10.1.0.1
Time: 2005/09/08 09:33:01 GMT+0
Note:

changed:
-
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.

 http://custodiev.org/tiki/tiki-index.php?page=CodeLayout

Directory Layout

 * app           - top level 'src' directory

  * lib          - the various libs built within cinepaint the intention here was to build and keep each set of
                  classes separate by their purpose.

   * color       - color handling classes

   * dag         - directed acyclic graph classes used within the spreadsheet

   * image       - base image handling classes, buffers etc.

   * painting    - painting classes, brush class, brush management

   * select      - intended to handle selections, replaced with the SelectionManager and
                  AbstractSelectionShape in image. I Think this can be removed now.

   * sys         - the core of the CinePaint system. this is where we start to hook together the other libs.

    * app        - core of the CinePaint application (no ui)

     * ops       - standard image operation class definitions. the intention here was that a distribution would provide an default implementation of these standard image operations via the core-plug-ins mechanism.

    * cpgui      - abstract UI components, these were intended to allow various parts of CinePaint (a plugin for example) to specify (and use?) a UI component, without linking CinePaint to any particular toolkit.

    * memory     - these are not used at the moment. The intention was to monitor and report on plugin, and application memory usage.

    * network    - client server handling classes.

    * plugindb   - the 'standard' plugin database classes and management.

   * util        - various utility classes and functions.

  * gui          - the CinePaint ui, based on fltk.

   * sheet       - the spreadsheet interface ui components

 * core-plug-ins - core plugin components that allow CinePaint to do useful things.

  * ops          - image operation plugins, scale, fill handling etc.

  * tools        - individual tool implementations that appear on the CinePaint tools dialog, and mouse event handling, for the particular tool.

 * libs          - additional libs required by cinepaint I've added a modified version of FL_Table here, used
within the spreadsheet ui.

 * plug-ins      - the 'standard' plugins, each in its own sub-directory

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.

 * color     lib/color

 * image     lib/image

 * painting  lib/painting

 * util      lib/util

 '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.

 * blur

 * jpeg

 * tiff

 * test_client

 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)

 * layers

 * select

 * selectors

 * toolbar

 * trans

Building

 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?



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.

http://custodiev.org/tiki/tiki-index.php?page=CodeLayout

Directory Layout

  • app - top level src directory
    • lib - the various libs built within cinepaint the intention here was to build and keep each set of classes separate by their purpose.
      • color - color handling classes
      • dag - directed acyclic graph classes used within the spreadsheet
      • image - base image handling classes, buffers etc.
      • painting - painting classes, brush class, brush management
      • select - intended to handle selections, replaced with the SelectionManager and AbstractSelectionShape in image. I Think this can be removed now.
      • sys - the core of the CinePaint system. this is where we start to hook together the other libs.
        • app - core of the CinePaint application (no ui)
          • ops - standard image operation class definitions. the intention here was that a distribution would provide an default implementation of these standard image operations via the core-plug-ins mechanism.
        • cpgui - abstract UI components, these were intended to allow various parts of CinePaint (a plugin for example) to specify (and use?) a UI component, without linking CinePaint to any particular toolkit.
        • memory - these are not used at the moment. The intention was to monitor and report on plugin, and application memory usage.
        • network - client server handling classes.
        • plugindb - the standard plugin database classes and management.
      • util - various utility classes and functions.
    • gui - the CinePaint ui, based on fltk.
      • sheet - the spreadsheet interface ui components
  • core-plug-ins - core plugin components that allow CinePaint to do useful things.
    • ops - image operation plugins, scale, fill handling etc.
    • tools - individual tool implementations that appear on the CinePaint tools dialog, and mouse event handling, for the particular tool.
  • libs - additional libs required by cinepaint I've added a modified version of FL_Table here, used within the spreadsheet ui.
  • plug-ins - the standard plugins, each in its own sub-directory

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.

  • color lib/color
  • image lib/image
  • painting lib/painting
  • util lib/util

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.

  • blur
  • jpeg
  • tiff
  • test_client

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)

  • layers
  • select
  • selectors
  • toolbar
  • trans

Building

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?