Interoperability proposal

[hans at lambermont.dyndns.org]

Hi Ed,

Cool that you work on this !

My first thougts :

- Call them 'integrations' instead of plugins.
- PHD2 and LinGuider are existing examples with which we integrate. As such they are to be listed in your selector.
- I expect these integrations to be listed and managed in the profiles. Not here as a step 4 after connect/disconnect.

-- Hans

Ed Lee wrote on 20240311:
> Hi all,
> 
> Here's a progress update on this topic as I have made a start into
> implementing this.
> 
> _GUI_
> I've put the plugin interface on the Manager ui like this...
> 
> 
> 
> This was for two reasons:
> 
> 1. A plugin could be relevant to any one or more Modules.
> 2. I'm using the preview window as the receiver for the live stacked
>    image from Siril.
> 
> _Application interface_
> 
> I have the DBus interaction working in both directions and log pass through
> from the QProcess that holds the plugin.
> 
> _Plugin design_
> 
> I've designated a new plugins sub-directory of the KStars
> AppLocalDataLocation (on my machine ~/.local/share/kstars/plugins). On start
> of INDI in the Manager UI this is searched for plugins that have a valid
> configuration file (see below) and optionally an icon file. The validated
> list populates the ComboBox.
> 
> The configuration file must contain a minimum_kstars_version string that is
> checked against the KSTARS_VERSION so plugins can't be used on earlier
> unsupported versions. My plugins also check this matches internally.
> 
> _Plug in progress_
> 
> I've finished the firecapture_launcher plugin. It works as I described.
> 
> I've tested all the individual parts of the siril_eaa plugin. I can set up
> Siril in headless mode for live stacking, watching the save directory set in
> a Capture job, and receive the live-stacked result back into the Capture
> preview window on the Manager UI. I just need to do all the conditional
> tests and logic.
> 
> _Outstanding_
> 
> I'm not sure of the best way in which to distribute the plugins once the
> facility is integrated. I've got them in github under my own account at the
> moment but if this ability is well received and other plugins are produced
> we may want a more centralised repository. I think it should be kept
> separate from the KStars codebase as there are no direct dependencies.* I'd
> like to hear any other thoughts on this, and indeed any other aspect of this
> proposal.
> 
> Lots of testing is required. This won't be ready for 3.7.0. but hopefully
> could be for the following release.
> 
> 
> *Some enums are copied over for status flag monitoring on DBus. I couldn't
> utilise the xml DBus directly as there are custom types that are defined in
> with other stuff (for instance in ekos.h) that results in a cascade of
> dependencies.
> 
> Regards
> 
> Ed Lee
> 
> 
> 
> 
> On 23/02/2024 13:56, Ed Lee wrote:
> > Hi Wolfgang,
> > 
> > I'll have a bit of a hack about with a view to scoping the pros and cons
> > with different approaches.
> > 
> > Kind regards
> > Ed Lee
> > 
> > On 23/02/2024 13:04, Wolfgang Reissenberger wrote:
> > > Hi Ed,
> > > is there a benefit keeping Kstars alive when the handover to
> > > FireCapture? Or is the only requirement when Kstars terminates that
> > > the INDI server is running?
> > > 
> > > For the latter it’s a lot simpler to start the INDI server remotely,
> > > because in this case the INDI server stays alive when Kstars
> > > terminates.
> > > 
> > > What about thinking the other way round and build an orchestration
> > > client that starts Kstars and the required steps, stops it when its
> > > tasks are finished and launches FireCapture to continue.
> > > 
> > > Kstars has a fairly good (but insufficiently documented) DBus
> > > interface for scripting, which could be used that way.
> > > 
> > > You hear, I‘m slightly sceptical about integrating such an approach
> > > into Kstars. We have done substantial progress in terms of
> > > modularisation, but our core modules are part of the application and
> > > not exchangeable plugins.
> > > 
> > > - Wolfgang
> > > -- 
> > > Wolfgang Reissenberger
> > > www.sterne-jaeger.de
> > > 
> > > > Am 23.02.2024 um 09:51 schrieb Ed Lee <ed at thefamilee.co.uk>:
> > > > 
> > > >  Hi Wolfgang,
> > > > 
> > > > Some more details regarding the second idea...
> > > > 
> > > > In FireCapture, the imaging camera is handled directly for
> > > > maximum throughput. Other equipment must be connected via INDI
> > > > (or ASCOM). The other equipment in this case can be mount,
> > > > filter wheel and focuser. There is no need, from FireCapture's
> > > > perspective, for KStars/Ekos, only INDI. So it's possible, but
> > > > clunky, to launch an INDI server handling all the kit from the
> > > > command line before starting FireCapture.
> > > > 
> > > > My current preferred workflow for a planetary capture is:
> > > > 
> > > >   * Start KStars/Ekos
> > > >   * Polar align using Ekos plate solving
> > > >   * Train a quick mount model using Ekos plate solving
> > > >   * Rough focus in Ekos (I'm manually focussing with a Bahtinov mask)
> > > >   * Slew to planetary target in KStars
> > > >       o In INDI control panel, disconnect imaging camera
> > > >       o Launch FireCapture from the Desktop
> > > >   * In FireCapture, connect to INDI, focus, adjust settings,
> > > >     capture, close FireCapture
> > > >       o In INDI control panel, reconnect imaging camera (if
> > > >         attempting another target in the session).
> > > > 
> > > > So I'm using KStars/Ekos for setup and INDI server management,
> > > > and FireCapture for capture and guiding. When FireCapture is
> > > > active it's vital that KStars/Ekos is in an idle state, so in
> > > > this case the button would only be active when the scheduler is
> > > > not running, guiding is not active and no capture job is
> > > > running. The plugin would just handle the three indented actions
> > > > above. I wouldn't intend to manage the capture session in any
> > > > way (guiding/focus/flip), that's the job of the capture control
> > > > system - in my case FireCapture.
> > > > 
> > > > Hope that helps in understanding my intent?
> > > > 
> > > > Kind regards
> > > > 
> > > > Ed
> > > > 
> > > > 
> > > > On 22/02/2024 22:27, Wolfgang Reissenberger wrote:
> > > > > Dear Ed,
> > > > > very interesting ideas!
> > > > > 
> > > > > The first idea should be feasible.
> > > > > 
> > > > > Regarding the idea interacting with FireCapture I’m not sure
> > > > > if I understand the intention behind. Is there the idea to
> > > > > use KStars for positioning the scope to the target, but then
> > > > > switching (at least capturing) to FireCapture? Should
> > > > > guiding continue running for example? What about meridian
> > > > > flip? Or Refocusing? There are many features of other
> > > > > modules that lead to interaction with the Capture module.
> > > > > 
> > > > > Cheers
> > > > > Wolfgang
> > > > > 
> > > > > > Am 21.02.2024 um 15:50 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com>:
> > > > > > 
> > > > > > Hello Ed,
> > > > > > 
> > > > > > That's a great idea. Perhaps something like "Plugins"
> > > > > > that could be used to add extra functionality? KStars
> > > > > > can be scripted by DBus though the documentation & level
> > > > > > of support for this can be improved.
> > > > > > 
> > > > > > --
> > > > > > Best Regards,
> > > > > > Jasem Mutlaq
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, Feb 21, 2024 at 5:35 PM Ed Lee <ed at thefamilee.co.uk> wrote:
> > > > > > 
> > > > > >     Hi,
> > > > > > 
> > > > > >     Although KStars is growing ever more capable there are other
> > > > > >     programs that I like to use in conjunction, mostly for
> > > > > >     convenience.
> > > > > > 
> > > > > >     It occurs to me that my workflow could be made easier and the
> > > > > >     system capabilities extended by providing a generalised means
> > > > > >     to call other programs from within KStars/Ekos. At present
> > > > > >     there is already a specific occurrence of this where the
> > > > > >     scheduler can call start up / shut down scripts.
> > > > > > 
> > > > > >     Two examples of how I would like to use a generalised call:
> > > > > > 
> > > > > >       * Add a button to the Capture module that launches an
> > > > > >         external live stacking application (for example Siril),
> > > > > >         pass it the necessary commands to start receiving images
> > > > > >         from the current selected camera, and then start repeating
> > > > > >         captures. Stop capturing when the external process closes.
> > > > > >       * Add a button to the Capture module that disconnects the
> > > > > >         current selected camera from the INDI server and then
> > > > > >         launches FireCapture for planetary imaging. Reconnect the
> > > > > >         camera when the external process closes.
> > > > > > 
> > > > > >     Abstracting the external program calls via scripts would allow
> > > > > >     user customisation and avoid any dependencies on / promotion
> > > > > >     of specific software. Sample scripts could be provided. It may
> > > > > >     also make the implementation simpler - an abstraction of the
> > > > > >     current scheduler script processing with additional control
> > > > > >     processes within KStars.
> > > > > > 
> > > > > >     Before I start working on this I wanted to ask for any
> > > > > >     thoughts on this proposal, both regarding the implementation
> > > > > >     and also whether this would be perceived an acceptable route
> > > > > >     for KStars.
> > > > > > 
> > > > > >     Kind Regards
> > > > > > 
> > > > > >     Ed Lee
> > > > > > 
> > > > > 
> > > > 
> >