[prev in list] [next in list] [prev in thread] [next in thread]
List: kstars-devel
Subject: Re: Interoperability proposal
From: Wolfgang Reissenberger <wolfgang () openfuture ! de>
Date: 2024-02-22 22:27:54
Message-ID: EAB7C3FB-E763-4EEC-AFA7-750B25B4674B () openfuture ! de
[Download RAW message or body]
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@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@thefamilee.co.uk <mailto:ed@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
> >
[Attachment #3 (unknown)]
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body \
style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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 <mutlaqja@ikarustech.com>:</div><br \
class="Apple-interchange-newline"><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" data-smartmail="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">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>
<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></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic