On Linux, window contents are rendered behind a menubar

[notpushkin]

But only if the menubar wasn't defined in the application code. Here's a slightly modified example code I'm running:

import toga

def build(app):
    box = toga.Box()
    button = toga.Button('Hello world', on_press=lambda _: print("hello"))
    box.add(button)
    return box

if __name__ == '__main__':
    app = toga.App('First App', 'org.pybee.sample', startup=build)
    app.main_loop()

Here's how it looks like to me:

Note that the button is behind the menubar (although no menubar was requested in the code). When I click on the menubar (including the Application or Help menu items), the button is being pressed instead.

I've tried this with a few GTK themes, including Arc-OSX-dark, Mint-X, Redmond and Adwaita, and in every case it behaves this way.

[freakboy3742]

Interesting - I take it this is on Fedora or Arch (Something other than Ubuntu)? Ubuntu puts the menu bar on the window, so the geometry adjustment needed to compensate for that isn't needed.

The flaw will be somewhere in container.py, proabably in the do_size_allocate() method - that's where the layout algorithm applies sets widget positions.

[notpushkin]

This is on Linux Mint (which is Ubuntu-based) with XFCE desktop. I can also try some other environments / window managers a bit later this week.

[freakboy3742]

Thanks for the clarification. It's unlikely to be related to Arch per-se - it's just about the "menu inside the window" configuration. If you use a screen-docked menu bar (IIRC that's an option with XFCE) the problem shouldn't exist manifest (if I'm understanding it correctly). Of course, that's not a fix, but it's an explanation of the cause.

[gugadev]

@freakboy3742 This happen in KDE Plasma 5.9.x too (default desktop configuration) in farenheit to celsius demo. The toga-demo pip package render perfectly.

[freakboy3742]

@gugadev Does KDE do "menu in a window" or "menu on the desktop"? (i.e., windows style or mac style menubars for applications)? If it's "menu in a window", then it will be exactly the same cause as under Mint.

[gugadev]

@freakboy3742 Yeah, it have a kind of title bar menu; I understand the problem now. It's curious that this kind of menus affect the layout placement even if is disabled. This is a SO issue?

[freakboy3742]

@gugadev It's almost certainly a case of asking for the wrong geometry - asking for a "relative to the window", rather than an "relative to the available workspace" dimension for the main container of the app. It's almost certainly a simple fix, but haven't had a chance to dig into the details.

[frol]

FYI, I see this issue on my Arch Linux Gnome 3.24 as well.

[friscodelrosario]

On Elementary OS Loki, I don't think the button is rendered at all:

[notpushkin]

@friscodelrosario You can try adding more buttons below. Maybe the button is too small so it is hidden completely behind the menubar?

Also, two close buttons?..

UPD: accidentally mentioned @freakboy3742 instead

[freakboy3742]

Adding more buttons would work - also, try increasing the padding on top of the button. If you have padding of 150, that should confirm whether the problem is the offset, or something else.

[friscodelrosario]

Increasing the margin worked! Here's what I get by clicking that second close button:

[freakboy3742]

Out of interest - what appears on the "help" menu? Because what is being displayed on the extra close menu is what the Help menu should have...

[friscodelrosario]

A grayed-out "Help".

[vangourd]

I'm running Ubuntu-Gnome 17.04 on a Surface Pro 3. I'm also using Gnome-Tweaks to set my HiDpi scaling to 2.0.

Here's my before.

And after with the padding adjustment.

The menu is also showing a grayed out Visit Homepage button.

[Russell-Jones-OxPhys]

On Ubuntu 19.10 Gnomeshell on Wayland:

Setting GDK_BACKEND=wayland with Tutorial 2 means the controls are hidden. They're (partly) visible with padding=50 instead of padding=5. The layout is fine with GDK_BACKEND=x11.

Could there be tests that output images (e.g. gdk_pixbuf_get_from_drawable() and gdk_pixbuf_save()? something equivalent in Cairo?) and compare them with reference images? If not, is there a way to do that? perceptualdiff or similar utility, perhaps?

[freakboy3742]

@Russell-Jones-OxPhys The issue isn't testing (at least, not explicitly) - As the history of this ticket shows, we've had many people report the problem, but I've been unable to replicate it anywhere. I've tried on multiple versions of Linux, and multiple distributions, and can't reproduce it. Having all the testing in the world won't help if we can't work out how to reproduce the problem.

This is the first time that Wayland has been suggested as a possible cause.

The cause of the problem is that something (possibly Wayland) isn't being consistent about reporting where the "top left" corner of the window is; as a result, the window starts laying out widgets "underneath" the toolbar, because the toolbar isn't being included in the geometry that is reported to the app.

[notpushkin]

This is the first time that Wayland has been suggested as a possible cause.

Note that my reproduction back then was on X11. The cause may be something different – or there might be a few things that can go off, but it's certainly not Wayland alone.

I'll try it out once again on my current setup (KDE, Materia Dark theme) and report back tonight.

[freakboy3742]

It was recently suggested on Gitter that a stock Debian install may exhibit this problem.

[freakboy3742]

During the PyCon 2020 virtual sprint, @danyeaw and @eliotb were able to confirm Wayland as at least one way to reproduce this, on both Debian and Ubuntu.

[yozachar]

Increasing the margin worked! Here's what I get by clicking that second close button:

Thanks @friscodelrosario it works on Hera too.

Just curious when will 0.3.0.dev20 release be pushed?

[freakboy3742]

@joe733 If all goes well, we'll release 0.3.0.dev20 this weekend.