Closed calcitem closed 2 years ago
Yeah it sometimes happens on the first build and I'm aware of the issue and the cause of it...
I introduced this bug
FYI the problem has to do with screenPaddingH
. Its computation can sometimes be negative (if the layout isn't complete yet ...
now asking what exactly was the reason behind this parameter? f I remember correctly you said it was to compensate layout on small devices?
@calcitem ?? could you please tell me the reason you did it this way? I'm planning to utilize the scaffolds AppBar to position our header. Is there anything against this? I'll open a PR for that so you can test it.
The origin source of calcScreenPaddingH
is from:
https://github.com/hezhaoyun/chessroad/blob/0ef84b36fda5545f9e43357beec4754402a6068e/lib/routes/battle-page.dart#L298
The Chinese comment for this function translates to:
Limit the width of the board when the aspect ratio of the screen is less than 16/9
I have directly followed this part of the code and have not yet targeted it for testing.
double get _screenPaddingH {
// when screen's height/width rate is less than 16/9, limit width of board
final windowSize = MediaQuery.of(context).size;
final double height = windowSize.height;
double width = windowSize.width;
// TODO: [Leptopoda] maybe use windowSize.aspectRatio
if (height / width < 16.0 / 9.0) {
width = height * 9 / 16;
return (windowSize.width - width) / 2 - AppTheme.boardMargin;
} else {
return AppTheme.boardScreenPaddingH;
}
}
I used ChessRoad's source code when some of it had not been thoroughly figured out and was just modified from the original code to Mill logic. I had previously contacted the author of ChessRoad, but he seemed to be very busy and could provide very few answers. So we have to do more of our analysis and do more testing later.
Ok, I've rewritten the painters again to make the scaling easier and faster (the above code will probably go away thus fixing this error)
I have a few questions: what exactly should be displayed for the screen reader? There is quite a bit there and I think we could do with less. I guess every point should be annotated. but why is there also text in between the points? Like "no point"
Also what exactly is the reason for LocalDatabaseService.display.boardTop
Why not center it? Or why is the top also applied to the header? Shouldn't the header always stay in the top (like the app bar) and the board be centered (or offset by the value)?
As mentioned in other issues before, the reading content of the existing screen reader is designed and defined by blind friends in Austria and cannot be changed. I will explain the specific reasons in detail in about 6 hours.
The reason why users are provided to configure the height of the board from the top is because different users have different preferences. Some people like to put the board at the bottom for easy tap, but some people think it is not beautiful.
why is there also text in between the points? Like "no point"
I rechecked the records of previous emails with the blind player, and he commented that it would be better to make it an option that some people like and some may not like. I haven't added the option yet and will do so later after completing the infrastructure refactoring.
Here is some feedback from the blind player in an email. https://github.com/calcitem/Sanmill/discussions/457
For your second question, I have added a post on Issue https://github.com/calcitem/Sanmill/issues/296.
It looks like it has been fixed. (Commit 71248fc8)
Close.
why is the top also applied to the header?
We can discuss Issue #296.
Commit 7794889b974b5acdb6fffd05d026755ae90c9c4a
Except when launching app. (Debug)