Web Analytics Made Easy - Statcounter
Skip to content

Developing GUI#

GUIs for SAMSON and SAMSON Extensions are built with Qt 6.10.2.

This page is not a Qt tutorial. Its purpose is to explain how GUI code should be structured inside a SAMSON extension so the result remains maintainable, distributable, and easy to integrate with the rest of the SDK.

The core design rule#

Keep GUI code focused on interaction with the user.

Use GUI classes to:

  • collect input
  • trigger actions
  • display state and results
  • manage widgets, forms, and interaction flow

Do not put core scientific logic, file parsing, or non-visual processing in GUI classes when it can live in data-side classes such as apps, models, or helper objects.

That separation is important for three reasons:

  • your functionality becomes easier to reuse outside the GUI
  • scripting and introspection stay cleaner
  • testing and maintenance become simpler

Typical GUI pairings in SAMSON#

Several extension types have a natural GUI counterpart:

  • an app often uses SBGApp
  • a data graph node may have an SBGDataGraphNode GUI class
  • property windows and specialized widgets are used to expose object state to the user

The common pattern is:

  1. put the logic in the data-side class
  2. let the GUI call into that logic
  3. keep widget code thin and explicit

Qt in a distributable extension#

Qt offers many modules, but not every Qt module is appropriate for a SAMSON extension that will be distributed through SAMSON Connect. In particular, module licensing matters. Avoid Qt modules whose licensing would make the extension unsuitable for distribution in the SAMSON ecosystem.

When in doubt, check the license terms for the exact Qt module you plan to use before you build a dependency on it.

Working with forms#

The Extension Generator creates Qt forms where they are needed. Those .ui files are a good starting point for standard windows and property panels.

For day-to-day form editing, Qt Creator is a practical choice:

A practical example#

Suppose you are building an optimization tool:

  • the app class owns parameters, execution logic, and result handling
  • the GUI contains text fields, checkboxes, progress feedback, and action buttons
  • button clicks call app methods rather than implementing the optimization directly in widget slots

That structure keeps the extension usable from both the GUI and from programmatic entry points.

Good practices#

  • Keep long-running or scientific logic out of widget classes.
  • Make UI state reflect real application state rather than duplicating it unnecessarily.
  • Treat generated forms as a starting point, not as the place to hide business logic.
  • Prefer clear, direct signal-slot wiring over overly implicit UI behavior.
  • Apps and Editors for the extension types most commonly paired with GUI code
  • Tutorials for complete GUI examples