Dos normalization menu even when normalization is not possible

@himanel1 @ndaelman I realized the kebab menu in the DOS always appears and let user click on "Normalize intensities", independently of whether the normalization factor was extracted by the DosNormalizer or not.

Could this be rendered or not depending on that condition? Otherwise is confusing that the units on the DOS axis change from "states / eV" to "1 / eV" but nothing happens.

added UX bug gui labels

Thx for pointing this out! Since I implemented this feature in the 1st place, I can see to fix it (after holidays, so next week Tuesday). Feel free to assign to me.

assigned to @ndaelman

added Area C label

Another note for this (for you to have in mind): when clicking on Normalize intensities, the Y range in the DOS is reset, while the one at the BS is not. This happens only until the plot is clicked or moved or zoomed.

simplescreenrecorder-2023-08-23_12.15.24.mp4

Thx for pointing this out. It's because the Band structure only syncs when one of both windows is scrolled or zoomed. So, I just have to extend the button to Band structure.

The only important point is whether we still want them interconnected. Else, decoupling will be faster.

So, I have 2 options here:

1. I read in the normalization_factor from DosValues and apply it to the BandStructure as well.
2. I copy the axis from the DOS.

While option 1 would be simpler for separating both cards, it is counterintuitive to read the normalization_value from the DOS for the band structure. In that case, it would be better to store the same normalization_factor in the band structure too, or better still, move it up. Same story as always, this would be a 2-step update (with the reprocessing in between).

Atm, my preference is with option 2, since both elements are linked in multiple ways. If we ever want to go with option 1, I could already move up the normalization_factor and write to both places. @pizarroj @himanel1 opinions?

removed bug label

added feature label

Could this be rendered or not depending on that condition?

Just pushed a solution. Note that this check will become superfluous in the near future, when all DOS data is reprocessed. We could see to remove it then.

That leads me to a simple problem: how to test that it works before merging? Every upload I generate, will have the normalization data. I guess one option would be to generate a GUI test that forcibly writes DOS data without normalization and test that scenario, but maybe that's overkill? @himanel1 what do you think?

You can create a very simple GUI test for the component that simply checks whether the button is disabled or not depending on what data is given as props. You don't need any real archives for this: just use dummy data.

I can also add it if you want.

You don't need any real archives for this: just use dummy data.

Makes sense. Thx for pointing this out.

I can also add it if you want.

@himanel1 Do you have an example of a test that uses dummy data? I think I can add it myself then.

You just give the data as a javascript object to the component. So something like this in DOS.spec.js:

renderNoAPI(<DOS data={[{energies: [...], densitites: [...], normalization_factors: undefined}]} />)
<find menu element>
<click on menu>
<assert that normalization option is disabled>

It might not be trivial to find the menu button, though. It has no text, only an icon. You may need a test id.

mentioned in merge request !1459 (merged)

closed with merge request !1459 (merged)

mentioned in commit 68dc879e