Respect tooltip hints / handle tooltips better

[dmb2]

"Yesterday I was updating ebooks in Calibre menus were appearing full screen and the progress dialog would grab focus and pop to the front on every tick. These are the types of issues that caused me to stop using it 4 or 5 years ago so unless you are willing to fix them yourself I wouldn't count on things improving."

• profsnuggles (hn discussion: https://news.ycombinator.com/item?id=8160968)

We really should investigate this. A number of aps I use cause jarring issues when their tool tips are treated as the main window. Some of them have sizing hints that are ignored completely by StumpWM.

[jorams]

Are there any clear examples of this? I installed Calibre, but just clicking around for a bit didn't show anything weird.

[dmb2]

I'll keep an eye out for bad offenders. One that comes to mind (which is a java app) is jaxodraw (http://jaxodraw.sourceforge.net/)

[dmb2]

Another is Vidyo Desktop (http://www.vidyo.com/products/use/)

[jorams]

I tried Jaxodraw (which resulted in #132) but I didn't get anything like tooltips being treated as a normal window. I clicked around for a bit and, aside from what I fixed in #132 I couldn't find any weird behaviour.

I couldn't get Vidyo Desktop to work. (Tried installing from the AUR but it crashed somewhere in Qt)

[dmb2]

Ah,

Specifically if you make a TeX box and mouse over it the resulting
tooltip will appear in the center of the screen and take focus away from
the main window. I'm pretty sure that JaxoDraw expects that tooltip to
appear next to the mouse and leave focus with the main window.

Dave

Joram Schrijver notifications@github.com writes:

I tried Jaxodraw (which resulted in #132) but I didn't get anything
like tooltips being treated as a normal window. I clicked around for a
bit and, aside from what I fixed in #132 I couldn't find any weird
behaviour.

I couldn't get Vidyo Desktop to work. (Tried installing from the AUR
but it crashed somewhere in Qt)

—
Reply to this email directly or view it on GitHub.

[jorams]

Ah, I see what you mean. I believe that might be an error on Jaxodraw's side though. It creates a JWindow that's recognized by StumpWM as a :DIALOG and which has a _NET_WM_WINDOW_TYPE of _NET_WM_WINDOW_TYPE_DIALOG. I don't think dialog windows are supposed to be used as tooltips.

[dmb2]

Ok Cool,

How are you getting this information? I would really like to know so
that I can debug stuff like this as I run into applications that aren't
behaving well.

Dave

Joram Schrijver notifications@github.com writes:

Ah, I see what you mean. I believe that might be an error on Jaxodraw's
side though. It creates a JWindow that's recognized by StumpWM as a :
DIALOG and which has a _NET_WM_WINDOW_TYPE of _
NET_WM_WINDOW_TYPE_DIALOG. I don't think dialog windows are supposed
to be used as tooltips.

—
Reply to this email directly or view it on GitHub.

[jorams]

Well, since the "tooltip" was getting focus I could just use SHOW-WINDOW-PROPERTIES to see that StumpWM thought it was a :DIALOG. I looked through the source and found this, which didn't really tell me much.

StumpWM has a function called XWIN-TYPE which uses

(xlib:atom-name (xlib:get-property win :_NET_WM_WINDOW_TYPE))

to find :_NET_WM_WINDOW_TYPE_DIALOG. This is then turned into :DIALOG by looking it up in +NETWM-WINDOW-TYPES+.

Here's some more information. There's also a window type _NET_WM_WINDOW_TYPE_TOOLTIP, which we currently don't really seem to handle but which would be more appropriate.

[dmb2]

Another awkward situation is when you are working with a program (like libreoffice) and it pops up a dialog box that is awkward.
Try opening libreoffice (any application) and opening the "Tools>Options" dialog, then cycle through the windows with prefix-n, you'll notice that the options dialog isn't redrawn properly when its selected this way. What makes it worse is that the options dialogue steals the focus of the parent window.

Proposed Behavior: Either the options dialog should float above all windows (and ideally really float) or it should float within the parent window and they should cycle as one.

[jorams]

That's a problem I have noticed too. You can "fix" it by calling fclear and then focusing the dialog directly, but that's very far from ideal.

I really like your second proposal of making the dialog cycle with the parent. The problem with making a dialog float above all others is that sometimes you want to keep it open, but not visible. If you switch your frame to a different window, others will be hidden, but that wouldn't work with windows that float above everything.

[dmb2]

Joram Schrijver notifications@github.com writes:

That's a problem I have noticed too. You can "fix" it by calling
fclear and then focusing the dialog directly, but that's very far from
ideal.

I really like your second proposal of making the dialog cycle with the
parent. The problem with making a dialog float above all others is
that sometimes you want to keep it open, but not visible. If you
switch your frame to a different window, others will be hidden, but
that wouldn't work with windows that float above everything.
I have no clue how feasible getting this to work, but floating within
the parent would be really awesome! Especially in a program like
libreoffice where your interactions with dialog boxes cause changes to
the parent window's contents (ie tweaking a graph's settings.)

—
Reply to this email directly or view it on GitHub.

[dmb2]

google-play tooltips down show up correctly

[dmb2]

this problems have been adequately addressed in the latest version. I'm closing this for now.