Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

RootPanel background painter and default sizes #240

Open
begrs opened this issue Mar 23, 2024 · 1 comment
Open

RootPanel background painter and default sizes #240

begrs opened this issue Mar 23, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@begrs
Copy link

begrs commented Mar 23, 2024

Is your feature request related to a problem? Please describe.
It is often very unintuitive how default sizes are applied, or why the setBackgroundPainter works on any panel but the root panel.

Describe the solution you'd like
For the RootPanel -> it is possible to set the background painters by overriding addPainters in the Description. That should not be necessary and simply setting setBackgroundPainter should be enough. Setting a value and than having it overwritten by another code piece is very unintuitive. The default code in description addPainters should, in my opinion, be

if (this.rootPanel!=null && !fullscreen && this.rootPanel.getBackgroundPainter() == null /* having null as the default if not set explicitly*/) {
			this.rootPanel.setBackgroundPainter(BackgroundPainter.VANILLA);
		}

For the default sizes:

  • a lot of Widgets could have reasonable default sizes e.g. a WLabel or WTextField could just calculate the default size based on their text content, or in the case of WTextField their MaxLength (its easy to do, as I am doing that right now with my workaround)
    e.g by using: textRenderer.getWrappedLinesHeight, textRenderer.getWidth(text)
  • currently this would just be overwritten by calling WPlainPanel.add(widget, posX, posY) to be width 18, height 18 when not using the overload add(WWidget w, int x, int y, int width, int height) where you have to do all that calculation manually. This is especially cumbersome to do with split client-server code as you need to implement a facade that fakes the real calculated widths on the server and is implemented with the correct calls on the client.
    Solution: if add(WWidget w, int x, int y) is called on a WPlainPanel, it should check the widget being added for its default/auto size and only if none is specified in the widget itself it would default to 18,18.
    This solution would the current code that I have in at least half.

When on the subject of having a facade to call client code, such as MinecraftClient.getInstance().textrenderer.XXX
it would be really cool to have that built into the LibGui. i.e. the description base class could have methods that delegate the calls to the textrenderer when executed on the client, and return dummy values when called on the server.

I could add a PR for these changes myself, but would appreciate feedback first if this wouldn't break some behaviour with e.g. InventorySlot drawing that I am just not aware of.

@begrs begrs added the enhancement New feature or request label Mar 23, 2024
@Juuxel
Copy link
Member

Juuxel commented Oct 23, 2024

Thanks for the suggestions!

In 12.0.0, you can call setUseDefaultRootBackground(false) to disable the VANILLA background painter.

The default size feature can't really be implemented as the text renderer isn't available on the server. With the way LibGui is designed, it would need that cumbersome "facade that fakes the real calculated widths on the server" you mentioned.

I do think it'd make sense to add non-resizing overloads of the add methods, though.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants