Hi Gang. I have some experiments happening here: https://playground.babylonjs.com/#4PLF3P#6
First, notice lines 30-31… we’ve told rect1 to adapt to the size of its children… both axes. Doing this, makes the text overflow into the orange thickness border. Although annoying, that is probably the correct functionality for both “adaptations”.
Now activate lines 25-28… let’s get some negative paddings set… and RUN again.
Ahh, much better, eh? Now our text has some room to breathe. But, negative paddings? That doesn’t feel right, does it? We really need the text to have a margin (like HTML boxModels)… but that’s not available, and is a headache for GUI-system programmers, I think.
De-activate lines 25-28, and notice lines 35-47, an experimental function I invented. Activate line 64 to call it. The value in the parameter… is the amount of text pixel-distance FROM the orange border. The rect1.thickness is automatically compensated-for.
Not bad, eh? No user-set negative paddings needed… which I like. I’m a bit worried that it COULD be called BEFORE the GUI system has done its needed measuring, but in this example, it seems to be working fine.
I don’t know if container.expandMargin() would be useful for core, and I cannot foresee/foretell the problems and ramifications of installing it… into the BJS Container-class controls. But, maybe it is a tolerable idea.
Would somecontrol.expandPadding() be useful, too? It would be a way to set 2-4 paddings, all in one call. .expandMargin and .expandPadding might each need TWO parameters, one for left/right and a second for top/bottom. Maybe they would be called setMargin and setPadding, and accept negative numbers (oh no, not THOSE again). Spacing helpers. Gap managers. Especially useful for those who use rounded corners.
When calling methods to set INITIAL GUI values… it is wise to call them from within a adt.onBeforeFirstRender handler, perhaps? (when adt.texture.isReady() goes true) Dumb idea? Calling methods… AFTER adt construction… but BEFORE its first-time render (and never again)… is a weird thing, I suppose. Bad design, perhaps. After our custom-func call, adt would need .isDirty set true, and (likely) need a complete re-measuring of entire flow/layout. Maybe better to consider these user-adjusted spacings… DURING the child-addings… WAY before adt.isReady.
Grids and stackPanels… I don’t think these methods would apply to those. Mostly… just bordered containers, I guess. (my brain is starting to hurt, though) I wonder where would we be… if textblocks allowed thickness… and a background color and border color apart from text color. In many cases, folks ONLY use rect-containers… for bordering and backgrounding textBlocks.
How 'bout a new “impure” combo-control… the rectTextBlock… a rectangle-contained textblock… with lots of spacing and bordering power, AND easy color or TEXTURED backgrounds! Even video backgrounds and RTT’s and other animated stuff! WOW! (drool). ANYwaaaaaaay…
Let’s hear from you guys/gals. Know things about this? See far-reaching impact problems? Do others have concerns about the use of negative paddings? Other work-arounds? Got more test playgrounds? Any other thoughts? (thx)
https://www.babylonjs-playground.com/#PF5SYT#18 Wingy goofing around with a simpleButton atop an imageOnlyButton (which has isHitTestVisible = false). Textured background, with border, with text, good fun. I still need two controls to do it, darn it. Hmm. Gruesome scaling work in lines 29-31 area, too. Image overflows when ADT does vertical resize (like when opening f12 dev tools window). It does MUCH better when lines 29-31 are set like this.