Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

visible status indicator #106

Closed
mhelvens opened this issue May 14, 2015 · 8 comments
Closed

visible status indicator #106

mhelvens opened this issue May 14, 2015 · 8 comments

Comments

@mhelvens
Copy link

I prefer to use my whole screen to view code, and not have any tool/run drawers open. Though even in that state, it would be very useful if a small Wallaby status indicator could be shown somewhere to distinguish between the following states:

  • no failing tests
  • no failing tests + full code coverage
  • failing tests
  • (failing tests + full code coverage?)
  • processing...

I'm thinking of something similar to the inspection indicator that WebStorm already has above the editor scroll bar.

@ArtemGovorov
Copy link
Member

@mhelvens, @maksimr I have been experimenting with various ways to show something in the distraction free/full screen mode. Unfortunately IntelliJ platform doesn't provide any options to just draw something/somewhere in the editor.

However I think I have found something you may like. For now I have hidden it to get some feedback from you before introducing it to all users. Upgrade to the latest 1.0.17 plugin version, press double Shift, type Registry, open the Registry dialog, find the "spy.js.realtime.evaluation" key and turn the value on. Don't worry about the key name, it's from my previous project, I have re-used it to avoid creating new tmp keys for wallaby.

Restart wallaby and try breaking some tests in the distraction free/full screen mode. For now the indicator just reflects two states: any tests are broken/all tests are passing. Let me know what you think.

@mhelvens
Copy link
Author

Very original, and certainly non-intrusive. But I do have the following worries:

  1. You can't have any mouse-over / click actions to get more information.
  2. You've restricted yourself to color to indicate status, so you can't use different degrees of freedom (e.g., little icons) to indicate different dimensions of data (success/fail, code coverage, processing).
  3. I don't feel like I can conclude the 'all OK' status at a glance now. The green color is similar enough to the darker gray of the tabs above it that I need to go look at it deliberately. Logically I should know that if it were red, I would definitely notice. And the plugin must be running, or there wouldn't be all those little indicators in the left gutter. But... it still feels uncomfortable enough to detract from a perfect experience.

Truthfully, I think the best solution would probably be something like this:

wallaby-status

That would require moving the top of the scroll-bar down a bit.

Unfortunately IntelliJ platform options to just draw something/somewhere in the editor.

I don't think I'm parsing this sentence correctly. Perhaps you mean you cannot do the scroll-bar thing?

@ArtemGovorov
Copy link
Member

Unfortunately IntelliJ platform options to just draw something/somewhere in the editor.

Sorry, must have not finished the sentence. I meant to say: unfortunately IntelliJ platform doesn't provide any options to just draw something/somewhere in the editor. I'll have a look if I can move the scroll bar, but not sure it's possible via public APIs.

@mhelvens
Copy link
Author

PS: I'd like to stress the importance of showing the other two types of status: "processing" and "full code coverage".

The former gets rid of a current frustration: not knowing whether the shown results are up-to-date ("The indicator hasn't changed... but maybe it's still busy?"). When I start typing, the indicator should immediately go to "processing", then back to a settled state when Wallaby is done.

The latter is just amazingly useful. And while I do have one library for which I maintain 100% coverage, the minimum coverage to reflect in the indicator should probably be configurable per-project. For example, I also have a larger project where I try not to drop below 80%.

@ArtemGovorov
Copy link
Member

Agreed on the progress indicator.

With the coverage one, I have a couple of questions. I have no doubt it is useful and we need it somewhere and there is a plan to display more detailed coverage report: #38.

I'm wondering though how useful it is in a form of a simple indicator. Because even if you see it indicating not full coverage, you'll still need to open the report to see where exactly the not covered parts are. So my question is - do you really need to always have the coverage level visible to you as you are doing the bulk of your coding? Or would be happy to occasionally check the coverage report?

@mhelvens
Copy link
Author

Yes, I suppose it is only a "would be nice" feature. But still, it would be nice. :-)

Because even if you see it indicating not full coverage, you'll still need to open the report to see where exactly the not covered parts are.

And if I do see it indicating full coverage, then I don't need to. That's the point, really. If I want to maintain a minimum coverage (100% or otherwise), it's reassuring to be constantly aware of the status quo.

I was fiddling with a mockup for that but... I'm not sure. I'm not a UI designer:

wallaby-status-2

@ArtemGovorov
Copy link
Member

Fair enough, I agree. I suppose it's similar to the tests failing indicator - you'll also only need to open the tool window if the indicator red (and there's no immediate visibility of what's broken), otherwise you also don't need to open it.

Thanks for the mockup, looks nice. My main issue for now is finding a way to draw the indicator there.

@ArtemGovorov
Copy link
Member

I have added a new indicator of failing tests in the latest version of the IntelliJ plugin (right top corner). It doesn't yet reflect any coverage metrics (because wallaby currently doesn't calculate any coverage metrics), but we'll revisit it once we implement them in #38.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants