-
Notifications
You must be signed in to change notification settings - Fork 23
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
Project pages get 50% bottom padding #50
Project pages get 50% bottom padding #50
Conversation
Currently playtesting it. |
This PR 100% implements what was written in the issue, however it feels weird to me (I normally have YAFC running fullscreen on my second monitor, which is rotated to portrait mode). Especially noteworthy:
It might be worth investigating whether a fixed-height pseudo line at the bottom would work better. Allowing to scroll past the bottom line, but not half a screen |
The current summaries are to be replaced by #38 in the next release. Does that resolve this particular point? |
Your usecase provides a counterexample to my issue because if people scroll down to the full stop, it indeed can be inconvenient to have half a screen of empty space when it's not intended. Therefore, I agree with your option:
I'll update the issue. |
Is this asymmetry a bother? I had no problem with the top row being always on top and unscrollable higher. |
Can I somehow answer in-line to your many comments? I'm such a github noob. I'm answering them here all at once, because they are related. Yes, the production summaries are a feature in preview and are about to be replaced, so it's not critical. Just felt weird to me, and I was asking myself whether one could want extra scrolling at the top when there is no header, that's all. Don't take this seriously, I believe extra scrolling at the top is bad, just had wild thoughts. Overall I think the fixed (small) extra-scroll is better. I very often scroll by letting the mouse wheel spin for a few seconds (yes, very large sheets). Having to scroll up half a screen afterwards is a nuisance that should be avoided. And it would make the current production summaries look less weird, too. |
You mean the quoting like I did above this sentence? I did it by copying the part and adding |
what is the expected behavior of using home/end key? currently the end key jumps to the very bottom, leaving the empty space. is it better to jump to whatever fills the screen? |
I don't know. Maybe the hotkeys are documented somewhere. We'll need to check. |
No that is only possible in a thread/comment on code reviews not with generic comments. Quoting the line you are replying to, as @have-fun-was-taken showed, is the next best (only) way to have some form of structured responses/discussions. |
1259fd9
to
327cbbc
Compare
Would a fixed numeric constant be sufficient or should it be based on some other geometry? Right now, it seems to be very convoluted to get something like a row height. |
I think yes. Something around 30-100 pixels at the bottom. Something that looks like the end of the list. |
…bottom padding to enable scrolling past the last row The base class Scrollable is used in different places (e.g. project pages, item explorer). To ensure that only those subclasses that need vertical bottom padding the padding factor has a default value of 0%. Project pages switch that to 50% to enable scrolling past the last row. Closes shpaass#14
On large screens the 50% of height tend to become really high so that the padding is much more than necessary. Padding by a fixed pixel amount makes it usable on screens of different sizes.
844276c
to
b4b39bd
Compare
Project pages (e.g. production tables, production summaries) get 50% bottom padding to enable scrolling past the last row
The base class Scrollable is used in different places (e.g. project pages, item explorer). To ensure that only those subclasses that need vertical bottom padding the padding factor has a default value of 0%. Project pages switch that to 50% to enable scrolling past the last row.
Closes #14