Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Add an API to get the "min" width of text widgets with wrapping that would be needed to show the text without wrapping #4826

Open
2 tasks done
dweymouth opened this issue May 2, 2024 · 6 comments

Comments

@dweymouth
Copy link
Contributor

Checklist

  • I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
  • This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

Complex positioning with truncating text widgets is very difficult. For example, to place an icon immediately to the right of a line of text that is allowed to truncate if shrunk, with a custom layout similar to HBox that uses the non-wrapping width as the packed width of the text line instead of its minSize - if there is enough room.

Is it possible to construct a solution with the existing API?

Yes, but messily, by making a custom text widget that includes another non-wrapping non-displayed text widget just to figure out the non-wrapping width

Describe the solution you'd like to see.

  • label.NonWrappingWidth() float32
  • hyperlink.NonWrappingWidth() float32
  • richText.NonWrappingWidth() float32
@andydotxyz
Copy link
Member

I'm not sure I agree that the only solution is a messy one... Can't you just get the minimum before turning on wrapping and cache that value?

@dweymouth
Copy link
Contributor Author

What about when you need to update the text while it's already displayed (and update the positioning of an icon you want to position immediately to the right of the text string)?

BTW here is a case internally where it would be useful - https://github.com/fyne-io/fyne/blob/develop/dialog/text.go#L38

@dweymouth
Copy link
Contributor Author

This could also supersede #4648

@andydotxyz
Copy link
Member

What I'm not really getting is why it's not just a right aligned icon with text filling the available space

@dweymouth
Copy link
Contributor Author

dweymouth commented May 5, 2024

As far as I can tell you can't achieve the desired positioning:

  • If you put the label and icon in an HBox, the text will always be forced to its minSize of "..." (using TruncateEllipsis)
  • If you put the label and icon in a border with label as center, and icon as right, then the icon will float all the way to the right with the available space, rather than immediately to the right of the end of the label's text
  • Writing a custom layout, you still need to know how much space the text takes up if the full thing can be displayed in the label (which is different from label MinSize which is only big enough for "...")

@andydotxyz
Copy link
Member

This is a complex topic as discussed on Slack, but I'm not convinced that different types of min are the way to go.
There are many combinations of text wrap/trunc etc that can lead to different space being needed and we should not add APIs for them all. In essence you've got two widgets with different configurations.

It seems that for this specific use-cases you are changing between two so it's likely more than just a custom layout as you say. Perhaps using tricks like for complex tables where we switch between different widgets depending on some factors.

I'd say that there are many ways to approach this:

  • managing multiple widgets similar to how you are doing or by actually switching which is visible in some custom code.
  • introducing a whole preferred size API into Fyne (which creates huge complexity increase to handle such corner cases). As discussed it is not clear if this would be in the layout or widget APIs.
  • Adding a set of new text APIs that allow you to measure text based on certain wrapping characteristics not just the text style as it currently exists.

Overall I think we have a solid underpinning so I'm not sure the Label widget is missing a bunch of APIs, but I think we should be open to exploring this going forward if we can more generally find a solution that helps out with complex layout requirements such as that above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants