i’ve added a feed for automatically built APKs for people who don’t want to use fdroid client: F-Droid APK Feed
Great, thanks! I can upgrade tt-rss via direct link, so I’ll submit a bug to f-droid developers
New beta is up: 1.266 (500).
This adds several options helpful on slow network connections:
- Amount of headlines requested at once is configurable in preferences (was hardcoded at 30 previously)
- Option to show embedded headline images on wifi only
Also, I’ve reordered and simplified descriptions for several preference names.
Feedback is appreciated.
nice to have this configurable. I’d think it might be good to have different values settable for wifi versus mobile. On wifi one usually has a faster/more reliable connection so a high value is good. On mobile the connection is possibly slower/less reliable.
I didn’t notice the other changes you made.
with lazy load it doesn’t really make that much difference anyway, i thought about simply hardcoding a lower value first. adding two settings seems like too much.
i could go for a separate “show images in articles on wifi only” option but i’m not sure if there’s any demand.
i also thought about showing downsampled previews in headlines list but there’s a bunch of issues with that approach; a potential plugin could downsample images linked in API responses as necessary (i.e. if client detects its not on wifi).
coming soon for the next beta (501):
original JPEG vs resized WEBP based on client-specified (in this case, device screen) width:
mfw:images (master):$ ls -l d3e*
-rw-r--r-- 1 www-data www-data 1244675 Aug 12 18:44 d3e3e0026d8c0128fdbcb32720c5ca50458ed577
-rw-r--r-- 1 www-data www-data 56008 Aug 12 19:13 d3e3e0026d8c0128fdbcb32720c5ca50458ed577-576
server plugin is here: Git repository browser (wip)
Nice. For me a missing feature of the android client is the mark read (1 day,1 week, 2 weeks). if you’re tweaking the client adding this might be nice.
some people really don’t bother compressing anything
mfw:tt-rss (master):$ ls -l cache/images/cd8e303b1612325b555354ccfeac01725e582126*
-rw-r--r-- 1 www-data www-data 458618 Aug 14 10:32 cache/images/cd8e303b1612325b555354ccfeac01725e582126
-rw-r--r-- 1 www-data www-data 8970 Aug 14 10:32 cache/images/cd8e303b1612325b555354ccfeac01725e582126-810
the images are almost identical when you look at them, too.
What can you tell me about Uncaught Error: Class 'DiskCache' not found in ?
I can’t find a php extension matching this name, running Debian Stretch with system packages (php 7.0.33) and apache2 (2.4.25).
Which dependency did I forget? The plugin worked till the rework 
, now tt-rss stays a blank page – maybe not optimal for an API-only plugin?
you need to update tt-rss, it’s a new class in core code.
e: i’m mostly done with this particular rework, so things are going to be back to normal today/tomorrow.
Didn’t you post a link to public.php to fetch an image w/ resize parameters? I am looking for it and can’t find your post. If not, could you post one for testing? Very nice feature, thx!
A thought, (re: files in my cache below), maybe the resize plugin could refuse to store minimal compression files and files that are larger? Reason being that they are not worth the time and space. Just a thought.
-rw-r--r-- 1 apache apache 1378 Aug 13 12:04 19d0519baebf26fe4c923d4b349f2ee6728446a2
-rw-r--r-- 1 apache apache 1202 Aug 13 12:04 19d0519baebf26fe4c923d4b349f2ee6728446a2-810
-rw-r--r-- 1 apache apache 0 Aug 13 12:08 19d0519baebf26fe4c923d4b349f2ee6728446a2.flag
…
-rw-r--r-- 1 apache apache 67K Aug 13 14:06 ff0f9da767073f25d22d833f96d889893c2dffc
-rw-r--r-- 1 apache apache 69K Aug 13 14:06 ff0f9da767073f25d22d833f96d889893c2dffc-1440
-rw-r--r-- 1 apache apache 0 Aug 13 13:56 ff0f9da767073f25d22d833f96d889893c2dffc.flag
you can’t use the plugin like that, it’s not an open proxy for obvious reasons.
i suppose it could send the file of lowest size between the original or resized one. the check was there before, i can add it back.
refusing to store already resized file is largely pointless, i think, the work has been done, might as well save it. otherwise we’ll need to do it again.
also, -1440, what kind of device you’re using this on? tablet in landscape? maybe android client should request the size based on min(height,width).
Ok, I just was trying to force a hit on my test environment that isn’t accessible by phone or tablet. I think I got a url from my production access logs that works for me.
But would a .flag file keep it from regenerating the resized image? Either way the diskspace savings wouldn’t be that big; just a thought.
I use an android SG5, so the screen resolution is just … well I’m not sure. Whatever a non-tricked out standard SG5 is. (?) So yeah, a min on height/width would probably work great.
.flag works as a token to allow resize operation because there might not be a cookie when image is requested (by a webview or whatever), actual resized image shouldn’t be regenerated if it already exists.
e: maybe there should be a cap on resized images, something like 1024px looks right.
New BETA: 1.273 (507)
this reworks app theme handling to use Theme.DayNight for faster theme switching and automatic night mode
Installed this morning, works, as far as I can see, same like before.
What do you mean with “automatic”? I’ve got Android 9 on a Samsung phone, there I can activate “Night Mode” which has impact on the theme of the system apps. Are you able to implement this too, or is this API not available for every app?
it should change day/night based on time. unfortunately it’s deprecated - for whatever reason - but it seems to work for me.
i think so. there’s an option to follow device theme. i’ll make a note to add this. my phone doesn’t have device night mode so testing this would be your duty. 
if apps like play store change to dark when you enable dark theme on your device then it’s likely to work. if not then it might only apply to built-in software.
my pleasure 
yes, the play store follows this setting!
Its absolutely not needed, as I am currently just using always night mode of tt-rss, but would be nice to have this option.