Bug 497192

Created attachment 176432 [details]
Screenshot

Can reproduce that.

For me only happens on X11.

And there for me only on the second screen, not the first.

This code part induces the problem:

 // Set the menu position
    if (m_pushButton && m_pushButton->isVisible()) {
        /*
         * Get vertical position.
         * NOTE: In KDE Plasma with Wayland, the reference point of the position
         * is the main window, not the desktop. Therefore, if the window is vertically
         * smaller than the menu, it will be positioned on the upper edge of the window.
         */
        int newMenu_y; // New vertical menu position
        if (m_positionY == AlignTop) {
            newMenu_y = m_pushButton->mapToGlobal(QPoint(0, 0)).y() - geometry().height();
            if (newMenu_y < 0) {
                newMenu_y = 0;
            }
        } else {
            newMenu_y = pos().y();
        }

        // Set horizontal position.
        if (m_positionX == AlignRight) {
            // New horizontal menu position
            int newMenu_x = pos().x() - geometry().width() + m_pushButton->geometry().width();
            // Get position of the right edge of the toggle button
            const int buttonPositionRight = m_pushButton->mapToGlobal(QPoint(0, 0)).x() + m_pushButton->geometry().width();
            if (newMenu_x < 0) {
                newMenu_x = 0;
            } else if (newMenu_x + geometry().width() < buttonPositionRight) {
                newMenu_x = buttonPositionRight - geometry().width();
            }
            move(newMenu_x, newMenu_y);
        } else if (m_positionX == AlignLeft) {
            move(m_pushButton->mapToGlobal(QPoint(0, 0)).x(), newMenu_y);
        } else if (m_positionY == AlignTop) {
            // Set vertical position, use the default horizontal position
            move(pos().x(), newMenu_y);
        }
    }

(In reply to Christoph Cullmann from comment #4)
> And there for me only on the second screen, not the first.

Yes, I use X11, and it only happens on the second screen for me too, with the second screen arranged to the right of the primary one.

Can reproduce as well. Debugged this a little bit. 

- reproducible with our minimal example in ktexteditor if the window is not maximized
- The mode menu is lazy init, changing it to init early didn't fix it
- If you look at the cut off menu window, it seems to have a square corner which is weird. 

I think this might be a bug somewhere lower in the stack.

I can indeed only reproduce it if the window is not maximized, and only in KWrite, not Kate. I *think* I've had it occur in Kate (which I use more, and generally with a maximized window), but I'm not sure.

can not reproduce this anymore, can  you?

I can reproduce it in KWrite 25.08.0, non-maximized window, X11, on the right-most screen of two screens (laptop screen on the left, external monitor on the right, the latter one is the primary). I can reproduce it in Kate 25.08.0 too, under the same conditions. It doesn't happen on the screen on the left, or in a maximized window.

Operating System: openSUSE Tumbleweed 20250825
KDE Plasma Version: 6.4.4
KDE Frameworks Version: 6.17.0
Qt Version: 6.9.1
Kernel Version: 6.14.6-1-default (64-bit)
Graphics Platform: X11

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/851

Grósz Dániel - can you try my patch?

Git commit 6c0b8406a90a4bff8d3b9274ffcd939b28335537 by Christoph Cullmann.
Committed on 19/11/2025 at 18:31.
Pushed by cullmann into branch 'master'.

ensure proper size of mode selection 'dialog' on first show

fixes position issues on Wayland, too

avoid to use showEvent, move logic to aboutToShow handler

M  +188  -193  src/mode/katemodemenulist.cpp
M  +0    -6    src/mode/katemodemenulist.h

https://invent.kde.org/frameworks/ktexteditor/-/commit/6c0b8406a90a4bff8d3b9274ffcd939b28335537