Skip to content

Comments

IDE: don't call resize(0, 0) on completion widget#7036

Merged
dyfer merged 2 commits into3.14from
topic/qtresize
Jul 15, 2025
Merged

IDE: don't call resize(0, 0) on completion widget#7036
dyfer merged 2 commits into3.14from
topic/qtresize

Conversation

@dyfer
Copy link
Member

@dyfer dyfer commented Jul 8, 2025

Purpose and Motivation

Fixes #7007, according to a user report.

But... what does it break instead?

This is a somewhat blind attempt at fixing a crash on Wayland with multiple displays (see #7007 for bug description).

I don't know what was the purpose of resize(0, 0) in the first place though. For reference it was introduced in 7f2db98 as part of #1333. On the surface the autocomplete hints still show as they have before this PR, as far as I can tell...

I'd appreciate if others could test to make sure this doesn't break any functionality!

Types of changes

  • Bug fix

To-do list

  • Code is tested
  • All tests are passing
  • Updated documentation
  • This PR is ready for review

@dyfer dyfer added this to 3.14.0 Jul 8, 2025
@capital-G
Copy link
Contributor

capital-G commented Jul 8, 2025

I don't know what was the purpose of resize(0, 0) in the first place though

In case you haven't checked, quoting https://doc.qt.io/qt-6/qwidget.html#size-prop

Note: Setting the size to QSize(0, 0) will cause the widget to not appear on screen. This also applies to windows.

Just tested 3.14-rc1 on fedora w/ wayland and couldn't trigger a crash, but found some weird behavior of the autocompletion box after moving the SC window across two screens

Screenshot From 2025-07-08 21-49-40

I found that when placing the window to a position where the autocomplete box couldn't spawn (due to limited space), it simply wouldn't spawn.

BTW - since bruno is using sway - maybe this is more a problem of sway? Is the compositor having something in its logs?

edit2: Found some more bugs when closing the IDE. I think wayland is not really stable yet b/c I never had such problems when using x11.

Screenshot From 2025-07-08 21-55-21

@dyfer
Copy link
Member Author

dyfer commented Jul 8, 2025

Thanks for testing!

In case you haven't checked, quoting https://doc.qt.io/qt-6/qwidget.html#size-prop

I didn't think to check that, sorry. Thanks for the reference!

So when does this function actually triggers closing the widget? I didn't catch the difference in behavior in this PR.

Just tested 3.14-rc1 on fedora w/ wayland and couldn't trigger a crash,

Did you test with a secondary display?

@capital-G
Copy link
Contributor

Did you test with a secondary display?

Yes, but gnome and not sway.

@elgiano
Copy link
Contributor

elgiano commented Jul 8, 2025

I was on this as well, and I came to the same conclusion :D

So when does this function actually triggers closing the widget? I didn't catch the difference in behavior in this PR.

I don't think resize(0,0) is meant to make the widget disappear: it should make it shrink to the minimum size constraints of its children. Quoting the same doc page above:

The size is adjusted if it lies outside the range defined by minimumSize() and maximumSize().

(I actually tested this on a small reproducer, if the child has a positive size, the parent doesn't resize to 0).

Maybe we should replace it with adjustSize()?

A strange thing I noticed: with resize(0,0) in place, during PopUpWidget::showEvent(QShowEvent*), at the beginning of the function the widget geometry has a non-zero size, and only after calling move() the size becomes 0x0. Seems like a strange delayed update behavior, perhaps because the widget was hidden when resize was called?

(I'm testing on sway, but I don't have a second monitor, so I tested on a virtual one. I think it should be equivalent, but I'm not 100% sure.)

EDIT: @capital-G, I've tried on sway the situations you describe on gnome, and I couldn't make them happen. When there is not enough space, the autocompletion moves so that it can be displayed.


void CompletionMenu::adapt() {
mListView->setFixedWidth(mListView->sizeHintForColumn(0));
resize(0, 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe substitute resize(0,0) with adjustSize()? Not fundamental though: it doesn't make a difference now because adapt()is currently called only before the widget is shown for the first time

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to adjustSize(). Would there be any possible side effects of this? I haven't read through the code closely.

@bgola could you test d3c4e4a on your system?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elgiano do you think we should risk adding this for 3.14.0-rc2 ? From the discussion so far it seems that the original bug only applies to a very specific environment configuration, is hard to reproduce, and I don't have full grasp of what's actually being changed by either removing the resize or changing it to adjustSize.

@dyfer
Copy link
Member Author

dyfer commented Jul 15, 2025

After testing the version with adjustSize() on macOS, Windows, and Linux (Fedora+Gnome+Wayland+2 monitors) me and @capital-G and @Spacechild1 decided to merge this.

@dyfer dyfer merged commit 4a7d10c into 3.14 Jul 15, 2025
47 checks passed
@github-project-automation github-project-automation bot moved this to Done in 3.14.0 Jul 15, 2025
@dyfer dyfer deleted the topic/qtresize branch July 24, 2025 07:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

scide crashes when running on second monitor (3.14-rc1/Linux/Wayland/Sway)

3 participants