SlickEdit Product Discussion > SlickEdit®

SlickEdit QT5

<< < (2/2)

patrick:
I use i3 when I'm not doing testing.  So far I haven't hit this.

When it happens, can you go to a terminal and run " xwininfo -root -all > /tmp/log.txt" and post the log.txt file?    My suspicion is the window is there, but isn't mapped, so it's a modal dialog that's invisible.  This was a problem that came up a few years ago, and was fixed for the qt 4 versions, it may be there's another permutation on qt 5 that we've missed.

patrickkox:
Here is the logfile

patrick:
Thanks.  It does look like that old problem we had with some window managers on Qt 4.  I have gotten it to occur a couple of times with the i3 window manager, so I can reproduce it, not as often as I'd like.  The original fix for the Qt4 version is still in place and enabled for the Qt5 version, it's just doesn't seem to be effective for it.

If it's like the original problem, it can happen with any of the dialog boxes we create that are "wizards" that have you fill out information in pages.  But in the past it tended to gravitate to one or two of the dialog boxes as timing was a large component component of getting this to happen.  The only workaround I know isn't great: use xdotool to force the window to map once you've gotten stuck.  ie, run this in a terminal:  xdotool search --name "Create GNU*" windowmap

Thanks for the report.  I'm looking in to it.

Clark:
27.0.0 beta 2 is here:

http://support.slickedit.com/outbound/2700/se_27000002_linux64qt5_beta2.tar.gz

Navigation

[0] Message Index

[*] Previous page

Go to full version