Require Qt5 for the upcoming 6.1 release?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Require Qt5 for the upcoming 6.1 release?

John W. Eaton
Administrator
I just wasted WAY more time than I would like to admit debugging a
signal/slot connection because of a stupid ONE-CHARACTER TYPO.  Instead of

   connect (p, SIGNAL (settings_changed (const gui_settings *)),
            this, SLOT (handle_settings (const gui_settings *)));

I wrote

   connect (p, SIGNAL (settings_changed (const gui_ettings *)),
            this, SLOT (handle_settings (const gui_settings *)));

It seems obvious now, but of course there was no warning and I simply
could not spot the error among all the other changes I had made.  Gah.

Can we just please give up on Qt4 already and start using Qt5-style
signal/slot connections that would catch this kind of error at compile time?

We discussed dropping support for Qt4 back in March and June of this
year.  I think most of us agreed that it was a good idea but we haven't
followed through.

If we agree that this is the right move for 6.1, then I'm willing to do
most or all of the work to fix the configure script and start updating
the sources immediately.  If we delay, I think we will have to wait
until after the 6.1 release as this is a fairly big change so deserves
sufficient time for testing.

As a compromise that would allow us to move to the Qt5 way of making
signal/slot connections while still supporting Qt4, I'd be willing to
use a macro like

   OCTAVE_CONNECT (sender_object, sender_class, signal_name, signal_args,
                   receiver_object, receiver_class, slot_name, slot_args);

if it is possible.  This macro would expand to

   connect (sender_object, SIGNAL (signal_name signal_args),
            receiver_object, SLOT (slot_name slot_args));

for Qt4 and

   connect (sender_object, &sender_class::signal_name,
            receiver_object, &receiver_class:slot_name);

for Qt5.  But I don't know whether something like this will work
properly with the moc thing.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Require Qt5 for the upcoming 6.1 release?

Daniel Sebald
On 11/1/19 4:01 PM, John W. Eaton wrote:

> I just wasted WAY more time than I would like to admit debugging a
> signal/slot connection because of a stupid ONE-CHARACTER TYPO.  Instead of
>
>    connect (p, SIGNAL (settings_changed (const gui_settings *)),
>             this, SLOT (handle_settings (const gui_settings *)));
>
> I wrote
>
>    connect (p, SIGNAL (settings_changed (const gui_ettings *)),
>             this, SLOT (handle_settings (const gui_settings *)));
>
> It seems obvious now, but of course there was no warning and I simply
> could not spot the error among all the other changes I had made.  Gah.

That is kind of annoying sometimes.  Launched from the command line Qt
should dump a runtime warning displayed in the console when such a
connection is attempted.  I've never used the QDebug window much, but
the message probably shows up there as well.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Require Qt5 for the upcoming 6.1 release?

mmuetzel
In reply to this post by John W. Eaton
Am 01. November 2019 um 21:01 Uhr schrieb "John W. Eaton":

> I just wasted WAY more time than I would like to admit debugging a
> signal/slot connection because of a stupid ONE-CHARACTER TYPO.  Instead of
>
>    connect (p, SIGNAL (settings_changed (const gui_settings *)),
>             this, SLOT (handle_settings (const gui_settings *)));
>
> I wrote
>
>    connect (p, SIGNAL (settings_changed (const gui_ettings *)),
>             this, SLOT (handle_settings (const gui_settings *)));
>
> It seems obvious now, but of course there was no warning and I simply
> could not spot the error among all the other changes I had made.  Gah.
>
> Can we just please give up on Qt4 already and start using Qt5-style
> signal/slot connections that would catch this kind of error at compile time?
>
> We discussed dropping support for Qt4 back in March and June of this
> year.  I think most of us agreed that it was a good idea but we haven't
> followed through.
>
> If we agree that this is the right move for 6.1, then I'm willing to do
> most or all of the work to fix the configure script and start updating
> the sources immediately.  If we delay, I think we will have to wait
> until after the 6.1 release as this is a fairly big change so deserves
> sufficient time for testing.

I personally wouldn't mind dropping support for Qt5 altogether. IIRC, we
agreed to keep Qt4 supported until it is too much pain to continue doing
so. Maybe we reached the "critical level of pain".

Are there still supported OSs that don't have Qt5?

Markus