Mitigate unreadable schedules (difficult to find a good zoom / pinch)

[valerio-bozzolan]

Premise: I love the Giggity app. Thanks for your work 🌈

---

A frequent negative feedback I receive after promoting Giggity, is that it's relatively easy to shoot in your foot and cause an unreadable layout during normal user interaction in the BlockSchedule activity.

For example, it's relatively super-easy to cause this broken layout where the cell width is so low that not even a single word stays in a single line. You cannot even read the times in the headers. Moreover, if cell widths become smaller, texts GROWS :D this may not help in general readability:

https://wikimania.eventyay.com/2024/

Workaround

The user can just use their powerful fingers to find a better zoom with the usual pinch gesture.

Anyway, it's not so obvious: the preview you see during zoom-pinch reflects the future size but it does not really reflect the future font-size, so it's a kind of "try catch" approach, to continue to try different pinches to obtain a readable layout.

Moreover, the user can open their app preferences and set the "small" font size preference.

Actionable Things

Probably we can mitigate the situation by "just" increasing our width/height minimum thresholds.

I think we already have something in place in onResizeEvent():

giggity/app/src/main/java/net/gaast/giggity/BlockSchedule.java

Line 265 in 8eb5c04

HourWidth = Math.max(60, Math.min(HourWidth, 1000));

So probably we could increase that 60 to something bigger:

HourWidth = Math.max(60, ...); 

For example, increasing that 60 to a greater/better value.

That feature was introduced in 2013 (12+ years ago) and probably never touched again (1080194).

Additionally, we should prevent the default font size from being in proportion of the "cell density" but it should probably (also?) consider the "cell width". The relevant code seems here:

giggity/app/src/main/java/net/gaast/giggity/BlockSchedule.java

Line 117 in 8eb5c04

fontSize = (int) (TentHeight / 3.6 / getResources().getDisplayMetrics().density);

Also the above feature was introduced 8+ years ago and never touched again (f852dc5).

Thanks for any feedback or any patch :) Long life to Giggity.

[Wilm0r]

Wow very nicely written bug report, my apologies for such a late response. :(

Indeed I can easily reproduce this and as is typical, I the author know how to fix it and just pinch myself back to safety. But you're right, there should just be restrictions on what width/height ratio it allows.

For sure that code is VERY old indeed, not my favourite part of the code base to work on... (At times I've considered rewriting it without AbsoluteLayout because you're not supposed to use it, but then hey it works fine, bugs like this one aside?)

[valerio-bozzolan]

Yeah "don't rewrite just patch 🎵 " 👍

[Wilm0r]

95f6bb2 should help I hope. Pretty modest change and one can certainly still produce weird results, but I think it'll definitely take more intent than accident now. :)

[valerio-bozzolan]

I will test this at next FOSDEM from F-Droid 😄 thanks again, seems promising