Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Rider window "view mode" issues
Magnus Lidbom
#1 Posted : Friday, November 22, 2024 9:44:46 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 8/30/2012(UTC)
Posts: 38

Thanks: 7 times
Was thanked: 5 time(s) in 5 post(s)
First I'll just say that it great that NCrunch now supports Rider so that I can try Rider out. Since there is no way I'm coding without NCrunch I never even considered Rider before you started supporting it :)

That, said I've run into a few pretty annoying glitches:

When setting an NCrunch tool window to the window view mode they do not behave as expected. I'll describe it for the tests window, but the issue exists for every NCrunch window I believe.

1. If the window is already open, but covered by another window, when I hit the shortcut for it, nothing happens. It remains hidden and I have to go hunting for it with Alt+Tab. The standard behavior in Rider is for the window to be focused and brought to the foreground.

2. When the window is not yet focused, clicking on a button does not have any effect other than focusing the window. Say I click the run all tests button, nothing happens. I have to click it a second time for anything to happen.

3. When the window is open and focused, hitting the shortcut for it does not close it as is the standard for windows in Rider. This means, that for example, I cannot easily and quickly open it to look at the status and then close it again with the shortcut. This issue is there when the window is docked as well, meaning one is forced to do precision work with the mouse to close it and recover one's screen space.
Remco
#2 Posted : Friday, November 22, 2024 10:58:13 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,150

Thanks: 961 times
Was thanked: 1294 time(s) in 1200 post(s)
Thanks for sharing these issues.

To give some context, our tool windows in Rider work very differently to the VS ones. They are basically a thin layer over a JetBrains component that pipes the UI into a background process, so our UI in the tool windows isn't actually properly integrated in the Rider process. This gives certain advantages, like not needing to port our entire UI into JVM. Unfortunately it doesn't offer a lot of flexibility. The annoying issue you've described with needing to click a window before you can interact with a button is one that we don't have the power to solve, though I am hopeful JB will implement something for this in future as they are now using the same tech for parts of Rider.

I'll take a look at the shortcuts to see if there's a way to improve our handling of them.
Magnus Lidbom
#3 Posted : Friday, November 22, 2024 11:20:05 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 8/30/2012(UTC)
Posts: 38

Thanks: 7 times
Was thanked: 5 time(s) in 5 post(s)
Remco;17765 wrote:
They are basically a thin layer over a JetBrains component that pipes the UI into a background process, so our UI in the tool windows isn't actually properly integrated in the Rider process.

Aha! I thought it looked suspiciously similar to the the UI in visual studio. Guess there was a reason :)
I suppose I'll just have to live with that issue. It's, to me, the smallest of these issues.

Quote:
I'll take a look at the shortcuts to see if there's a way to improve our handling of them.

Thanks a bunch. It would make a pretty big difference to the experience of using NCrunch if that frequent annoyance was fixed :)
Magnus Lidbom
#4 Posted : Tuesday, November 26, 2024 9:52:02 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 8/30/2012(UTC)
Posts: 38

Thanks: 7 times
Was thanked: 5 time(s) in 5 post(s)
Three more days of working in Rider and I can tell you that
Quote:
It would make a pretty big difference to the experience of using NCrunch
was an understatement.

Switching back and forth between writing code and looking at the failures in the tests window is my standard workflow, I do it countless times a day, either through the shortcut or through the failure number on the risk/progress bar. It's a conditioned reflex and each time I find it doesn't work....

This really add up over a day of programming, both as an irritating hurdle that I find it hard not to allow myself to be distracted by, and as time wasted searching for the window.

I feel kind of bad reminding you like this, I strongly suspect you are very busy, but I felt a need to try and make it clear why this is not a minor annoyance to me, but rather a quite significant usability issue. If you're already working on it, sorry about wasting your time with this extra comment to read.
Remco
#5 Posted : Friday, November 29, 2024 3:55:38 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,150

Thanks: 961 times
Was thanked: 1294 time(s) in 1200 post(s)
I've looked into the behaviour of shortcut keys to open NCrunch tool windows.

I've now rigged these up so that if the tool window is already visible at the time the shortcut is used, it will be activated instead.

Unfortunately, the result is not what I was hoping for and I don't think it will be of much help to you. Even when activated, full keyboard control is not passed to the contents of the tool window until it is clicked with the mouse. There is no way around this from my side, as we're entirely reliant on the behaviour of the JetBrains wormhole component that allows us to beam the contents of the tool window over from a background .NET process.

I'm hopeful that wormhole will continue to be improved and that JB may yet solve this. It has already come a very long way over the past year.

I'm sorry that at the moment this looks to be the best I can do here. The activation change will be published with the next build.
1 user thanked Remco for this useful post.
Magnus Lidbom on 11/29/2024(UTC)
Magnus Lidbom
#6 Posted : Friday, November 29, 2024 4:13:43 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 8/30/2012(UTC)
Posts: 38

Thanks: 7 times
Was thanked: 5 time(s) in 5 post(s)
Remco;17778 wrote:
Unfortunately, the result is not what I was hoping for and I don't think it will be of much help to you. Even when activated, full keyboard control is not passed to the contents of the tool window until it is clicked with the mouse.

Thank you so much!
Actually, the whole thing about having to click is a smaller problem. The big problem is finding the window quickly when I'm constantly switching back and forth between different windows, and the window has been covered by another window. As long as the shortcut shows the window the major pain point will be gone :D
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.042 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download