Scale getter API bug?

Known Issues
1

I think the scale getter doesn’t work properly…

ScaleX.hype.zip (20.2 KB)

2

yeah, i sended a report few weeks ago … guess it’s a bug :slight_smile:

2 Likes
3

The getter/setter API returns values before flexible layout has been applied. Top/left/width/height are the same. This allows for modifying elements in their canonical (aka non-resized) space, and then flexibility is applied afterwards. The goal being to make it easier to reason about element sizing an positions.

Feel free to elaborate on what you’re trying to do; this will help give me an idea on priority for the API providing post flexible-layout metrics.

1 Like
4

I understand the logic…but I don’t understand why you told me to use the API to get the scale if they don’t get the current scale. :confused: I feel lost… :dizzy_face:

Anyway, in my opinion, from an UX point of view this is an unexpected behaviour: without knowing how the Hype framework works is really hard to understand why the value doesn’t update. :worried:

1 Like
5

It would be unexpected in both directions - in fact I can more easily see “why is flexible layout changing my expected values?” being a question if you’re expecting to do hand-made animations through hype’s runtime in a specific manner.

Take CSS for example, if you have a font-size of 12px and then set a scale transform of 150%, you wouldn’t then expect to read back a font-size value of 18px. It is really a matter of what space makes the most sense to work from.

There’s a few principles on why the API is this way:

  1. getting and setting need to use the same values; often a flow is to read a value and set it to some multiple. If the get and set are inconsistent then programming is near impossible
  2. direct access to the Hype runtime
  3. easy conceptual model to control items
  4. low filesize footprint

I do think it makes sense to allow both modes; the main reason this isn’t presently an option is #3 - an extra mode is extra learning - and not every document needs to be concerned with flexible layout, and #4 - being able to do a set requires converting the flexible-layout space back to hype’s canonical space, and frankly that’s a lot of code which doesn’t exist in the runtime that would only need to exist for this feature.

6

@jonathan
i wondered first but came to same conclusion when considering pros and cons.
for example the small pacman game is responsive and it’d be horrible for sthg. like this to get transformed values …

but:
could be something like “use strict”; as a global for a hype function be nice?

lets call it: “use transformed”

so within scripting one could easily switch to what fits his / here needs :slight_smile:

1 Like
7

Yep, at this point is just better have both :slight_smile: so is clear the intention of the API:

hypeDocument.getElementProperty(element, ‘propertyName’, ‘mode’)

Mode values:
0 = Hype runtime (default)
1 = DOM

What do you think about this? :smiley:

1 Like