Automatic movement of toolbox when writing is now not working well

[marc-git]

Hello,

I tried today writing to the far right and found that the toolbox was jumping up and down and making me accidentally change colours. Previously the feature to avoid collisions worked well. It seems to be not the case anymore.

VG,
Marc

[martenrichter]

Hi,
hmm, jumping, do you mean the feature, where the toolbox disappeared at the bottom and reappeared at the top (or the other way round?). Or do you mean just the movement of the toolbox?

The corresponding code was not changed, for 9 months:
https://github.com/fails-components/lectureapp/blame/912c29794792750ca978b5a11e19403399d21840/src/toolbox.jsx#L982

So, my first guess is not a problem in the web app.
Please check on the computer in the lecture hall, what the zoom level of the browser is. (100% should be the right setting).
Also, a wrong dpi setting of the computer (whether full HD or 4 K), can cause problems as it affects the size of the buttons and the toolbox). In the lecture hall, I was teaching this week and last week, I encountered an increased zoom level of the browser, which I changed back. So this would be my first guess, in the case of the dpi setting, it is an issue that probably only the central computer admin for the lecture halls can address. (At TU Berlin avz)

Marten

[marc-git]

Hi, yes I mean that when I was writing near the middle of the right hand side it would change to the top and then again to the bottom, sometimes directly where I was writing so that I would be accidentally selecting different colours.

[martenrichter]

Ok, so the palette was expanded.
I had a similar reported problem with a 4:3 tablet and low resolution and high zoom level. (The app can not get information about the zoom level from the browser).
So please check this, and report back.
Although the only solution would be to close the palette, when writing, which has some impact on handling, if you are trying different colors, so I did not change it.

[marc-git]

Actually the palette was expanding because I was accidentally writing on it. I will check it again on Friday in H104.

[martenrichter]

I have checked in the lecture hall. The DPI setting of Windows is very high, causing abnormal scaled UI control. This has to be fixed by the administrative staff.

However, I think I should check, if I can make FAILs to do correct collision avoidance also for smaller screen sizes (this is effectively the result of the high dpi setting). However, this is risky and needs extensive testing before deployment.

[martenrichter]

It is probably caused by the changed dpi settings.
Until now a safety border for the beaming border was calculated using an absolute offset, I changed the formulat to scale relatively with the size of the toolbox:
23be281
The change is critical and will be deployed first to the experimental branch.