Replies: 1 comment 1 reply
-
I hoped I had fixed that one...
Exactly.
Good point! I did not think of that one. I will see to take that info for update.
v5 had the same problem actually. v4 was also impacted but to a lesser extend. And yes the redrawing should ideally not be happening, as you can see, it is a tricky one... |
Beta Was this translation helpful? Give feedback.
-
Lychee version
master (1d7fbf7)
Which PHP version are you using?
PHP 8.3
Detailed description of the problem
During my tests with different layouts, I noticed a few strange results with the formatting of the gallery when using the justified layout. Especially noticeable was a relatively large “gap” on the right side of the gallery. This was even more pronounced when watching the page from a smartphone (with an already narrow display).
Also, the “gap” seems to increase when the gallery is redrawn, like after switching to masonary and back to justified or just selecting an image in the album.
I tried to dig into the code of
resources/js/layouts/useJustify.ts
thinking is should be a simple formatting change, however I came across two problems which seems to cause the issue, that I could not easily fix.1.
Regarding the gap in general:
From what I understand the code in
should check whether the timeline is enabled & visible and reduce the width of each image accordingly to account for the space used up by the timeline. However, in my tests those expressions are always evaluated as true, even if the timeline is disabled for the specific album.
As I test I aggravated the code to
(timelineData.isLeftBorderVisible ? 200 : 0);
and even when the timeline is off, the now very large “reserved” space is still displayed.I could imagine, that some of this is caused by the fact, that
isLeftBorderVisible
if forced-on for non-SE users, howeverisTimeline
should still be false, if the timeline is inactive for the album.2.
Regarding the “changing” of the gap after redraw. (which also happend to other layout then justified if the are pre-selected when first opening the album)
I believe this behavior is caused by the scrollbar on the right side in larger albums. When the album is opened the first time, the calculation is based on the width of the whole browser window, without taking a scroll bar in consideration (is that the reason for the -36 in the code?). However, when the site is redrawn the browser realizes that there’s a scrollbar and
getComputedStyle(baseElem).width
returns a smaller value of only the remaining space, therefore the 36px are accounted for twice.Also this makes it more noticeable on smartphones where there are no scrollbars displayed at all.
I also checked how the old version (v5) has handled that and it think the problem wasn’t present there because it mostly used flex columns which are automatically redrawn whenever the viewport changes. Would it be possible to implement flex columns also in v6. This would also allow an immediate resize of the album when the browser window is changed.
(I hope I am not too much nitpicking here. Those are just the things I noticed when comparing v5 to v6. Regardless these minor things, I wanted to say I am really impressed by the new features and wanted to thank you for the huge efford you put into Lychee).
Steps to reproduce the issue
Diagnostics [REQUIRED]
Browser & System [REQUIRED]
Server:
Ubuntu 22.04 LTS (Linux 6.8.0-48)
php8.3.12
nginx/1.18.0
Client:
Windows 10
Firefox 132.0
Please confirm (incomplete submissions will not be addressed)
Beta Was this translation helpful? Give feedback.
All reactions