Interoperability proposal

Mon Mar 11 19:52:55 GMT 2024

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
>>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20240311/005f6852/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2nJLQiag0ZZeBHK2.png
Type: image/png
Size: 631728 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20240311/005f6852/attachment-0001.png>