Add Custom-UI-Anchors plugin repository details

[Car-Role]

Provides customizable UI anchors to handle client resizing

[runelite-github-app]

New plugin custom-ui-anchors: https://github.com/Car-Role/Custom-UI-Anchors/tree/b424971dcbae1ba1c6aeb736b40fa9e16b395e4c

[runelite-github-app]

This plugin requires a review from a Plugin Hub maintainer. The reviewer will request any additional changes if needed.

---

Internal use only: Reviewer details Maintainer details

[raiyni]

Reflection is not allowed. Your method for snapping overlays is also highly wrong for being in client tick. I don't think this is possible as a hub plugin.

[riktenx]

https://github.com/runelite/runelite/wiki/Rejected-or-Rolled-Back-Features#forbidden-language-features

if you can't produce a functional version of this without reflection we're not going to be able to accept it

[raiyni]

Your update will not work on overlays being added/removed, nor will it work when you restart the client/plugin. There's also the fact you will still be clashing with the the core overlay renderer between render calls. Like I said previously, I seriously do not think this will work as a hub plugin and would appreciate you discussing it with us.

[Car-Role]

I seriously do not think this will work as a hub plugin and would appreciate you discussing it with us.

Would the RuneLite team consider making the following public/additions to enable this use case properly?

1. OverlayManager.getOverlays() - currently package-private, would need to be public (needed to find and position overlays assigned to anchor regions)
2. OverlayAdded / OverlayRemoved events - new events (needed to capture new overlays when plugins are enabled/disabled)
3. A hook or callback in the render pipeline for custom positioning logic (needed to set overlay positions without racing against the renderer)
4. Anything that I'm missing or done in a better way than what I'm proposing

Basically exposing what I was doing with reflection, but in a safe way.

[raiyni]

We generally don't expose things exclusively for hub plugins that aren't already public. Considering overlay rendering is internally managed, I'm not sure it make sense to expose all overlays nor a hook due to potential issues of having to make sure the hub plugin is absolutely correct. At that point, it should just be managed on core.

[Car-Role]

We generally don't expose things exclusively for hub plugins that aren't already public. Considering overlay rendering is internally managed, I'm not sure it make sense to expose all overlays nor a hook due to potential issues of having to make sure the hub plugin is absolutely correct. At that point, it should just be managed on core.

The only thing that comes to mind that may make it useful to make these public would be plugins that are natural extensions of wanting to manipulate UI. Basically, I can foresee a plugin that saves profiles of different UI setups or community hubs for sharing these UIs presets/templates (kind of like World of Warcraft has)

I would I imagine that next use case wouldn't end up in core functionality, right?

[raiyni]

That would be part of the core profiles, I'd imagine.