Web Analytics Made Easy - Statcounter
Skip to content

SDK Organization#

The SAMSON SDK is large, but its structure is consistent. This page gives you a map you can keep in mind while reading headers, generated API pages, and sample code.

The SDK is organized into seven library groups:

How to use this map#

When you are looking for an API entry point:

  • start in Facade if you want top-level convenience functions such as SAMSON::...
  • go to DataModel for persistent objects, documents, nodes, references, and containers
  • go to GUI for windows, widgets, editors, controllers, and rendering-side tools
  • go to IO for file import/export infrastructure
  • go to Modeling and Simulation for scientific model and simulator abstractions
  • go to Core for lower-level utilities and cross-cutting infrastructure

This rough map saves a lot of time when navigating the codebase.

Naming conventions#

Most files contain one main class declaration or definition, and the file name usually matches the class name. Because the SDK is large, SAMSON follows a strict naming convention.

For SDK classes:

  • The first two letters are SB (stands for SAMSON Base)
  • The third letter indicates the library group (e.g., SBD for DataModel)
  • The next n letters indicate the library name (e.g., SBDDataGraph for the DataGraph library in DataModel)
  • The (optional) next m letters are used to differentiate class names in the library (e.g., SBDDataGraphEvent and SBDDataGraphNode)

This is why class names are long but descriptive.

Short names#

Frequently used classes often have a short name. For example, SBMStructuralModelNodeAtom has the short name SBAtom.

Short names are convenient in day-to-day code, but the long names are useful when you are exploring the SDK structure because they reveal where the class comes from.

Extension naming conventions#

Classes generated by the Extension Generator follow a parallel convention:

  • The first two letters are SE (stands for SAMSON Extension)
  • The next n letters indicate the Extension name (e.g., ProteinProteinDocker)
  • The next m letters indicate a class name (e.g., MainApp)

That convention is worth preserving when you add new classes manually because it keeps extension code readable and consistent with generated code.

Finally, SDK macros begin with SB_, for example SB_REGISTER_TYPE.

Practical navigation advice#

  • If you know a short name, use the generated API pages to jump to the full class.
  • If you only know the domain, start from the library group index and narrow down by subsystem.
  • When a class name looks long, read it as a path: prefix, library group, library, then class role.