Global flag to suppress popups?

[Hy Murveit]

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?

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.

I do agree that all blocking pop-ups should have a default "lifetime" of no
more than 5 minutes.

On Tue, Apr 20, 2021 at 4:25 AM Jasem Mutlaq <mutlaqja at ikarustech.com>
wrote:

> Great, I've created an issue here:
> https://invent.kde.org/education/kstars/-/issues/84
>
> --
> Best Regards,
> Jasem Mutlaq
>
>
>
> On Tue, Apr 20, 2021 at 1:53 PM Hans <hans at lambermont.dyndns.org> wrote:
>
>> Wolfgang Reissenberger wrote on 20210420:
>>
>> > Good point, these message boxes are not a good idea for running KStars
>> in a (more or less) unattended way.
>> >
>> > 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.
>>
>> Yes, both please. And if that is no option then the first, an option to
>> suppress them all. That is also needed for any future option where ekos
>> would
>> be fully scriptable from the outside for automation.
>>
>> -- Hans
>>
>> > > Am 20.04.2021 um 07:37 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com
>> >:
>> > >
>> > > Hello everyone,
>> > >
>> > > 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.
>> > >
>> > > 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?).
>> > >
>> > > So we have a couple of options:
>> > >
>> > > 1. Create a global flag where it suppresses any calls to
>> KSNotication::sorry or KSNotification:error ..etc
>> > > 2. Convert all existing KSNotification::error..etc to a non-blocking
>> timer-based KSMessageBox?
>> > >
>> > > This is of course for the next release of KStars, not 3.5.3 which is
>> already overdue.
>> > > --
>> > > Best Regards,
>> > > Jasem Mutlaq
>> > >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20210420/da8b9e3b/attachment.htm>