[OBSOLETE] Hype GridBuilder (Alpha, Proof Of Concept)

Extension Project
1

20190809-6pkke(2)
20190809-6pkke(2).png1856×1200 85.4 KB

PROJECT OBSOLETE. HYPE CAN DO IT NATIVLY! :man_facepalming: :upside_down_face:

Use stretch and only scaling on groups (no pinning)! I am leaving the code up just as reference on how I was going about this. But you don’t need it.

**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..

Download
HypeGridBuilder.zip

Demo
HypeGridBuilder.html

Versionhistory
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?*
3 Likes
2

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…

3

Hi Max!

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

Thanks.

4

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
5

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

20190812-5uzrq
20190812-5uzrq.png1268×1458 67.4 KB

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.

6

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

1 Like
7

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
8

Thank You for clarifying!

9

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:.

10

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.

11

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.

12

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

20190813-4laex(1)
20190813-4laex(1)1863×1358 92.7 KB

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.

20190813-phewr(1)
20190813-phewr(1)1442×944 75.1 KB

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)

2 Likes
13

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).

14

Thank you… to be continued.

15

I was in a Workshop and I just realized through a participant just poking at Hype that this GridBuilder approach of mine is completely obsolete. Hype already can do this beautifully if you remove any pinnings but applying stretching! I think separating stretching and Pining into two fields like in Adobe XD would make that even more clear. At least for me having it all in one panel made me over apply settings all the time (although it’s just simple):

image

16

There it was all the time… Well now I am asking myself the same question! Why was I doing this… Answer all this time later: I was just doing it wrong all the time until today. You already have that little nice preview and I still got it wrong for some years now. Doing complicated and grouped left/right pinning to build multi column layouts.

Update: Example of a proportional complex grid done only in Hype with minimal effort
ComplexGrid.hype.zip (15,7 KB)

3 Likes
17

That works well. And simple once you figure the inner pinning and each element is in a group. I had tried this before with groups but did not get it right.

Nice one

1 Like
18

Also if You deselect the “Zoom contents” the type in a given group (as You have constructed them in your example) will “auto flow” in the container rather than get larger or smaller as with “Zoom Contents”

53%20PM

24%20PM

53%20PM

1 Like
19

Thanks Jim, that one I knew, though. What I always constructed with a left/right approach (using pinning and scaling) was the proportional grid surrounding the content.

20

Yes, Mark same here. So either we are to unpatient or the IDE is the problem. Then again the IDE actually delivers a preview… my hunch is that it is to packed and as everything is in one spot you start combining all settings wild. Also it is always easier to blame it on the software :wink: