Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missed properties for RadialGradientFill #61

Open
GDreyV opened this issue Jul 2, 2019 · 1 comment
Open

Missed properties for RadialGradientFill #61

GDreyV opened this issue Jul 2, 2019 · 1 comment
Labels
enhancement New feature or request

Comments

@GDreyV
Copy link

GDreyV commented Jul 2, 2019

I know that it doesn't have official documentation but we still need to work with it. Please add currently existing properties to unblock current development:

  "isCentered": true,
  "flipScale": { "sx": 1, "sy": 1 },
  "rotationHandle": { "x": 1, "y": 0.5 },
  "degreeRotation": 0,
  "scaleFactors": { "scaleX": 1, "scaleY": 1 },
  "linkId": "",
  "endR": 0.5,
  "endY": 0.5,
  "endX": 0.5,
  "startR": 0,
  "startY": 0.5,
  "startX": 0.5,
  "transformHeight": 0,
  "transformWidth": 0,
  "gradientTransform": { "a": 1, "b": 0, "c": 0, "d": 1, "e": 0, "f": 0 },
  "colorStops": [
    {
      "color": { "a": 255, "r": 255, "g": 255, "b": 255, "linkId": "", "value": 4294967295 },
      "stop": 0
    },
    {
       "color": { "a": 255, "r": 88, "g": 58, "b": 168, "linkId": "", "value": 4283972264 },
       "stop": 1
    }
  ],
  "rotationHandleX": 1,
  "rotationHandleY": 0.5,
  "rotation": 0,
  "scaleX": 1,
  "scaleY": 1
}```
@pklaschka
Copy link
Contributor

Hi @GDreyV,

I understand that this poses a problem for you. However, the decision to keep the typings in sync with the docs stands for three reasons:

  1. Without the docs, I have no idea what type (or "range" of types something actually is. In this example, is the color in the color stop an object, a scenegraph.Color? Are some properties read-only? There simply is no way to know what the actual "specs" are without documentation. Experimenting around how it is simply isn't an option since I don't have the time.
  2. There is – without documentation – no way to create the doc comments. This, however, creates inconsistency and makes the next point even bigger
  3. The most important argument: Maintainabilitiy. Since I'm doing these typings in my spare time, it's difficult enough as it is to keep them up-to-date. And right now, it is still relatively easy as I can just look at the diff of the docs since the last time I've updated the typings and make the changes. If now, I "mix" content that's in sync with the typings and content that isn't, the typings simply become an unmaintainable mess and I'd always have to know what parts are "guess-work" and which ones are in sync.

To be honest, this is a (huge) issue of the documentation. We simply cannot know what types (or "ranges") some properties are. Therefore, I see this as an issue of the plugin-docs, and – since as soon as this gets fixed in the docs, it'll get implemented here – not as an issue with the typings. I understand that this is an issue for you, but please understand that – due to the reasoning above – I won't be able to (willingly) take the typings "out-of-sync". I can (and do) implement things which are not – by themselves – documented´, but clearly documented in another way (this, e.g., is the case for the rendition type constants – I'll fix them in the next typings release), but a completely undocumented class isn't something I can provide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants