Make NT great again, and fuck the rest of the world ?! No way you'll get us waste room between thumbnails.

The solution might be to wrap a thicker linewidget in a smaller CenterContainer sized the size of the original LineWidget.

fuck the rest of the world

first of all, wash that mouth with soap and water, and second. Why couldn't you say any of this before? I specifically pointed it out and you were very nonchalant about it.

I haven’t updated this yet, so be nice and behave @poire-z ;)

(Continuing the above "conversation" here in the main thread to have more room.)

OK, I understand the need for some padding.
And OK, it looks like my yellow highlight is actually the underline for the item above, and its the item below that's draw over it. It is not like it is that small or cut like I thought :)

Anyway, you may have not noticed anything, but I do, just poking stuff here and there, there may need for adjusting things elsewhere.
Here's the current rendering (with underline=1 and padding=0), with some bash windows used as fixed rulers:

Here's with underline=5 and padding=0: notice how the dogear leaks/overflows below:

Here's with underline=1 and padding=5:

So, it seems different padding values do not change the look (just the position of the underline), hopefully because we force our size elsewhere and the added height (by the padding) to the underline container does not interfere with the overall geometry.
But the underline size does: the thumbnail bottom edge is a bit higher up, and the dogear is badly positionned.

Putting now a ruler at the top of the thumbnail (forgot to do that above):
Here's the current rendering (with underline=1 and padding=0):

Here's with underline=5 and padding=0

The top edge of the thumbnail does not move, but its bottom edge does - which means it is smaller with underline=5, but my thumbnail did not get refreched. Which means it is either truncated or resized, which is not good :/
Actually resized, here's with underline_h=25:

May be there is already something fishy with using 1, and it's either not noticable or stuff rounded so there's no thumbnail resize - or may be there is one and we just never noticed it :/ Or we hardcoded a 1 somewhere that we need to update to 5 or using underline_h...

(I'm a bit sick that your PRs take so much time and energy, even the most innofensive looking like this one :( )

At least, the thumbnail gets refreshed when I move back from underline_h=25 to 1, so the code seems to re-use higher sized cached thumbnails - but when the cached one is smaller, it gets refreshed. @hius07 : I think we kept that behaviour last time you revamped that, right?
So there may be no issue, but it needs some checking that everything is right, and if that behaviour (the underline taking room from the thumbnail instead of growing below, expecting there's enough margin to not overlap on the thumbnail below) is the one we want. (And if it is alright NT users will get to reuse higher sized cached thumbnails that will get resized forever.)

(I'm a bit sick that your PRs take so much time and energy, even the most inoffensive looking like this one :( )

cut it out, I know you enjoy every bit of it.

Interesting observations, my experience is rather 'mixed' to describe it somehow. this is as per PR, padding = tiny, underline = non_touch_active

some books appear to have their dog ear sticking out (horizontally paint stroked), whilst others seem unaffected and even some have it higher up (vertically paint stroked).

then again, it appears a lot of this behaviour occurs today with 2024.07...

I think this may work (replace my 5 and 1 with your proper things from size.lua):

--- a/plugins/coverbrowser.koplugin/mosaicmenu.lua
+++ b/plugins/coverbrowser.koplugin/mosaicmenu.lua
@@ -408,19 +408,24 @@ function MosaicMenuItem:init()
     -- for compatibility with keyboard navigation
     -- (which does not seem to work well when multiple pages,
     -- even with classic menu)
-    self.underline_h = 1 -- smaller than default (3), don't waste space
+    local underline_h = 5 -- smaller than default (3), don't waste space
+    local underline_padding = 1
     self._underline_container = UnderlineContainer:new{
         vertical_align = "top",
-        padding = 0,
+        padding = underline_padding,
         dimen = Geom:new{
             x = 0, y = 0,
             w = self.width,
-            h = self.height
+            h = self.height + underline_h + underline_padding,
         },
-        linesize = self.underline_h,
+        linesize = underline_h,
         -- widget : will be filled in self:update()
     }
     self[1] = self._underline_container
+    -- (This MosaicMenuItem will be taller than self.height, but will be put
+    -- in a Container with a fixed height=item_height, so it will overflow it
+    -- on the bottom, in the room made by item_margin=Screen:scaleBySize(10),
+    -- so we should ensure underline_h + underline_padding stays below that.)

     -- Remaining part of initialization is done in update(), because we may
     -- have to do it more than once if item not found in db
@@ -435,7 +440,7 @@ function MosaicMenuItem:update()

     local dimen = Geom:new{
         w = self.width,
-        h = self.height - self.underline_h
+        h = self.height,
     }

     -- We'll draw a border around cover images, it may not be

It would request cached thumbnails 1px taller, so they would get refreshed (which is better than the opposite, requesting smaller ones and getting taller ones that would have to be resized each time).
Is that the case for you too ?

I noticed the dogear sometimes overflowing, even with the previous code - a "Refresh cached book info" somehow solves it (so, the thumbnail we get from the cache may influence the sizing/positionning ?! :/).
So, if it overflows, and if the thumbnail does not refresh, force a "Refresh cached book info" to see if it solves the overflow.

I believe that we could even go with underline_h = 5 (rather, your equivalent from size.lua) even on the emulator (so, no if Device:isCrappy() check needed). With 5, the underilne is somehow centered in the margin (on my emulator), so one could think they apply to the thumbnail below instead of the above - with 4 it's a bit nearer to the thumbnail above).

Anyway, to be tested on your Kindle - and may be on the emulator by people who have higher resolution than my little PC (where scaleBySize does x1).

+    local underline_h = 5 -- smaller than default (3), don't waste space
+    local underline_padding = 1

sorry just to clarify, you want underline_h = 5 for ALL?

-if not Device:isTouchDevice() then
-     -- Make it bigger on non-touch devices, without affecting our sizing
-     -- we'll keep doing with that small self.underline_h
-     self._underline_container.linesize = Size.line.non_touch_active
-end

and that goes too?

Yes to both. With your Size.line.something instead of my 5, and Size.padding.somethingelse isntead of my 1.
Well, I don't know what is really ALL, devices that would see it. On the emulator, we usually don't see it (it's not displayed until we first use an arrow key), and people probably don't use it. But if they do, I don't think they would be bothered by it being thicker.

so, no if Device:isCrappy() check needed)

no, I don't use kobo.

first off, I want to say that pixel peeping like I have with these dog ears, makes me feel like I am doing something hugely inappropriate :)

Is that the case for you too ?

it looks like it, at least all covers seem to be perfectly aligned with their dog ears now.

Anyway, to be tested on your Kindle

looks good so far, will update if anything changes.

speaking of dog ears, could we you add drop shadows to the ones used for bookmarks?

speaking of dog ears, could we you add drop shadows to the ones used for bookmarks?

I'm not a SVG artist, I can't do that.
Also, about our current dogear, it somehow fits the rusticity of our UI: we don't have any 3D/shadow/gray icon, so it would need to stay black & white, with just stroke thickness tricks. But again, I like our current one.

Anyway, if you want to change your dogear icon or test various ones, no need to hack the code, you can just create koreader/icons/ (alongside styletweaks/ and settings/) and put in it a SVG that you name dogear.alpha.png and it will be used instead of our shipped one.
Someone did that in #7514 (comment).