Find / Replace window is non-responsive on WSL2

[paulae]

Opening the find / replace window on WSL2 with slickedit results in the following behavior:
1. The window (sometimes) centers properly over the editor window, but frequently displays partially or entirely off the display.
2. The find / replace window is completely non-responsive. It doesn’t respond to keyboard input, window moves with mouse interaction, or even closing
3. Once opened, the zombie find/replace window will be opened on all subsequent invocations of slickedit under wsl2.
4. The zombie window can only be closed by resetting the window layout with “Window / Reset Window Layout”. This is super annoying, because it of course resets all the toolbars and other window layouts as well.
5. I’d also note that the slick-c stack window also behaves similarly – once it’s opened, it always opens on all subsequent invocations, and it will only close with a “reset window layout” menu command.

I've tried this on multiple versions of slickedit (28.0.1.0, 28.0.0.6, 27.0.2.0), and with both the *_linux64 and *_linux64qt5 installers. I've tried fresh installs of slickedit. It repros consistently. I've tried this on WSL2 2.0.9 and WSL2 2.1.5. Ubuntu 23.04 and 22.04. I've tried this on two different systems.

Not being able to access find / replace is a serious problem. Not being able to close windows that persist even after the app is closed / OS is restarted is also pretty serious.

[Clark]

WSL can't be supported by SlickEdit right now. Could be because SlickEdit uses Qt.

DO NOT run SlickEdit on WSL

[paulae]

OK, that works to close the window, thanks.
It's unfortunate that SlickEdit doesn't support WSL. Is this a thing you plan to look into? (Presuming it's not a WSL or WSLg bug - there are plenty of those.)
I work on drivers for both Windows and WSL. :/ They are large, complex, and it's quite tedious to setup project environments for them in multiple IDEs, so having SE available in both windows and wsl is pretty necessary.

[pbrightly]

I live & breath in WSL bash. But I use slickedit on the Windows side.  Share file systems. So .. edit code in Windows and run code, side-by-side on WSL.  A very happy environment for me.

[paulae]

I live & breath in WSL bash. But I use slickedit on the Windows side.  Share file systems. So .. edit code in Windows and run code, side-by-side on WSL.  A very happy environment for me.

Thanks. I'd be interested in hearing about the types of projects on which you use this.

When applicable, I do this too. This works great when I'm using msbuild and msbuild invokes the compiler in wsl. For projects that are created in Visual Studio this is really easy to do. The projects so generated also work well in SlickEdit from windows.

I've not found it to be as simple with large linux buidls. I prefer to build launching the build configuration I'm interested in from an IDE, as the commandlines for some of our builds are quite lengthy, and there are hundreds of configurations. (This is a large set of projects.) It's easy to get a build option wrong. The builds take a while.

These larger linux builds require chroot, and invoke gmake, and some custom hacks, I mean tooling. I'm not sure I can make these work under MSBuild with it ssh'ing into WSL2. Depending on how you set it up, msbuild sometimes feels it needs to rsync things, and that would be unpleasant on this project, as it's quite large. I guess I could try this, although I expect file searches from windows -> wsl2 fs would probably be not especially pleasant. This is a LOT of source.

IDK, I guess I could try to see if I can make MSBuild invoke the build - but I have a sinking suspicion it'll choke and die on the chroots invoked by the build. But I haven't tried it myself to know for sure.

I am reasonably certain I could make all of this work from windows using VSCode -> WSL2. The thought of moving my SE project files over to VSCode makes me want to cry, however. If I have to do that to operate in WSL, I'll likely just switch to VSCode for everything, although I don't like it very much. It's too difficult to maintain the project files for all of this across multiple IDEs and I expect I'd hate that more than I hate VSCode. If MSBuild can successfully build these projects under WSL, then Visual Studio would be a reasonable choice too - and somewhat easier since we have tools to automatically create and update VS projects, presuming I can convince it not to rsync the world constantly. I don't love VS as an editor, however.

[paulae]

As a workaround for anyone else who might encounter this issue, choosing the find / replace window as a docked window, rather than a floating window, avoids the issue. It appears to be an issue with floating windows. Some floating windows will hang, others (like Project Properties) work fine. Anyway, I just dock the find / replace window on the left side of the editor window. Not ideal, but it'll do.

[hs2]

It would be great if SE could be run natively in WSL2. Soon I’ve to cope with this dev. environment, too.
(I afraid I also need a dual OS license then ? I’ll stick to Windows as dev. host on the same node/PC for a number of other projects..)
I found accessing the exported WSL2 shares is very, very slow. With larger projects I think this will be an issue. I’d also like to (gdb) debug the built remote Linux targets with SE. However, the latter is not a must.
The alternative is using CLion or VSCode in a similar way as paulae but I really don’t want that.
@Clark I hope you find the time to have look at the hopefully few issues to seamlessly run SE in WSL2

[pbrightly]

On my current project, I don't have any big local builds.  I'm using python, bash, ansible and terraform mostly.  Being my first love, SE is also where I keep multiple notes files, do all my prototyping, note taking,.. just any general editing.  I write a fair amount of code in it as well. 

Though Ubuntu is my command line environment everywhere, including windows (WSL), I like Windows as my UI for everything.  I see nothing useful about running SE in WSL.  What would be awesome, is, if SE would support  running my programs/terminal in WSL "just like VSCode does".  Windows UI.  WSL dev env.  It's what I do.  I'm not a fan of mac.  I recently gave back my macbook pro.  Meh.

So I've prototyped that with wonky results (see my old posts).  It worked, but were quirks and problems.  I've more or less given up on it for now, but might revisit.  I don't have anything on this project to build, so I'm not too motivated.

[hs2]

The thing is that searching/code tagging on larger code bases via WSL2 exported shares/filesystems might be pretty laggy.
Along with the problems invoking 'remote' build cmds through ssh or whatever and make use of build error parsing/source lookup and as mentioned preferably also using SE for gdb-based (remote) debugging of embedded Linux targets.
I also prefer Windows as self-hosted development platform, but there is a strong trend using containerized build environments on (virtual) Linux machines.
Just for completeness..

[pbrightly]

Ah. Yeah, the performance thing was a problem for me.  And quirky. I'm still on WSL1 so I'm sharing a real file system between Windows UI & Ubuntu environment.  I want to go to WSL2, but that's held me back.