future_of_swift

Thoughts on the future direction of swift

Decompose blackmisc and blackcore into smaller, more cohesive libraries.

  • The new libraries would lose the vestigial “black” prefix which is a point of confusion for new contributors.
  • By being smaller and more cohesive, they can be truly reusable and not tightly coupled to one specific pilot client.
    • For example, another project can use our FSD and AFV implementations without being forced to include DBus and other irrelevant stuff.
    • By this we try to ensure that our code has more longevity, attract collaborators, and create maximum value for the community.
  • This process of decoupling is also necessary for reducing complexity.
    • We hope it will open up new opportunities, such as the possibility to create a new client building upon the core of swift.

The first step to decomposing blackmisc and blackcore is to break the cyclic dependencies between modules.

  • “Module” means a header file and its corresponding .cpp file.
  • So far this has been done for the modules in the root directory of blackmisc.
  • I have used various ad-hoc scripts to detect cycles in the dependency graph, but none works 100% perfectly.
  • When a particularly difficult cycle is detected, one of several different refactoring patterns can be applied to break the cycle:

Integrate propertyindex methods of value classes into the metaclass system.

  • The metaclass system (formerly the tuple system) can be used to rationalize a lot of propertyindex-related methods, but this is a lot of work.
  • This is made possible with C++17 support (especially constexpr lambda functions).

Simplify the plugin system and support for multiple simulators.

  • There is no need to switch between different simulators on the fly. This feature adds unnecessary complexity.
  • It is sufficient to allow the user to choose one simulator when they launch swift. To use a different one, they can restart swift.
  • We could drop the plugin system completely, and just ship a different swift executable for each sim.

Simplify the installer.

  • Set up a standard configuration and model set by default. Keep the wizard for advanced users.
  • XSwiftBus could be included in the installer instead of being downloaded in a separate step.
    • Another possibility is for the X-Plane plugin to be a stub that does nothing but load the “real” plugin as directed by the pilot client.
    • The stub only needs to be installed in the X-Plane plugins directory once. The “real” plugin lives in the swift installation directory.
      • The loading can be done using libltld (cross-platform dynamic linker).
      • The client can send the path of the “real” plugin via simple network protocol:
        • The built-in UDP protocol of X-Plane;
        • Or JSON with a basic HTTP server (e.g. libhttpserver).

SharedState is the new subsystem designed to replace many parts of swift, including the cache, settings, hotkeys, contexts, etc.

  • The logging system is already using it.
  • Eventually we could migrate from DBus to QtRemoteObjects.

Reduce the client's dependency on web services maintained by us, like the datastore.

  • The datastore adds value, but swift should still be able to work without it, and not use it as a crutch.
  • As many features as possible should be able to work without the datastore. We should only use it for features that really need it.
  • If the datastore is unavailable, swift should gracefully degrade to an alternate mode with relevant features disabled.
  • We can't maintain it forever and we should aim to simplify it as much as possible to reduce the maintenance cost.

Thoughts on UI

  • More streamlined UI with most common features immediately accessible. Less common features hidden in menus and pages.
  • Avoid grids of buttons. Use more icons in place of (or in addition to) text.
  • Inspiration may be taken from Drago's prototype.
  • Can be embedded in simulator? Consider other UI libraries?
  • Avoid business logic in UI code. Move it to the core.

CApplication needs a deep redesign focusing on the startup and shutdown procedures, decoupling and splitting into smaller classes.

  • future_of_swift.txt
  • Last modified: 2021/04/17 17:09
  • by msutcliffe