In Android Studio 4, top dropdown menus and context menu covers horizontally across the screen. #321

robinchew · 2021-03-07T16:26:26Z

Here's a video of the behaviour. https://youtu.be/TbYoW7vxvpM

The menus are all anchored at the bottom of the screen.
The menus takes up the whole width of the screen, with all the extra width in black background colour.
The context menu options are still selectable because the menu remains on mouse up.
3b. The top menus are not selectable because the menu disappears on mouse up.
I cannot run xprop on the menu, you can see the output of xprop on the main window in video.
Tried to add to cfg_kludges.lua the following, but has no effect:

defwinprop{ 
    class = "jetbrains-studio", 
    acrobatic = true,
    transient_mode = "current"
}
defwinprop{ 
    class = "sun-awt-X11-XFramePeer", 
    acrobatic = true,
    transient_mode = "current"
}

It makes Android Studio 4 unusable unfortunately.

The text was updated successfully, but these errors were encountered:

wilhelmy · 2021-03-13T14:31:32Z

I'm wondering if it's possible to use xdotool to obtain more information about these transient windows:

#!/usr/bin/env bash

pid=$(pgrep firefox) # insert pid of android studio here
ws=$(xdotool search --pid $pid)
while true; do
    wstmp=$(xdotool search --pid $pid)
    wsnew=$(diff <(echo "$ws") <(echo "$wstmp") | awk '/^>/ {print $2}')
    echo found windows: $wsnew
    for win in $wsnew; do
        xprop -id $win
    done
    ws=$wstmp
    sleep 0.5
done

robinchew · 2021-03-13T19:13:06Z

Hi your script fails because just running xdotool search --pid $pid of android studio will give no outputs, whereas there were outputs if it was a pid of firefox instead.

wilhelmy · 2021-03-13T19:52:48Z

That's odd. Does that mean that Android Studio starts submenus in a different process?
I have no idea how to search for Android Studio windows since I don't use it myself. Feel free to play around with the xdotool arguments, if this doesn't work: xdotool search --onlyvisible '' 2>/dev/null
In theory this should find all visible windows.

#!/usr/bin/env bash

search() {
    xdotool search --onlyvisible '' 2>/dev/null
}
ws=$(search)
while true; do
    wstmp=$(search)
    wsnew=$(diff <(echo "$ws") <(echo "$wstmp") | awk '/^>/ {print $2}')
    echo found windows: $wsnew
    for win in $wsnew; do
        xprop -id $win
    done
    ws=$wstmp
    sleep 0.5
done

It finds some false positives (such as notion's own WGroupWS), but better too many than too few...

robinchew · 2021-03-13T20:11:13Z

Awesome, I've modified your script as such:

#!/usr/bin/env bash

ws=$(xdotool search --onlyvisible --class 'jetbrains-studio')
while true; do
    wstmp=$(xdotool search --onlyvisible --class 'jetbrains-studio')
    wsnew=$(diff <(echo "$ws") <(echo "$wstmp") | awk '/^>/ {print $2}')
    echo found windows: $wsnew
    for win in $wsnew; do
        xprop -id $win
    done
    ws=$wstmp
    sleep 0.5
done

And I caught the following when I open a file menu or context menu.

WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = 
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_NET_WM_STATE(ATOM) = 
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		window id # of group leader: 0x220004e
WM_TRANSIENT_FOR(WINDOW): window id # 0x220004e
_NET_WM_PID(CARDINAL) = 70508
WM_CLIENT_MACHINE(STRING) = "silverstone"
WM_PROTOCOLS(ATOM): protocols  
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x0, 0x0, 0x0, 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 1081, 401
		program specified size: 305 by 434
		window gravity: NorthWest
WM_CLASS(STRING) = "sun-awt-X11-XWindowPeer", "jetbrains-studio"
WM_CLIENT_LEADER(WINDOW): window id # 0x220002f
_NET_WM_NAME(UTF8_STRING) = "win35"
WM_NAME(STRING) = "win35"

wilhelmy · 2021-03-13T20:53:41Z

Just wondering, does it work? When you opened the issue you mentioned class = "sun-awt-X11-XFramePeer", but this one has WM_CLASS(STRING) = "sun-awt-X11-XWindowPeer",

robinchew · 2021-03-13T21:04:17Z

You mean use kludges to fix it? I added the following:

defwinprop{ 
    class = "jetbrains-studio", 
    acrobatic = true,
    transient_mode = "current"
}
defwinprop{ 
    class = "sun-awt-X11-XFramePeer", 
    acrobatic = true,
    transient_mode = "current"
}

defwinprop{
    class = "sun-awt-X11-XWindowPeer",
    acrobatic = true,
    transient_mode = "current"
}

But there has been no change.

wilhelmy · 2021-03-13T21:50:23Z

After inspecting the source, there is a special case for _NET_WM_WINDOW_TYPE_DIALOG in cfg_notion.lua which seemingly defaults to false (at least it's set to false here but I don't remember setting it) and according to the comment might help and is commented out as true. You can inspect with notionflux(1) or the Lua prompt by evaluating print(ioncore.get()["window_dialog_float"]).
Edit: I checked the code, it is initialized to ioncore_g.window_dialog_float=FALSE in C. Firefox's menus are _NET_WM_WINDOW_TYPE_POPUP_MENU. Whether or not globally handling that information is a good idea or should rather be a kludge ...not sure. The mysterious world of X11.

raboof · 2021-03-14T14:09:19Z

The menus are all anchored at the bottom of the screen.
The menus takes up the whole width of the screen, with all the extra width in black background colour.

I can reproduce that

The context menu options are still selectable because the menu remains on mouse up.
3b. The top menus are not selectable because the menu disappears on mouse up.

Interesting, the top menus don't disappear on mouse up for me. But it obviously doesn't work well.

I'm wondering if it's possible to use xdotool to obtain more information about these transient windows

Neat! A trick I sometimes use is to save the output of xwininfo -root -tree and one with sleep 5 && xwininfo -root -tree to catch one with the dialog open, and then compare with vimdiff. This indeed suggests the dialog is ("sun-awt-X11-XWindowPeer" "jetbrains-studio")

AFAIK Android Studio is based in a large part on IntelliJ IDEA, which I use a lot and mostly works fine. For IntelliJ we do have some winprops, but I just tried without them and think they might no longer be relevant.

Looking at the IntelliJ IDEA menu's with xwinprop, however, they are ("jetbrains-idea-ce" "jetbrains-idea-ce") rather than sun-awt-X11-XWindowPeer - so apparently they are different in this regard - even though the winprops look pretty similar:

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		window id # of group leader: 0x2a00042
WM_TRANSIENT_FOR(WINDOW): window id # 0x2a00042
_NET_WM_PID(CARDINAL) = 2521983
WM_CLIENT_MACHINE(STRING) = "rigter"
WM_PROTOCOLS(ATOM): protocols  
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x0, 0x0, 0x0, 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 2272, 893
		program specified size: 607 by 782
		window gravity: NorthWest
WM_CLASS(STRING) = "jetbrains-idea-ce", "jetbrains-idea-ce"
WM_CLIENT_LEADER(WINDOW): window id # 0x2a00023
_NET_WM_NAME(UTF8_STRING) = "win10"
WM_NAME(STRING) = "win10"

wilhelmy · 2021-03-14T15:08:26Z

@raboof window_dialog_float = true in cfg_notion.lua makes no difference?

raboof · 2021-03-14T15:23:46Z

@raboof window_dialog_float = true in cfg_notion.lua makes no difference?

Ha, I didn't get that far into this thread, sorry :).

I can confirm setting window_dialog_float = true makes this work much more like it was intended, though it doesn't seem to work well in multi-monitor configurations...

Whether or not globally handling that information is a good idea or should rather be a kludge ...not sure.

I agree perhaps we should make this overridable at the kludge level... or lobby for android studio to take the same approach as IntelliJ IDEA ;).

robinchew · 2021-03-14T17:07:12Z

I have a 3 monitor setup. Setting the following in ~/.notion/default-session--0/cfg_notion.lua made no difference for me.

ioncore.set{
    window_dialog_float = true,
}

wilhelmy · 2021-03-15T13:17:57Z

FTR,
[16:41] < Robin> Yes notion works fine with android studio 3

robinchew · 2021-03-16T20:07:58Z

Today I noticed my Android Studio 4's menus are all anchored to the top left. I'm assuming it's because of:

-- cfg_notion.lua
ioncore.set{
    window_dialog_float = true,
}

and I don't know why this has happened now instead of 2 days ago when I made the config change. That time I restarted Xorg and notion, and the menus were still taking up the whole width demonstrated in the video.

Although this change is an improvement, it's still a pain. For example clicking on File anchors the menu on the top left, then selecting New anchors the sub menu somewhere to the right. See screenshot

wilhelmy · 2021-03-16T23:07:47Z

@raboof Just wondering, in IntelliJ, are menus _NET_WM_WINDOW_TYPE_DIALOG or _NET_WM_WINDOW_TYPE_POPUP_MENU?

Firefox "Do you want to quit?" dialog has the same type as Android Studio's dropdown menus, just to confirm that this is what a dialog is in usual terms — which indicates to me that Android Studio really seems to be off here:

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG

For illustration, here's some other software and values their dropdown menus have:
Firefox:

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_POPUP_MENU

Gimp:

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DROPDOWN_MENU

GVim:

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_POPUP_MENU

Libreoffice: my script fails to obtain information besides the window id. Oops :)

Qt software: VirtualBox, quasselclient-qt5, OpenSCAD (iirc those were buggy but I can't remember details):

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_NORMAL

Ultimaker Cura (PyQt5) — menu positions here also seem off:

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL

Seems like there is no consensus between toolkits/implementations on this issue, either, and we can't fix every single package that has a different way of rendering popups. Maybe honoring the window position these programs explicitly request through size hints is the way to go? Taking a wild guess here that we don't already, I know very little about how notion handles any of this.

WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 1324, 92
		user specified size: 275 by 190
		window gravity: Static

raboof · 2021-03-17T11:07:42Z

@raboof Just wondering, in IntelliJ, are menus _NET_WM_WINDOW_TYPE_DIALOG or _NET_WM_WINDOW_TYPE_POPUP_MENU?

Just checked and it's really (though indeed oddly) _NET_WM_WINDOW_TYPE_DIALOG

wilhelmy · 2021-03-17T11:32:33Z

dwm seems to deal with it by always setting dialogs floating: https://git.suckless.org/dwm/file/dwm.c.html#l2015
Haven't checked what other tiling WM's do.

robinchew · 2021-03-21T13:01:44Z

So the problem came back again after messing with cfg_kludges.lua. So I don't know what combination of the following will cause what behaviour. But in any case, they are all difficult to work with:

-- cfg_kludges.lua
defwinprop{ 
    class = "jetbrains-studio", 
    acrobatic = true,
    transient_mode = "current"
}
defwinprop{ 
    class = "sun-awt-X11-XFramePeer", 
    acrobatic = true,
    transient_mode = "current"
}
defwinprop{
    class = "sun-awt-X11-XWindowPeer",
    acrobatic = true,
    transient_mode = "current"
}

-- cfg_notion.lua
ioncore.set{
    window_dialog_float = true,
}

lhotari mentioned this issue Jun 18, 2021

Dialogs switch the stack to an incorrect window pop-os/shell#712

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

In Android Studio 4, top dropdown menus and context menu covers horizontally across the screen. #321

In Android Studio 4, top dropdown menus and context menu covers horizontally across the screen. #321

robinchew commented Mar 7, 2021 •

edited

Loading

wilhelmy commented Mar 13, 2021 •

edited

Loading

robinchew commented Mar 13, 2021

wilhelmy commented Mar 13, 2021

robinchew commented Mar 13, 2021

wilhelmy commented Mar 13, 2021

robinchew commented Mar 13, 2021

wilhelmy commented Mar 13, 2021 •

edited

Loading

raboof commented Mar 14, 2021

wilhelmy commented Mar 14, 2021

raboof commented Mar 14, 2021

robinchew commented Mar 14, 2021

wilhelmy commented Mar 15, 2021

robinchew commented Mar 16, 2021

wilhelmy commented Mar 16, 2021 •

edited

Loading

raboof commented Mar 17, 2021

wilhelmy commented Mar 17, 2021

robinchew commented Mar 21, 2021

In Android Studio 4, top dropdown menus and context menu covers horizontally across the screen. #321

In Android Studio 4, top dropdown menus and context menu covers horizontally across the screen. #321

Comments

robinchew commented Mar 7, 2021 • edited Loading

wilhelmy commented Mar 13, 2021 • edited Loading

robinchew commented Mar 13, 2021

wilhelmy commented Mar 13, 2021

robinchew commented Mar 13, 2021

wilhelmy commented Mar 13, 2021

robinchew commented Mar 13, 2021

wilhelmy commented Mar 13, 2021 • edited Loading

raboof commented Mar 14, 2021

wilhelmy commented Mar 14, 2021

raboof commented Mar 14, 2021

robinchew commented Mar 14, 2021

wilhelmy commented Mar 15, 2021

robinchew commented Mar 16, 2021

wilhelmy commented Mar 16, 2021 • edited Loading

raboof commented Mar 17, 2021

wilhelmy commented Mar 17, 2021

robinchew commented Mar 21, 2021

robinchew commented Mar 7, 2021 •

edited

Loading

wilhelmy commented Mar 13, 2021 •

edited

Loading

wilhelmy commented Mar 13, 2021 •

edited

Loading

wilhelmy commented Mar 16, 2021 •

edited

Loading