TheIDE Screen Position & Mouse Click Handling Are Unusable about ultimatepp

[mirek-fidler]

I have done some fixes in the code, can you please retry with current master or tomorrow's nightly build?

[mirek-fidler]

What is the resolution of your LCDs (from left to right) ?

[BloodyMess]

leftmost is 1080x1920 (oriented vertically/portrait)
middle display is 3840x2160
bottom display is 1920x1080

[mirek-fidler]

Nice. How is 4K vs 2K resolution handled BTW?

(I am not really experienced using multiple LCDs in Linux. I have taken some old LCD from the storage for testing so I am now trying to reproduce your scenario as best as possible).

[BloodyMess]

I've got the latest from master branch building. The window positioning is much better!

The other problems are still there though:

• No window titlebars anywhere
• No way to un-maximize the main window
• The controls not getting mouse-clicks

I'm getting crashes (or maybe unexpected window closes?):

• When I click on the file menu the IDE crashes/closes with no message.
• When I click on a specific spot in the initial dialog, it just crashes/closes with no message.

I'm wondering if they are caused by the same underlying problem as the controls not receiving mouse clicks, and the missing window titlebars. I also note that the mouse cursor changes to the resize arrows at consistent distances from the edges of the windows, and moving the mouse further toward the desktop (as opposed to further into the window) is when/where mouse clicks start getting lost. It's like the system window manager thinks the dialogs and windows are smaller than they are.

I'm attaching a screenshot showing the initial dialog. The spot where I can click to crash/close the dialog is roughly located vertically on the same row for "My Apps" and horizontally slightly to the right of the end of the text "benchmarks".

I'm also attaching screenshots of the messages from the log viewer produced for these same runs:

[BloodyMess]

I'm wondering if they are caused by the same underlying problem as the controls not receiving mouse clicks, and the missing window titlebars. I also note that the mouse cursor changes to the resize arrows at consistent distances from the edges of the windows, and moving the mouse further toward the desktop (as opposed to further into the window) is when/where mouse clicks start getting lost. It's like the system window manager thinks the dialogs and windows are smaller than they are.

I'm pretty certain this is the case, because I've been able to hunt down and click the phantom minimize button and zoom button on the far right of the initial window. So it must be that I was clicking on the phantom close button. For some reason, the window manager must think the window is smaller than it is, so the titlebar and its close, minimize and zoom buttons are all "invisible".

[BloodyMess]

How is 4K vs 2K resolution handled BTW?

What do you mean?

[mirek-fidler]

4K vs 2K:

Well, normally I am running my main 4K display with 200% scaling, which results in superior smooth text rendered. However, your 2nd and 3rd LCDs are not UHD, so they would need something like downscaling from UHD, which is not readily available in my MATE desktop. Anyway, this is now unrelated to the bug, so...

[mirek-fidler]

As for errors, U++ is using GTK as "rendering/window" backend, so those NET_ACTIVE_WINDOW messages are actually sent by GTK (but it is still possible that it is U++ fault, e.g. misusing GTK API somewhere).

Do normal GTK 3 apps work for you?

[BloodyMess]

As for errors, U++ is using GTK as "rendering/window" backend, so those NET_ACTIVE_WINDOW messages are actually sent by GTK (but it is still possible that it is U++ fault, e.g. misusing GTK API somewhere).

Do normal GTK 3 apps work for you?

Yes, they run fine. I remember there was a similar bug in KiCAD a few years back where the windows were being drawn with the outer edge and titlebar offset outward from the correct window size. Same sort of problem, just going in the opposite direction from what U++ is doing.

Here's what it was doing:

[BloodyMess]

I remember there was a similar bug in KiCAD a few years back where the windows were being drawn with the outer edge and titlebar offset outward from the correct window size. Same sort of problem, just going in the opposite direction from what U++ is doing.

Here is a link to the commit in KiCAD that fixed their issue. Maybe it will help you narrow down what's happening in U++ (and what GTK API's are involved).

[mirek-fidler]

Well, installed Elementary 5 in VM, can confirm that U++ works pretty badly there.

Then tried current Elementary 7, all works fine... (minus some small cosmetic issues).

[mirek-fidler]

Fixed some cosmetics in Elementary 7.... mostly wrong color is topmenu items (looks like el team does not care those about menu visuals, which is understandable given their's goal mimicking macos).

That said, it now feels like Elementary 5 has incomplete or buggy window manager, which seems to be fixed in subsequent versions. I am not sure it is worth investing time into workaround for 5 years / 2 versions old distro... (I can be wrong, can be U++ bug or maybe there is a simple workaround, but I do not see any).

[BloodyMess]

Fixed some cosmetics in Elementary 7.... mostly wrong color is topmenu items (looks like el team does not care those about menu visuals, which is understandable given their's goal mimicking macos).

That said, it now feels like Elementary 5 has incomplete or buggy window manager, which seems to be fixed in subsequent versions. I am not sure it is worth investing time into workaround for 5 years / 2 versions old distro... (I can be wrong, can be U++ bug or maybe there is a simple workaround, but I do not see any).

Since the only other time I've seen a program behave this way was when KiCAD had a bug that they fixed fairly quickly, and no other program has this problem, it has to be a bug in U++/TheIDE.

No other program is having this problem. It isn't the OS.