Displaying the image previews

[CodedOre]

While I was about to implement the image preview, I ran into the design issue on how do we want to display them.

The current Cawbird lines up all images in a row and displays them:

While this works and should be easy to implement (thanks to GTK4 offering an auto-scaling Gtk.Picture class), I do think that for more than two the previews become too small.

Both the Twitter and the Mastodon client on the other hand are using a grid and display the image in this, which sometimes require cropping:

I personally would tend to use the grid-method, as while it requires some code to crop the images, it scales better for different sizes and should serve the wanted purpose of being a preview:

But wanted to ask for your opinion first, @IBBoard.

[IBBoard]

I've thought about the grid view for a while, but I never wanted to get into the hassle of scaling it right (especially with three photos). And I thought it might be a pain to position the three images properly as well. If GTK4 has an auto-scaling Picture widget then that'll be great!

The only thing is that I'd want to do as little cropping as possible. We've got the thumbnail size from the JSON, so I wonder whether we can do something to rearrange the images to minimise cropping (e.g. put the tall one in the first slot)… but then maybe people put things in a specific order sometimes, so we'd break that and so we might just have to live with cropping. (We already broke the "trivia quiz with images" pattern where people put the answer in the middle and "right" or "wrong" outside the cropped area, but then Twitter is breaking that as well now by showing full images!)

[CodedOre]

If GTK4 has an auto-scaling Picture widget then that'll be great!

Scaling a Picture can be done by GTK now. Cropping it would still be our task.

We've got the thumbnail size from the JSON.

The problem with the "thumbnail size" though is that the v2 API does not contain it anymore...

We would need to get it from the picture itself.

Also it seems to me that the thumbnail image is cropped to an image (so not the sizes that would be used in Twitters own preview), but need to recheck this...

[IBBoard]

Scaling a Picture can be done by GTK now. Cropping it would still be our task.

Is there not an option like CSS background-size: cover that lets the widget do some kind of auto-cropping? That would have been helpful rather than us (still) doing all of the calculations and having to deal with layout and resizing.

The problem with the "thumbnail size" though is that the v2 API does not contain it anymore...

Really? Well, that seems like a really dumb choice!

https://developer.twitter.com/en/docs/twitter-api/migrate/data-formats/native-enriched-to-v2

Native Enriched format	Twitter v2 format	Required v2 parameters	Type in v2
extended_entities.media.sizes.thumb.w		Not Available
extended_entities.media.sizes.thumb.h		Not Available
extended_entities.media.sizes.thumb.resize		Not Available
extended_entities.media.sizes.large.w	includes.media.height	expansions=attachments.media_keys&media.fields=height
extended_entities.media.sizes.large.h	includes.media.width	expansions=attachments.media_keys&media.fields=width

Yep, looks like Twitter made a dumb choice 😒 Maybe the (cropped) thumbnail is a fixed size and we have to make do with their crop? I've not found it in the docs yet, though.

[CodedOre]

Is there not an option like CSS background-size: cover that lets the widget do some kind of auto-cropping?

I mean GTK's CSS seems to support it, but we'll need to see. Try to look into it tomorrow.

Yep, looks like Twitter made a dumb choice 😒

Probably depends on the person you asking (We've already seen that they probably making it intentionally harder for third-party clients).

Oh, stupid GitHub threading. Wrong text box! The "reply" one is too small and I missed it. Never mind.

Well, with the iOS client it's even worse, so...

[CodedOre]

I may have found my answer to the "how are we doing clipping": Using the new Gtk.ConstraintLayout.

This from another demo I made some time ago where I used it, and I can clip images with it.
Now the main hurdle is to calculate the size of each preview window and position the images accordingly...

[IBBoard]

It would be nice to use as much space as is necessary (so a wide image and a narrow image gives more space to the wide image) but we seem to do even splits at the moment and that's what Twitter does, so I guess the calculation is just height.

Can it be done with a 2x2 grid and row spanning?

[CodedOre]

It would be nice to use as much space as is necessary (so a wide image and a narrow image gives more space to the wide image) but we seem to do even splits at the moment and that's what Twitter does, so I guess the calculation is just height.

I think that's a bit out of scope, it's already complex enough...

Can it be done with a 2x2 grid and row spanning?

That's something I am already doing. The remaining difficulty lies in:

• Demanding more height from GTK (as now it's only as high as a normal Button), where I am yet to fully understand which function to use exactly
  • On that note: Also define a width-to-height ratio that is being used.
• Modifying the constraint so that it positions the image so that it actually clips (instead of trying to be as small as possible).

[IBBoard]

Ah, yes. It's being "helpful" and trying to show the whole image, even if that makes it tiny. Good luck with finding the right setting! 🙂

[CodedOre]

So, it's now included!
Was more complicated than I expected...

It still has some bugs, but I think I am at a point where I leave it for now and revisit the remaining bugs when the rest is done.

[IBBoard]

I think we currently have an effective max size because we don't go beyond 1:1 scale on the thumbnail image. But if the user has a wide window then we should maximise the amount of image shown up to that max thumbnail size.

Personally, I'd rather have space around the images rather than cropping wherever possible (i.e. show a slightly shorter widget with a down-scaled image rather than 1:1 scale with the edges cropped off). But if it was hard to get it to crop working then that might not be possible.

The only other thing is what we do about showing that it's cropped. I know Twitter doesn't do anything, but it's really annoying to look at a thumbnail and go "is it hiding something or isn't it?". I was never entirely happy with the gradient overlay that I used, but didn't have any better ideas. GTK's dashed line to show that there's content scrolled off the page (which they seem to have since removed) wasn't always sufficiently visible.

Also, this probably isn't going to play nicely with IBBoard/cawbird#29 and uncropped images, is it? 😁

[CodedOre]

Personally, I'd rather have space around the images rather than cropping wherever possible (i.e. show a slightly shorter widget with a down-scaled image rather than 1:1 scale with the edges cropped off). But if it was hard to get it to crop working then that might not be possible.

The big issue was to find and understand the mechanism to use. I'm currently simply assigning the picture more space outside the visible widget and move it a bit so it's still centered.

It should be possible to reduce or remove this adaptions when the widget get bigger, which would leave the rest of the work to Gtk.Picture to fit the image inside it.

So: Should be relatively easy, but not something I personally would now prioritize, I already spend too much time on this widget...

The only other thing is what we do about showing that it's cropped. I know Twitter doesn't do anything, but it's really annoying to look at a thumbnail and go "is it hiding something or isn't it?". I was never entirely happy with the gradient overlay that I used, but didn't have any better ideas. GTK's dashed line to show that there's content scrolled off the page (which they seem to have since removed) wasn't always sufficiently visible.

Maybe a striped things similar to what Adwaita does on development header bars could work?

The question would just be which widget should get the style (probably the button I included for selecting the preview).

Also, this probably isn't going to play nicely with IBBoard/cawbird#29 and uncropped images, is it? 😁

Well...

[CodedOre]

Alright, I have implement a custom snapshot to ask for resizes 2 days ago which seems to clear most of the remaining bugs on the preview grid.
The last bug is that a 1x2 cell sometimes clips in the wrong direction due to (I guess) the cell sometimes becoming wider than taller, which results in some sorts of flickering.

For a final design note to be discussed for this widget would be about what when the image is loaded. I think a full progress bar is not neccessary (as the preview images should only be small ones, 200 px in width or similiar), so with the use of some CSS I managed to implement this:

It's not on any branch yet, as I want to discuss first if you think this is sufficient enough (and yes, the full display will get a progress bar).

[IBBoard]

Like you say, thumbnails should be small and load quickly for most people. I'm happy with that as a "loading" animation. Hopefully it's not too complex and slow as CSS, but then it shouldn't be there for long. IIRC the current widget just draws the percentage onto the canvas.

[CodedOre]

Hopefully it's not too complex and slow as CSS.

It is not complex (just a gradient moved from left to right), and with GTK4's hardware acceleration I don't think it should drop the performance significantly.

So, I will apply this to main then.