v1.6 Wishlist

[20kdc]

Chances are this wishlist will never be fulfilled, like, ever. But it'd be nice.

Ok, so in order to make this practical, this needs to be grouped into v1.6 stuff and v2.0 stuff

v1.5-maintenance (aka v1.6) stuff

Stuff here will either get in the way of branch maintenance if not applied early or is relatively inconsequential.

UI

• [x] Split UI out of gabien-common (backends still need it for mobile support / file-browser-emulator)
• Destaticification of the UI framework used to be written as a task here but it kind of wasn't worth it (there's not even much left to do). The only thing that was done on this task follows.
• [x] Undo the "elements inherit their theme from their parents" thing because it caused much breakage. This increases staticness but ultimately that was inevitable anyway.
• [x] New layout system; copy the design from projects that were shipped after R48
  • While this would logically be a v2.0 kind of thing, that basically halts user support.
  • Removed the "scrollbar fix" ( https://github.com/20kdc/gabien-common/commit/bcaacc89ae9bb10872dd50ff5ca449d38de0543d ) - it was making layouts worse across the board to make a few menus function well.
  • Avoid Frenyard's "infinite" value. Instead, add "For W get H", "For H get W" operations. getWantedSize becomes non-dynamic with respect to input size, it represents the (SIZE_UNLIMITED, SIZE_UNLIMITED) case. Importantly, this means layout loops should never happen. Relayout calls are descend-only in the Frenyard layout model, with limits declaring the reverse, rather than the iterative constraint solver that GaBIEn used. If a panel's subelements change as a result of something it's doing on layout, it needs to keep that contained.
  • TLDR: Metricking propagates upwards, then relayouting propagates downwards. There are dedicated calls for getting the width for a given height or the height for a given width. Lacking support for either of those calls will simply require the wanted width/height (i.e. the element can't adapt to this axis being changed).
  • Notably an element may shrink or expand without any risk of instability. Consider if an element shrunk vertically when given less horizontal room, grew vertically when given more horizontal room, and was in a vertical scroll container.
    • Old system had a whole weird multi-pass algorithm throwing around stuff I don't even understand anymore to try and resolve these cases internally.
    • New system simply tries without a scrollbar and if that fails tries with a scrollbar (but won't re-attempt without a scrollbar - this logic is all in one function rather than being multi-pass).
    • Old system used an iterative algorithm (aka runLayoutLoop) to adjust the layout until it stabilized (or didn't). The problems this caused with UIScrollLayout were "fixed" with even more custom code: https://github.com/20kdc/gabien-common/blob/bcaacc89ae9bb10872dd50ff5ca449d38de0543d/ui/src/main/java/gabien/ui/UIScrollLayout.java#L60
    • New system is completely top-down. Upward calls only happen in the layout system when the content meaningfully changes.
• [x] While doing the above, actually rearrange packages to be sensible.

Media: Imaging

• [x] WSIImage should be better supported & occupy proper position in image cache
  • Cancelled, kind of. Support for decoding these from input streams was exposed from engine and that's Good Enough.

Media: Audio

• [x] gabien-natives needs to expose licensing data, and R48 needs to be picking that data up
• [x] Ogg Vorbis support (via stb_vorbis with modifications)
• [x] MP3 support (via https://github.com/lieff/minimp3 - this is the only realistic choice)
• [x] Need to stop scanning every audio file that shows up in a Schema page. The lagspikes are real.

General Fixes

• [x] Need better messaging on what RPG::MapInfo.@music_type does. See issue 59
• ZIP file generation (? depends on how things actually go with Android 11)
  • it fine

Little Refactors that can be done before the point of no return where v1.6 and v2.0 completely break code compat.

• "Pizzazz": Theming system should be using PVA
  • This could cause... user-related issues. Cancel it for now. It's not like the effort isn't more effort anyway.
• [x] "Pizzazz": Clean up scrollbars (either PVA or a triangle)
• [x] Icons-As-Abstract-Interface (move icon drawer concept to engine)
  • UIIconButton is a thing. Improvements could be made but this'll definitely work. Main downside is there's no proper provision for light vs. dark theming. If this is pursued should not even make it based on theme (due to mismatch potential); honestly may be best to implement at IIcon draw level. It should be near-impossible to "mix up" the theme.

[20kdc]

So there was a comment that I had here detailing my plan to deal with needing to generate ZIP archives for EasyRPG Player. It turns out that I misinterpreted the blogpost. Sorry for any inconvenience. Still, I will note that the changes in Android 11's (not EasyRPG's, mind) policy pointed out by https://blog.easyrpg.org/2023/04/easyrpg-player-0-8-paralyze/ will be a significant problem for R48 if they are applied to sideloaded applications.

[20kdc]

Alert In Regards To R48 Compatibility With Changes Made To Android (Revised)

I've kind of embarassed myself a bit with a horribly incorrect version of this alert based on misinterpretations, so let's try again.

So if you've read https://blog.easyrpg.org/2023/04/easyrpg-player-0-8-paralyze/ you may have an inkling of what this is all about.

In short, the kinds of applications that are allowed to directly access storage (i.e. `/sdcard/`) are being limited by Play Store policy.

First and foremost. This doesn't affect R48 that much so long as it stays *Play Store* policy. R48 was not and will likely never be distributed via the Play Store.

But if things do go wrong:

The good news is that EasyRPG Player appears to have moved mountains on their end to make sure that should stay working.
The bad news is that moving those mountains is a bit awkward for R48. R48 requiring a low minimum Android version limits access to APIs - including those APIs needed to stay compliant with the requirements of later Android versions.
And R48's state of being an application that works on both desktop and tablet makes this awkward anyway. Keeping this testable is difficult.

If this becomes a real problem, it might still be fixable. But there will be issues, and there may end up being a minimum version bump at the end of this.

Hopefully I got the facts right this time, - 20kdc

[20kdc]

Kicking some "risky" stuff here to v2.0 like the UIFlowLayout stuff. v1.6 ship date should be ~31st Dec.

[20kdc]

Need to finish up testing on Android and deal with the JUnit "Grand" tests, but then it's release time

[20kdc]

:tada: