[GUI] StructuredTextBlock: multiple colors/styles in one block of text

Feel free to make adjustments to textbook as you see fit. I personally am very open to this PR and feel free to add me on the review for it.

You can also continue the conversation on here and then on GitHub once you have a PR. My personal apprehension to this this might be more of a design question. Does the [{text:“my string”}] feel intuitive? Maybe it totally does! :grinning_face_with_smiling_eyes: Just want to double check this is the best approach. Also I think it would be best to keep everything on the current textblock. If there is a huge overhaul to the internals of it this will require a lot of testing. Plus remember any new changes must maintain backwards compatibility.

@msDestiny14 I prepared the PR here.
This is a PR to iterate over.
Please tell me what do you think about it! :wink:

4 Likes

I added a frame style (e.g. could be used for mardown backtick rendering, or whatever).

5 Likes

The progress made to StructuredTextBlock make it easy to plug in some nice effects with only few lines of codes:
crazy

6 Likes

News:

  • Support for hover effect
  • Support for clickable text part (hyperlink-like)
4 Likes

Dears,
As I am back with just another session of my GUI ‘evaluation’, I was just wondering:
Where do we stand with this project today?

Looking back at it a little, it might have just gone out of scope.

Though, I truly believe that the ability to use simple styling within a textBlock would really improve things and be a fine ‘nice to have’ if not a ‘must have’.

When I say ‘simple’, understand similar to html or just very basic inline css-like. Bold or strong, italic, underline…eventually color… I guess you got my point. Really not much more than that.

And then, in this simple form, (in my opinion only) I would really see it as part of the core features (not as a plugin)

What is your say? @sebavan @Deltakosh (who closed the topic on gh and requested for an extension) @carolhmj (my gui mentor :smiley:)

1 Like

Let me restart the discussion with the team :slight_smile:

Hi,

I’m starting over from scratch as an independent module (following advice from @Deltakosh on the Github PR).

I need to know if GUI’s internal API is stable, because I’m building everything extending the 2D GUI Control class (private methods like _draw(), _applyState(), _processMeasures() and so on…). I would like to avoid too much maintenance every BabylonJS’s major version bump.

Any recommandations ? (@msDestiny14)

The scope of this project will be to provide some advanced widgets for videogame (mostly dialogs and choices, but maybe more).

1 Like

That’s a good question :slight_smile:

Babylon guarantees backwards compatibility on the public API, even between major versions. But we don’t (and can’t really) guarantee back-compat on protected and private methods. These might change, not only between major versions but possibly within a minor or a patch release.
Now, to your direct question - the GUI API (also the internal one) hasn’t been changed in the last few years. it is working, it is quite stable, and apart of a few hiccups along the way it stayed the same since it was created. Will it ever change? not sure. Maybe we will decide to revamp the entire thing for Babylon 8. Probably not :wink:

One positive thing regarding back-compat is that even if we do change the internal API of the GUI package, your extended package will continue working with any version of Babylon core. so if you fork the GUI project and maintain it yourself, you don’t have to worry about changes to the GUI system at all.

Thanks for your reply.

I don’t feel like forking and maintaining my own version of the full 2D GUI lib, in case of trouble I could eventually have my own Control class copy, but for instance let’s say nothing will change anytime soon! :wink: