using QKeyEvents

[mzimmers]

This problem has to do with setting the button's visibility. If I disable this line in my widget c'tor:

//    ui->pushButtonNics->setVisible(false);

My slot receives the signal, and opens the Nics dialog. After the dialog closes, I set the button to not visible, and the problem recurs.

This problem exists on Windows 10, but not on MacOS. Could it be a bug?

[SGaist]

One silly test, did you try to make the button invisible after calling connect. AFAIK, it should have no relation but it's worth a shot.

[mzimmers]

@SGaist yes, that's how I had it:

Widget::Widget(QWidget *parent) :
    QWidget(parent),
    ui(new Ui::Widget)
{
    ui->setupUi(this);

    // create and connect a KeyPress object.
    m_keyPress = new KeyPress(this);
    connect(m_keyPress, &KeyPress::keyEvent, this, &Widget::handleKeyEvent);
    connect(ui->pushButtonNics, &QPushButton::clicked, this, &Widget::on_pushButtonNics_clicked);
    installEventFilter(m_keyPress);

    // hide the button for the NICs window.
//    ui->pushButtonNics->setVisible(false);
}

[mzimmers]

Update: I submitted a bug report on this; no movement on it yet.

One of my users noticed that the application is now rather CPU-intensive. I verified that it was the key filter by disabling this code in my main widget:

    m_keyPress = new KeyPress(this);
    connect(m_keyPress, &KeyPress::keyEvent, this, &Widget::handleKeyEvent);
    installEventFilter(m_keyPress);

Here's the filter:

bool KeyPress::eventFilter(QObject *obj, QEvent *ev)
{
    Q_UNUSED(obj)

    bool rc = false;
    int key;
    QKeyEvent *qke;
    QEvent::Type type = ev->type();
    if (type == QEvent::ShortcutOverride || type == QEvent::KeyRelease)
    {
        qke = static_cast<QKeyEvent *>(ev);
        key = qke->key();

        // don't bother signaling when the key isn't meaningful to us.
        if (key == 'c' || key == 'C' || key == 'd' || key == 'D')
        {
            emit keyEvent(*ev, key);
        }
        rc = true;
    }
    else
    {
        rc = QObject::eventFilter(obj, ev);
    }
    return rc;
}

I don't see anything really inefficient in my code, but with this enabled, the app uses ~15% of my CPU (on an i3) at idle. Is this to be expected, or am I doing something wrong?

Thanks...

[SGaist]

What type of widgets are you checking ?
You can add an additional check for the obj parameter class to avoid further checks.

[JonB]

@SGaist
If @mzimmers says:

but with this enabled, the app uses ~15% of my CPU (on an i3) at idle

assuming "idle" means not pressing any key, why is this KeyPress::eventFilter() being hit at all, let alone loads of times to use that CPU?

[mzimmers]

@SGaist well, maybe that's my problem -- I'm checking the entire QWidget. (The idea was to reveal hidden buttons when certain keys were pressed.) Given that, I'm not sure there's any meaningful obj parameter checking I can do.

[mzimmers]

@JonB I suspect I'm doing something wrong with my use of the filter, but I'm not sure what to change. I think my filterEvent() is being called for all events, not just for key events.

[JonB]

@mzimmers said in using QKeyEvents:

I think my filterEvent() is being called for all events, not just for key events.

I suspect that is more like it ;-) I would worry about that before anything else :)

Use a debugger or qDebug()s to at least see when your filter is being hit, when the user isn't doing anything?

[mzimmers]

@JonB

    qDebug() << QTime::currentTime().toString();

Got about 6000 hits in ~2 seconds of run time. That explains the CPU usage.

I have no idea what could possibly be generating that many events, though.

[JonB]

@mzimmers
Start by debugging out ev->type()!

[mzimmers]

@JonB the great majority were:

QEvent::UpdateRequest
QEvent::Paint

UPDATE: I managed to eliminate the flood of events, but...that didn't have an effect on my CPU usage. The problem is definitely in the KeyEvent class -- when I comment it out, CPU usage is nil. Anyone have any ideas?

[mzimmers]

Update on this, documented here

The behaviour is different because clicked is emitted on button down on macOS, but on button up on the other two[Windows and Linux]. While the keyboard keys are down, the QPushButton stays down. That's a UX difference caused by how the OS itself behaves.

So, my idea for using the keys goes out the window...I'll think of something else.

The performance issue is a mystery, but I'm going to open a new thread on that. Thanks to everyone for looking.