<div dir="ltr">I think there are some inherently interactive aspects of KStars/Ekos that probably shouldn't be blocked--things that aren't part of automation. Would there be a separate pop-up notification class for those things that wouldn't be blocked?<div><br><div>As an example, there's a pop-up in the Analyze tab that's activated when the user tries to configure the display to show an HFR graph but HFR is not being computed. There's also a pop-up Help button.</div></div><div><br></div><div>I do agree that all blocking pop-ups should have a default "lifetime" of no more than 5 minutes.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 20, 2021 at 4:25 AM Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com">mutlaqja@ikarustech.com</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 dir="ltr">Great, I've created an issue here: <a href="https://invent.kde.org/education/kstars/-/issues/84" target="_blank">https://invent.kde.org/education/kstars/-/issues/84</a><div><br clear="all"><div><div dir="ltr"><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 Tue, Apr 20, 2021 at 1:53 PM Hans <<a href="mailto:hans@lambermont.dyndns.org" target="_blank">hans@lambermont.dyndns.org</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">Wolfgang Reissenberger wrote on 20210420:<br>
<br>
> Good point, these message boxes are not a good idea for running KStars in a (more or less) unattended way. <br>
> <br>
> I would even opt for having both, so having the option to avoid message boxes in general plus making all message boxes non-blocking timer-based.<br>
<br>
Yes, both please. And if that is no option then the first, an option to<br>
suppress them all. That is also needed for any future option where ekos would<br>
be fully scriptable from the outside for automation.<br>
<br>
-- Hans<br>
<br>
> > Am 20.04.2021 um 07:37 schrieb Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com" target="_blank">mutlaqja@ikarustech.com</a>>:<br>
> > <br>
> > Hello everyone,<br>
> > <br>
> > What do you guys think about having a global flag that would suppose any KSMessageBox messages? This can be set for example when Ekos scheduler is running, and for any errors that would end up as a popup, this would just block the program.<br>
> > <br>
> > I've actually fixed quite a few of these cases before and redirected the output to the log instead of blocking KSMessage. Please note that we have KSMessageBox class that has pop ups with timeouts (why isn't this a standard in KDE or Qt?). <br>
> > <br>
> > So we have a couple of options:<br>
> > <br>
> > 1. Create a global flag where it suppresses any calls to KSNotication::sorry or KSNotification:error ..etc<br>
> > 2. Convert all existing KSNotification::error..etc to a non-blocking timer-based KSMessageBox?<br>
> > <br>
> > This is of course for the next release of KStars, not 3.5.3 which is already overdue.<br>
> > --<br>
> > Best Regards,<br>
> > Jasem Mutlaq<br>
> > <br>
</blockquote></div>
</blockquote></div>