Hype GridBuilder (Alpha, Proof Of Concept)

Quick Summary (so far)
This extension aims at providing a proportional scaling grid layout and more if we remove the current brick wall we are up against. See below…



0.8 (Alpha) Initial release under MIT-license

Bugs to overcome for this project to go forward

The main reason was not to position some elements. This might be nice for galleries spreads but to position group containers inside the grid (first order). This would be the actual power of this. The big problem is that children of said first order groups don’t respect the width updates and hence don’t act on their pinning and scaling. This only gets triggered if the container is also pinned/stretched by Hype. I hope this will be fixed as I think this limits the layout engine. If a container containing pinned elements is set with setElementProperty the layout should still be respected. Any thought or hints, anybody?


The flexible layout seams to be implemented in a recursive way. So it’s walking the Hype/DOM tree (updateFrame) and chokes on nodes that break a constant chain of flexible nodes cutting of branches with “gaps” to update. If this assessment is right then this might be a performance consideration rather then a simple oversight. If changing this to always walk the full tree isn’t viable (from a user perspective this would be great, though) on could consider walking the update tree once and having all loose ends in a lookup so the tree walk can be more performant (with multiple entry points). Another option (less preferable, but safer on backwards compatibility) would be a settings on the flexibility panel declaring the element user managed. This would allow the user based updates to position, width and height and still be considered part of the current recursive tree walk for the flexible layout engine. Looking forward to an update to this…

Hi Max!

What are the advantages of GridBuilder compared to a set-up like the “Fluid Columns Kit” as available on HypeDocks.


The advantage is that you have a truly proportional scaling container grid. So in that capacity no more mind bend on groups living in groups, living in groups to archive a only slightly complex grid. Just position them like you want build highly complex grids on the first order under the grid node and there you go. But until the layout crawler is fixed there is no way the true potential of this can be unlocked: flexible groups managed by the grid.

1 Like

You can build something like this without going crazy (see the simple depths structure) …

Just an example, not that any sane designer needs that pattern :wink: … also overlapping is possible and much more like fixed width gaps etc. (in 1.0) if the bug is overcome.

Then there is the issue with the layout engine “bug”. Since I am aware of it, I see all the lost potential there. Like user managed containers that scale their flexible content based their width / height or maybe even flexible scaling symbols.

kind of a hack could be to set ‘data-grid’ for nested groups too …

True, great idea! Nesting hasn’t been tested (by me yet) but might just work already. I was just hoping to interact with the regular already familiar flexible layout. But that solves it partially (no alignment etc.) if you stay in one realm. Better even would be to benefit from the best of each world.

1 Like

Thank You for clarifying!

It sounds like you might have a flexible layout implementation question for this?

I’m a little uncertain on the aims of this project - would you mind elaborating on what you are trying to accomplish (general overview and any important details much appreciated) and where Hype’s Flexible Layout is getting in the way? I’m happy to help :slight_smile:.

The question is up there already. Will the flexible layout be “fixed” in a way so we can use them on groups with parents that are not a flexible layouts?

The flexible layout system isn’t a truly proportional scaling grid. This project tries offering possibilities to build these kind of grids. The current flexible grid has it’s upsides but the pinning doesn’t allow for complex grid building without insane deep nesting.

Then hit me up about the recursive “(_)updateFrame” and ways this could be fixed. I think once that is fixed flexible layout symbols could also work.

If the parent does not change width or height then there’s no changes that would ever be needed for children. I’m guessing that your problem is that you are changing the width of a group element, and want the children to adapt?

For each element there’s a “base width” (what is specified in Hype) and a “flexible width” which represents a current value from being scaled. The base divided by flexible is used for calculating how to scale and position children. It sounds like what you want is to be able to change the flexible width and not the base width. The API only allows changing the base width. While you could change the DOM’s width (used in calculations), this will get overwritten pretty quickly by Hype and isn’t of use. In fact, I suspect that all of the values you want are getting overwritten due to the (overly) recursive nature of how Hype updates frames when flexible layout is enabled, right?

Let me know if this analysis jives with your impression, and we can move from there.

That jives. It’s about the last example in the above demo. The parent is changing but the contained flexible layout isn’t updated.

In this screenshot I am inspecting the group container and it’s actually the correct size. Only the contained elements don’t react to the size. So the problem it’s really that values are overwritten. At least from a user perspective.

I made this simple example to illustrate expected behavior vs. what Hype does.

After pinning the inner object to the left/top I’d want it to do this even if I trigger the width change through the API. In the current state of affairs it just sits there and isn’t updated.

UserScale.hype.zip (15,4 KB)


Unfortunately I think the only way to go at this point would be that you would need to define (or re-define) the flexible layout and you would need to manage this yourself. There’s no visibility into the flexible layout system and Hype will overwrite values since it wants to manage them itself (but I will file an issue to not overwrite as much, yet relying on it would still be unsupported).

Thank you… to be continued.