Minor button styling feedback

[Gert-dev]

The styling has much improved since the headers were added to the tests tree and the classes are collapsed by default (on passing tests contained in it).

The icons also match Atom a lot better now, thanks!

A minor nitpick about the buttons is that they currently still contain custom styling by some sort of white-grey border. The styleguide contains classes for buttons that contain icons, such as the btn class, under the "Icon buttons" heading. These also include hover states and such as styled by the theme. I think using these for the tests panel buttons may further improve the styling.

Apart from that, in the short time this package has been released, it went from a not-so-great look to a pretty awesome look!

I also like how the overview row on the bottom of the tree is now colored according to whether tests passed or not, it really helps by throwing failed tests in your face so you don't miss them.

Finally, I originally mentioned that the percentages in the tree don't take away the focus, but found myself experimenting a bit today with alternative solutions anyway. Alas, I didn't find a better way to display them. I tried:

• Only showing them on hover, but then I tend to ignore them entirely
• Using the same color as the filename, but then they just blend in with everything else and everything becomes a giant blob
• Using a slightly more transparent color, but then they become hard to read
• Using the current color, but making it a bit transparent, which didn't help much
• Making the font smaller and vertically aligning to the top, which helped a little, but didn't solve much of the original problem

I also thought of making them toggleable, but then I think you'd usually just ignore them as well. Besides, there is already the code coverage panel for seeing that. I see PhpStorm also just uses a slightly less apparent color, so perhaps a change isn't necessary.

[twifty]

Applied in 0.0.39

Even using the .btn class, the buttons still require styling. I think this is why I stopped using it the beginning. Each needs a specified width, otherwise it will size according to the icon (inner text), also the :focus style had to be removed otherwise a blue border appears on click. This border is not appropriate for these buttons as it implies keyboard navigation, for which there is none.

Quick note to self, change width to em based rather than px (next patch release).

I also spent quite a bit of time trying the percentage style in the tree. Ideally it would be in a right hand side column with a subtle color which stands out on hover. Very much like the times in the result panel. The problem is, each list item requires a display: inline-flex, with the filename span being wrapped in a div so that it's text can be truncated with ellipses. I could override these styles, but I'm reluctant to do so since 1. Any changes to the tree dom will likely break; 2. It will break any other package which also modifies the tree.

If this package becomes popular, we can request the tree view devs to apply these styles at the source, and to possibly allow inserting an element to this column via their service.

I noticed PhpStorm also shows the stats for files and lines. I decided to ommit these since they look cluttered.

[Gert-dev]

Indeed. If I think of a better way to display it, I'll let you know.

In any case, the button styling now looks a lot better and not out-of-place anymore, thanks!

[twifty]

Well, I can't think of anymore changes/tweaks to make, so I think it's about ready to get a major version. I'll leave it a few weeks though, just in case any bugs pop up.

One change I'm thinking about making is splitting it into two packages. One for the main views, the other for the PHP. I've already separated the logic in order to do this. Then again it might be better to wait if other languages actually show an interest.

[Gert-dev]

Sounds like a plan.

Regarding splitting up the package: this may be a good idea. My experience tells me that people usually don't explicitly ask for it to be split up. I think there are roughly two categories of people here:

• Those that have test runner A and just want to plug it into Atom as easily as possible without having to do all of the base work themselves (think of linter packages which just run tool B and send the data off to the main linter service/package)
• Those that have test runner A and want to plug it into Atom entirely themselves

The second category of people usually already has its mind set on rolling their own from scratch, but they may yet be convinced to use another as a base if it is good.

The first category of people will usually look around for a package with a service, like the one you're thinking of exposing, but tend to just drop the idea unless such a package exists, the documentation is good, and for some reason they have already heard of it (exposure can be a bit of a problem for these Atom packages; it isn't clear what services can be reused unless you already know the relevant packages).

In short: if you don't do it, people probably won't ask for it either. Sooner or later some other package will pop up that does pretty much the same for another test framework such as JUnit, with yet another interface, which may (will probably) not invest as much attention into detail as you already have into yours.

I like the idea of having reusable packages with services, as it provides a consistent interface no matter what language you use, but I don't want to push you either way. You should take into account that you may get more than you bargained for; in other words, prepare for corner cases and highly specific requests related to other test frameworks that don't apply to PHPUnit ;-).