Edit detail for Glasgow Code Guide revision 1 of 1

1
Editor: 10.1.0.1
Time: 2006/01/04 20:20:54 GMT+0
Note:

changed:
-
by Robin Rowe 
12/28/05; updated 1/4/06

"Up":http://cinepaint.bigasterisk.com/GlasgowDocumentation

Took a little longer, but the Glasgow code re-org is checked in. Builds in vcpp7. Other platforms broken until the relevant project files get updated for Linux, Mac, and vcpp8 respectively.

If you already have a check-out of Glasgow you may want to rename it and do a new check-out to another directory. Glasgow has been streamlined to have a lot fewer directories than before.

* app - executable code

* gui - gui.lib has app gui components

* plug-ins/ - plug-ins.dll needed by plug-ins and app

* plug-ins/image_ops - image_ops.dll handles image ops

* plug-ins/tools - tools.dll has toolbar tools

* utility - utility.lib of data structures, sockets 

* vcpp7 - VC++ 7 project files

Also under plug-ins are blur, jpeg, png, test_client, and tiff. These and plug-ins.dll should go away when open_img is integrated. The plug-ins in the new architecture are supposed to load from open_img.exe instead of cinepaint.exe. Glasgow reused some of the Film Gimp plug-ins as a stopgap because I'm still building open_img. The plan is to have open_img in February.

Under VC++ 7 I'm seeing some build link warnings with gui.lib for multiply defined methods. This seems to be caused when VC++ elects to make an inline method out-of-line (as is permitted by C++). When this happens it finds (identical) definitions in both plug-ins.dll and gui.lib and triggers a warning. One way to eliminate this warning is to make everything out-of-line in the classes causing warnings, but that's sub-optimal. Anyone know the right way to fix it?

The image_tools.dll was renamed image_ops.dll, but I haven't tested the code that loads it.

Sometime this week I'll check in FLTK 1.1.7. That should eliminate the window resize bug in our version of 1.1.6.

Old structure described below. Ignore.

<HR>

12/28/05

Note this structure is much too complex. To be changed. Confusingly, the project files and directories don't have a direct relationship. There are cpp files being linked from multiple directories.

CinePaint Glasgow VC++ Project Layout

 * cinepaint

 * color

 * core

 * core_interfaces

 * fl_table

 * gui

 * image

 * image_tools

 * libfltk

 * libjpeg

 * liblcms

 * libpthread

 * libtiff

 * painting

 * plugin_blur

 * plugin_jpeg

 * plugin_test_client

 * plugin_tiff

 * tools

 * util

CinePaint Glasgow Directory Layout

 * cinepaint-project/glasgow - top level directory

 * cinepaint-project/glasgow/app - top level 'src' directory

 * cinepaint-project/glasgow/app/gui - FLTK-based GUI

 * cinepaint-project/glasgow/app/gui/sheet - spreadsheet interface ui components

 * cinepaint-project/glasgow/app/lib -

 * cinepaint-project/glasgow/app/lib/color - color handling classes

 * cinepaint-project/glasgow/app/lib/dag - directed acyclic graph classes used within the spreadsheet

 * cinepaint-project/glasgow/app/lib/image - base image handling classes, buffers etc.

 * cinepaint-project/glasgow/app/lib/painting - painting classes, brush class, brush management

 * cinepaint-project/glasgow/app/lib/select - To be removed. Was intended to handle selections. Replaced with the SelectionManager and AbstractSelectionShape in image.

 * cinepaint-project/glasgow/app/lib/sys - To be removed. Too many levels.

 * cinepaint-project/glasgow/app/lib/sys/app - Core of the CinePaint application (no ui)

 * cinepaint-project/glasgow/app/lib/sys/app/ops - Image operation class definitions. The Scotland team's intention here was that a distribution would provide an default implementation of these standard image operations via the core-plug-ins mechanism. Needs to be rethought.

 * cinepaint-project/glasgow/app/lib/sys/cpgui - Abstract UI components. Scotland team intended to allow plugins to specify a UI component without linking CinePaint to any particular toolkit. We don't need this because using open_img for toolkit independence (and FLTK-only in CinePaint app).

 * cinepaint-project/glasgow/app/lib/sys/memory - Unused. Scotland team intended to monitor and report on plugin, and application memory usage.

 * cinepaint-project/glasgow/app/lib/sys/network - Scotland team built client-server handling classes into CinePaint. This will need to be removed because that's the function of open_img.

 * cinepaint-project/glasgow/app/lib/sys/plugindb - The PDB, plug-in database classes.

 * cinepaint-project/glasgow/app/lib/util - Generic utility functions that should be moved to an external lib.

 * cinepaint-project/glasgow/build - VC++ project files, but nested too many levels down. Need to be moved up and to rename VC++ to vcpp7.

 * cinepaint-project/glasgow/core-plugins - ???

 * cinepaint-project/glasgow/core-plugins/ops - image operation plugins, scale, fill handling, etc.

 * cinepaint-project/glasgow/core-plugins/tools - tool implementations that appear on the CinePaint tools dialog, and mouse event handling, for the particular tool.

 * cinepaint-project/glasgow/data - brushes, gradients, images, palettes and patterns.

 * cinepaint-project/glasgow/libs - Scotland team intended for static libs. Only thing here now is FL_Table. That should be moved outside to libfltk and libs removed. There should no libcinepaint in the Glasgow design because open_img will run as a daemon, not linked.

 * cinepaint-project/glasgow/plug-ins - blur, jpeg, png, test_client and tiff. These are temporary plug-ins needed because open_img architecture not in place yet. In the future plug-ins will be run from the open_img daemon. It's possible for an app to have it's own (private) plug-ins, but will be better to offer plug-ins through the open_img API because they become accessible to all apps.

The core-plug-ins design probably doesn't make sense with open_img, but here's how it works now. The image_tools.dll is loaded as imageops during app init. The tools.dll is loaded as tools. Likewise, the design of core and core_interfaces needs to be rethought. The Scotland team had core intended as the real guts of the CinePaint applications (without UI), whereas 'core_interfaces' was intended as all the interfaces that external apps/plugins may need.



by Robin Rowe 12/28/05; updated 1/4/06

Up

Took a little longer, but the Glasgow code re-org is checked in. Builds in vcpp7. Other platforms broken until the relevant project files get updated for Linux, Mac, and vcpp8 respectively.

If you already have a check-out of Glasgow you may want to rename it and do a new check-out to another directory. Glasgow has been streamlined to have a lot fewer directories than before.

  • app - executable code
  • gui - gui.lib has app gui components
  • plug-ins/ - plug-ins.dll needed by plug-ins and app
  • plug-ins/image_ops - image_ops.dll handles image ops
  • plug-ins/tools - tools.dll has toolbar tools
  • utility - utility.lib of data structures, sockets
  • vcpp7 - VC++ 7 project files

Also under plug-ins are blur, jpeg, png, test_client, and tiff. These and plug-ins.dll should go away when open_img is integrated. The plug-ins in the new architecture are supposed to load from open_img.exe instead of cinepaint.exe. Glasgow reused some of the Film Gimp plug-ins as a stopgap because I'm still building open_img. The plan is to have open_img in February.

Under VC++ 7 I'm seeing some build link warnings with gui.lib for multiply defined methods. This seems to be caused when VC++ elects to make an inline method out-of-line (as is permitted by C++). When this happens it finds (identical) definitions in both plug-ins.dll and gui.lib and triggers a warning. One way to eliminate this warning is to make everything out-of-line in the classes causing warnings, but that's sub-optimal. Anyone know the right way to fix it?

The image_tools.dll was renamed image_ops.dll, but I haven't tested the code that loads it.

Sometime this week I'll check in FLTK 1.1.7. That should eliminate the window resize bug in our version of 1.1.6.

Old structure described below. Ignore.


12/28/05

Note this structure is much too complex. To be changed. Confusingly, the project files and directories don't have a direct relationship. There are cpp files being linked from multiple directories.

CinePaint Glasgow VC++ Project Layout

  • cinepaint
  • color
  • core
  • core_interfaces
  • fl_table
  • gui
  • image
  • image_tools
  • libfltk
  • libjpeg
  • liblcms
  • libpthread
  • libtiff
  • painting
  • plugin_blur
  • plugin_jpeg
  • plugin_test_client
  • plugin_tiff
  • tools
  • util

CinePaint Glasgow Directory Layout

  • cinepaint-project/glasgow - top level directory
  • cinepaint-project/glasgow/app - top level src directory
  • cinepaint-project/glasgow/app/gui - FLTK-based GUI
  • cinepaint-project/glasgow/app/gui/sheet - spreadsheet interface ui components
  • cinepaint-project/glasgow/app/lib -
  • cinepaint-project/glasgow/app/lib/color - color handling classes
  • cinepaint-project/glasgow/app/lib/dag - directed acyclic graph classes used within the spreadsheet
  • cinepaint-project/glasgow/app/lib/image - base image handling classes, buffers etc.
  • cinepaint-project/glasgow/app/lib/painting - painting classes, brush class, brush management
  • cinepaint-project/glasgow/app/lib/select - To be removed. Was intended to handle selections. Replaced with the SelectionManager and AbstractSelectionShape in image.
  • cinepaint-project/glasgow/app/lib/sys - To be removed. Too many levels.
  • cinepaint-project/glasgow/app/lib/sys/app - Core of the CinePaint application (no ui)
  • cinepaint-project/glasgow/app/lib/sys/app/ops - Image operation class definitions. The Scotland team's intention here was that a distribution would provide an default implementation of these standard image operations via the core-plug-ins mechanism. Needs to be rethought.
  • cinepaint-project/glasgow/app/lib/sys/cpgui - Abstract UI components. Scotland team intended to allow plugins to specify a UI component without linking CinePaint to any particular toolkit. We don't need this because using open_img for toolkit independence (and FLTK-only in CinePaint app).
  • cinepaint-project/glasgow/app/lib/sys/memory - Unused. Scotland team intended to monitor and report on plugin, and application memory usage.
  • cinepaint-project/glasgow/app/lib/sys/network - Scotland team built client-server handling classes into CinePaint. This will need to be removed because that's the function of open_img.
  • cinepaint-project/glasgow/app/lib/sys/plugindb - The PDB, plug-in database classes.
  • cinepaint-project/glasgow/app/lib/util - Generic utility functions that should be moved to an external lib.
  • cinepaint-project/glasgow/build - VC++ project files, but nested too many levels down. Need to be moved up and to rename VC++ to vcpp7.
  • cinepaint-project/glasgow/core-plugins - ???
  • cinepaint-project/glasgow/core-plugins/ops - image operation plugins, scale, fill handling, etc.
  • cinepaint-project/glasgow/core-plugins/tools - tool implementations that appear on the CinePaint tools dialog, and mouse event handling, for the particular tool.
  • cinepaint-project/glasgow/data - brushes, gradients, images, palettes and patterns.
  • cinepaint-project/glasgow/libs - Scotland team intended for static libs. Only thing here now is FL_Table. That should be moved outside to libfltk and libs removed. There should no libcinepaint in the Glasgow design because open_img will run as a daemon, not linked.
  • cinepaint-project/glasgow/plug-ins - blur, jpeg, png, test_client and tiff. These are temporary plug-ins needed because open_img architecture not in place yet. In the future plug-ins will be run from the open_img daemon. It's possible for an app to have it's own (private) plug-ins, but will be better to offer plug-ins through the open_img API because they become accessible to all apps.

The core-plug-ins design probably doesn't make sense with open_img, but here's how it works now. The image_tools.dll is loaded as imageops during app init. The tools.dll is loaded as tools. Likewise, the design of core and core_interfaces needs to be rethought. The Scotland team had core intended as the real guts of the CinePaint applications (without UI), whereas core_interfaces was intended as all the interfaces that external apps/plugins may need.