Future 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. => done
• 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:
  • I refer to the "levelization techniques" described in chapter 5 of "Large Scale C++ Software Design" by John Lakos:
    • Escalation, demotion, opaque pointers, dumb data, redundancy, callbacks, manager class, factoring, escalating encapsulation.
    • See also https://github.com/swift-project/pilotclient/issues/77#issuecomment-683468351
    • Examples of dumb data: 63e8de8f, b1185eb5
    • Example of demotion: ecac4bcb

Integrate propertyindex methods of value classes into the metaclass system.

• The metaclass 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).
• See also https://github.com/swift-project/pilotclient/issues/27

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.
• See also https://github.com/swift-project/pilotclient/issues/49
• 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.

• Related to https://github.com/swift-project/pilotclient/issues/33