Increase size of download buttons

Adding patch for Increase size of download buttons

RTBC for the merge request. I didn't use the patch; I used the MR's patch file.

Very nice! I like it! Now the buttons will conform to my site's theme!

Personally, I think it'd be nice if the button text could be customized in the view settings, though I don't need to use that.

For some reason it didn't apply when I used 8.x-1.3, but it did apply to dev. They should be equal right now, though...

+1 RTBC for the Gitlab patch "MR !24". It works fine with the dev-version. (Doesn't apply with the latest release 1.4)

I'm not sure if it makes sense to style it as a regular button and to keep it in the feed icon region. Before, it matched the style of other feed icons, now not anymore.

A better solution IMO would be to add a local action (button in de top right region of the screen), but I'm not sure if this is possible in views.

I created a new issue since the scope is way different than this one: #3414095: Add export links as local actions instead of feed icons.

Great idea @DieterHolvoet, I very much agree that the position in the lower left corner is not ideal. Perhaps this issue should even be closed, and further work done in #3414095: Add export links as local actions instead of feed icons?

I think the feasibility of that type of solution should be evaluated. If it's not possible for filters to be taken into account, then having the button at the bottom is preferrable.

Removing the filtering would break backwards compatibility and break the functionality for some users.

@ressa While I do agree with you, we should probably leave it up to the maintainer to decide which solution to go for.

Sure, no problem :) Though, as far as I can tell, no maintainer has yet participated in this issue. It could be changed to Postponed?

This seems like a great change to me, but is a breaking change, so we should bump the version of the module I reckon.

Thanks everyone, fixed in 8.x-2.x.

Attached patch is the backport to 1.x

#22 patch wasn't created with a --binary flag, so it won't apply. This one works.

I lied again. With binary files, the patch appears to only apply when the index matches the point when the patch was created.

So I had a little play with at site of ours...and actually this change made the view buttons look a decent amount worse.

I've had a sort of re-think, but I think I'll continue discussion in #3414095: Add export links as local actions instead of feed icons

It makes the buttons follow the site's theme and adjusts them to be themeable, so you can style them however you want. On my site, it makes the buttons look like literally every other button on the site. I do agree with your post that adding a config option would be a good idea.

@steven jones Can you backport it to 1.x? That, or can you provide a release for 2.x? There isn't a single release for 2.x.

yes i guess this should go to 1.x branch too. There is only CSS change, which is not a breaking changes IMO.

Re-roll of the 8.x-1.x backport (#24) without the binary image deletions, so it applies with Composer.

#23 and #24 delete the PNGs with GIT binary patch hunks. When the module sits inside another git checkout (the usual Composer project), git apply skips the patch and cweagans/composer-patches 1.x falls back to GNU patch, which rejects binary diffs ("git binary diffs are not supported"), so composer install fails. This patch carries only the CSS and template changes. The resulting files are byte-identical to the ones committed to 8.x-2.x (blobs 3266672 and 22d857e); the unused images stay in place.

Applies cleanly to 8.x-1.10, with both git apply -p1 and patch -p1.

AI-Generated: Yes (used Claude Code to re-roll the committed 8.x-2.x change against 8.x-1.10; tested locally with git apply, GNU patch and a rendered export link).