Qt - top level widget with keyboard and mouse event transparency?
Asked Answered
L

6

45

I want an app's main window to ignore mouse and keyboard events, passing them to applications underneath it in the window manager Z-order.

I see how to make child widgets ignore keyboard or mouse events, but how about the main window?

I'm trying to make a desktop widget that always sits just over the background and is totally invisible to keyboard and mouse events. (Pass through)

Qt::X11BypassWindowManagerHint gets me keyboard pass through (although sadly X11 specific, but fine for now), so how about mouse events?

Is there a OS-agnostic way to be transparent to keyboard events?

EDIT:

The key word here is transparency.

I don't want to EAT mouse and keyboard events, I want the window manager to know I don't want them at all. Those events should be directed to whatever application is under me in the zorder.

For example, I want to be able to click on desktop icons that are covered by my widget and interact with them as if the widget was not there.

Lovesome answered 12/6, 2009 at 14:45 Comment(2)
no idea why someone down voted this... perfectly legitimate question. unfortunately I don't have the answer, but I'm pretty sure it's out there because if I remember correctly KDE has these type of widgets on the desktop and it's based on Qt.Cozmo
Did you ever find the solution for Linux?Lidless
R
13

I found the following solution (tested on Linux, also works on Windows according to @TheSHEEEP):

setWindowFlags(windowFlags() | Qt::WindowTransparentForInput);

It has been added in more recent qt release (i did not find when) see http://doc.qt.io/qt-5/qt.html

Rossuck answered 3/8, 2016 at 19:56 Comment(1)
I just ran into an obscure side-effect of WindowTransparentForInput: if you're also trying to set the WA_TranslucentBackground flag for the window it stops working and the window's background color becomes solid instead. So it appears that in Qt, transparency to user input breaks visual transparency. Nobody would ever run into this unless they were trying to implement a non-rectangular window.Filamentary
C
11

On Windows you can set WS_EX_TRANSPARENT

To do this in Qt use the following code:

Include the header,

#if _WIN32
    #include <windows.h>
#endif

and put the following code into the constructor.

#if _WIN32
    HWND hwnd = (HWND) winId();
    LONG styles = GetWindowLong(hwnd, GWL_EXSTYLE);
    SetWindowLong(hwnd, GWL_EXSTYLE, styles | WS_EX_TRANSPARENT);
#endif
Clarabelle answered 8/2, 2011 at 8:25 Comment(0)
C
7

Maybe what you want is

widget->setAttribute(Qt::WA_TransparentForMouseEvents)

? That's what QRubberBand uses to let it's parent handle the mouse events. As for keyboard events, a QWidget doesn't get any keyboard events unless it has set itself a focusPolicy().

setFocusPolicy( Qt::NoFocus );

should therefore take care of the keyboard events.

Chyme answered 10/7, 2009 at 11:27 Comment(3)
Okay, this is doing exactly what I said I already know how to do. I don't want a widget that lets "it's parent handle the mouse events"... I want the entire APPLICATION to ignore them. I want something to tell the windowing environment (X, WinXP, etc) that a click on my app should just pass to another app sitting under it on the Z-order. That typing on the keyboard should do the same. These solutions are just passing events up from child widgets to the parent. I want events being sent from the parent widget back to the window manager, or most likely just never sent to the app at all.Lovesome
however, this response is useful to someone who might actually want to do what you're talking about. (pass stuff to a client). I did try it, on the off chance that the Qt framework actually recognizes you're trying to ignore events at the parent level and would try to send them back to the window manager (or set some sort of flag in the window manager to bypass)... but as expected it did not work. My app ate the events.Lovesome
Right, sorry. I've since also tried setMask(), which does what you want, but also clips visibility. I'm pretty sure there's no way to do what you want, without falling back to OS-specific hacks. Have you found the functionality you seek in any other application?Chyme
H
1

Use Qt's event filters: they will allow your application to eat whichever events you specify (i.e. keyboard and mouse events) but still process other events such as paint events.

bool FilterObject::eventFilter(QObject* object, QEvent* event)
{
    QKeyEvent* pKeyEvent = qobject_cast<QKeyEvent*>(event);
    QMouseEvent* pMouseEvent = qobject_cast<QMouseEvent*>(event);

    if (pKeyEvent || pMouseEvent)
    {
        // eat all keyboard and mouse events
        return true;
    }

    return FilterObjectParent::eventFilter(object, event);
}
Hiatt answered 18/6, 2009 at 14:8 Comment(0)
E
1

Maybe I'm missing something here, but have you tried subclassing the QMainWindow class and overriding the QWidget::event() method to always return false? If you need to handle some events, you could add that intelligence here as well.

This technique should allow you to inspect the events coming in to the application and ignore them if desired without having to eat them using an event filter.

If this doesn't work you could attempt to redirect the events to the desktop by calling QCoreApplication::notify() and passing the event to the desktop widget obtained by calling QApplication::desktop(). I have no idea if this would work, but it seemed like it might be worth giving a try.

Esma answered 19/6, 2009 at 17:20 Comment(1)
This answer is not very useful if you don't even know if your idea works or not.Deafanddumb
O
0

I think that overriding is supposed to work:

bool YourMainWindow::event( QEvent *event )
{
   event ->accept();
   return true;
}

that's some of what the QWidget class documentation says about event() member function:

This function returns true if the event was recognized, otherwise it returns false. If the recognized event was accepted (see QEvent::accepted), any further processing such as event propagation to the parent widget stops.

Oldtime answered 16/6, 2009 at 18:52 Comment(1)
I tested this. It does not work (QT 5.15.2, Linux, X11).Deafanddumb

© 2022 - 2024 — McMap. All rights reserved.