Tooltip window stealing focus

Hi Jules,

On linux, adding a tooltip to one of the texteditor widgets the JuceDemo renders it almost unusable for text input: the tooltip shows up after 2 seconds and steals the focus everytime, it is not possible to type more that 4 or 5 characters before the tooltip shows up. This is something that used to work fine (the focus was not stolen by tooltip windows) in older juce versions (I have a version from April 2010 where it works).

That’s odd, I don’t remember changing anything in there.

Does it make a difference if you modify this clause, in juce_linux_Windowing.cpp, inside handleClientMessageEvent()

[code] else if (atom == Atoms::ProtocolList [Atoms::TAKE_FOCUS])
if ((getStyleFlags() & juce::ComponentPeer::windowIgnoresKeyPresses) == 0)
XWindowAttributes atts;

                ScopedXLock xlock;
                if (clientMsg->window != 0
                     && XGetWindowAttributes (display, clientMsg->window, &atts))
                    if (atts.map_state == IsViewable)
                        XSetInputFocus (display, clientMsg->window, RevertToParent, clientMsg->data.l[1]);


No, it does not change anything :frowning:

There was the override_redirect flag that was used with “alwaysontop” windows in createWindow() , in the old JUCE version that used to work. Adding it again fixes this issue with tooltips, but it has probably been removed for a good reason , I guess.

Hmm, that’s a tricky one. the override_redirect was indeed causing problems with window managers failing to correctly decorate the window. Not sure what to do about that…

Yes there is probably some other property to set to prevent the window manager from transfering the focus to the tooltip window but I can figure what it is. A similar issue probably happens also to popup menus, when one of them is displayed , the parent window loses its “active window” status (the titlebar becomes grayed), this also did not happen with the older juce versions

Yeah, I need to devote a bit more love to the linux version. I’ll take a look when I get chance, but let me know if you come across any clues…

Just to say that I also have this issue, it happens with menus too.

When I click to open a menu, the main window loses focus (my window decoration color gets grey instead of blue).
I am 100% about this - tooltips/menus create a new X11 window, which seems wrong.

I believe this is just a matter of Window flags, but I know nothing about how X11 works… :frowning:

Me neither. In fact, I don’t think anybody does. It’s a pretty dreadful system.

It seems that GTK menus do set the override_redirect flag on their windows, so I’m not sure if it can be avoided for this kind of windows.

As a temporary fix, I’m adding the override_redirect flag in createWindow when the window is created with alwaysontop and windowIsTemporary (in the old version , it was set for all windows with ‘isAlwaysOnTop’):

       // CHANGED
       swa.override_redirect = (getComponent()->isAlwaysOnTop() && (styleFlags & windowIsTemporary)) ? True : False;
        swa.event_mask = getAllEventsMask();

        windowH = XCreateWindow (display, parentToAddTo != 0 ? parentToAddTo : root,
                                 0, 0, 1, 1,
                                 0, depth, InputOutput, visual,
                                 CWBorderPixel | CWColormap | CWBackPixmap | CWEventMask | CWOverrideRedirect /* CHANGED */,

It seems to works fine for both menus and tooltip windows, except when sub-menus are involved, in which case the focus seems to go back and forth between the menu and the main window.

Ok, thanks! I’ll take a look at that today.

I’m jumping in the bandwagon, but did you see my other post about how to do a menu with the new GTK/Gnome (so they are like the other windows, that is a single menu bar on top à la Mac)
You have some documentation in the link inside that post. While you’re at it, it might worth doing it the way Gnome is doing.