<div dir="ltr">Don't forget doc. As part of your MR, please create a new section under Ekos in the handbook (source is in kstars/doc/ and some info about "compiling the doc" is in the KStars README--even though it's a weird new "language", writing by using examples of other doc isn't too bad).<div><br></div><div>Also, please remind me what you mean by "plug-in" (I guess, write some paragraph that will eventually wind up in the handbook). BTW, just checking...is plug-in the right word?</div><div><br></div><div>Thanks for doing this--I think writing the doc early will help explain what you're up to. </div><div><br></div><div>Hy</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2024 at 12:53 PM Ed Lee <<a href="mailto:ed@thefamilee.co.uk">ed@thefamilee.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
Hi all, <br>
<br>
Here's a progress update on this topic as I have made a start into
implementing this. <br>
<br>
<u>GUI</u><br>
I've put the plugin interface on the Manager ui like this...<br>
<br>
<img src="cid:ii_18e2f22e5717d7a3ed91" alt="" width="1024" height="768"><br>
<br>
This was for two reasons:<br>
<ol>
<li>A plugin could be relevant to any one or more Modules.</li>
<li>I'm using the preview window as the receiver for the live
stacked image from Siril.</li>
</ol>
<p><u>Application interface</u><br>
</p>
<p>I have the DBus interaction working in both directions and log
pass through from the QProcess that holds the plugin.</p>
<p><u>Plugin design</u></p>
<p>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.</p>
<p>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.</p>
<p><u>Plug in progress</u></p>
<p>I've finished the firecapture_launcher plugin. It works as I
described.</p>
<p>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.</p>
<p><u>Outstanding</u></p>
<p>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.<br>
</p>
<p>Lots of testing is required. This won't be ready for 3.7.0. but
hopefully could be for the following release.</p>
<p><br>
</p>
<p>*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.</p>
<p>Regards</p>
<p>Ed Lee<br>
</p>
<p><br>
</p>
<br>
<br>
<div>On 23/02/2024 13:56, Ed Lee wrote:<br>
</div>
<blockquote type="cite">
Hi Wolfgang, <br>
<br>
I'll have a bit of a hack about with a view to scoping the pros
and cons with different approaches.<br>
<br>
Kind regards<br>
Ed Lee<br>
<br>
<div>On 23/02/2024 13:04, Wolfgang
Reissenberger wrote:<br>
</div>
<blockquote type="cite">
Hi Ed,
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Kstars has a fairly good (but insufficiently documented)
DBus interface for scripting, which could be used that way.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>- Wolfgang</div>
<div>
<div dir="ltr">--
<div>
<div><span style="background-color:rgba(255,255,255,0)">Wolfgang
Reissenberger</span></div>
<div><span style="background-color:rgba(255,255,255,0)"><a href="http://www.sterne-jaeger.de" target="_blank">www.sterne-jaeger.de</a></span></div>
</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">Am 23.02.2024 um 09:51 schrieb Ed
Lee <a href="mailto:ed@thefamilee.co.uk" target="_blank"><ed@thefamilee.co.uk></a>:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<font face="Arial">Hi Wolfgang, <br>
<br>
Some more details regarding the second idea...<br>
<br>
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. <br>
<br>
My current preferred workflow for a planetary capture
is:<br>
</font>
<ul>
<li><font face="Arial">Start KStars/Ekos</font></li>
<li><font face="Arial">Polar align using Ekos plate
solving</font></li>
<li><font face="Arial">Train a quick mount model using
Ekos plate solving</font></li>
<li><font face="Arial">Rough focus in Ekos (I'm manually
focussing with a Bahtinov mask)</font></li>
<li><font face="Arial">Slew to planetary target in
KStars</font></li>
<ul>
<li><font face="Arial">In INDI control panel,
disconnect imaging camera</font></li>
<li><font face="Arial">Launch FireCapture from the
Desktop</font></li>
</ul>
<li><font face="Arial">In FireCapture, connect to INDI,
focus, adjust settings, capture, close FireCapture</font></li>
<ul>
<li><font face="Arial">In INDI control panel,
reconnect imaging camera (if attempting another
target in the session).</font></li>
</ul>
</ul>
<p><font face="Arial">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.</font> 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.<br>
</p>
<p>Hope that helps in understanding my intent?</p>
<p>Kind regards</p>
<p>Ed<br>
</p>
<font face="Arial"><br>
</font>
<div>On 22/02/2024 22:27, Wolfgang
Reissenberger wrote:<br>
</div>
<blockquote type="cite">
Dear Ed,
<div>very interesting ideas!</div>
<div><br>
</div>
<div>The first idea should be feasible.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers</div>
<div>Wolfgang</div>
<div>
<div><br>
<blockquote type="cite">
<div>Am 21.02.2024 um 15:50 schrieb Jasem Mutlaq <a href="mailto:mutlaqja@ikarustech.com" target="_blank"><mutlaqja@ikarustech.com></a>:</div>
<br>
<div>
<div dir="ltr">Hello Ed,
<div><br>
</div>
<div>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. </div>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--</div>
<div>Best Regards,<br>
Jasem Mutlaq<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb
21, 2024 at 5:35 PM Ed Lee <<a href="mailto:ed@thefamilee.co.uk" target="_blank">ed@thefamilee.co.uk</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <font face="Arial">Hi,<br>
<br>
Although KStars is growing ever more
capable there are other programs that I
like to use in conjunction, mostly for
convenience.<br>
<br>
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. <br>
<br>
Two examples of how I would like to use
a generalised call:<br>
</font>
<ul>
<li><font face="Arial">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.<br>
</font></li>
<li><font face="Arial">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.</font></li>
</ul>
<p><font face="Arial">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.</font></p>
<p><font face="Arial">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.</font></p>
<p><font face="Arial">Kind Regards</font></p>
<p><font face="Arial">Ed Lee<br>
</font></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
<br>
</div>
</blockquote></div>