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

needsExtraMainOutlineDrawingForActiveLayer does not yet hide corner/cap components #61

Open
2 tasks
Mark2Mark opened this issue Jan 25, 2022 · 11 comments
Open
2 tasks

Comments

@Mark2Mark
Copy link
Contributor

Mark2Mark commented Jan 25, 2022

When needsExtraMainOutlineDrawingForActiveLayer returns NO, don’t draw:

  • The thick blue component stroke
  • "Color Layer" content (e.g. Stroke, Fill, Shadow, Gradient, etc)
@Mark2Mark
Copy link
Contributor Author

Mark2Mark commented Mar 13, 2024

This still happens, and does not make sense IMO. Hiding the layer drawing should hide all things drawn on the layer.

Here an example with the hiding setting active in Variable Font Preview. You can see how everything is nicely hidden, making way for the reporter’s drawings, but the corner halos still show:

vfp.-.virtual.masters.mp4

@Mark2Mark
Copy link
Contributor Author

any insights on this @schriftgestalt / @florianpircher?

@florianpircher
Copy link

florianpircher commented Apr 10, 2024

The thick blue component stroke is drawn as part of the background by the tool. A reporter only draws additional background content, so that cannot suppress the blue lines.

The same goes for the color layer drawing.

Either we add a new API for a reporter to suppress the background of the tool, or maybe needsExtraMainOutlineDrawingForActiveLayer should also control the background. @schriftgestalt?

@Mark2Mark
Copy link
Contributor Author

Thanks for explaining. Both options would be nice to have.

@florianpircher
Copy link

I think I might have a reporter use case where I don’t want the main outline and color drawing, but the blue corner paths should stay.

To future-proof this, we could offer a new API where a reporter returns an option set like

GSDrawSkipLayerMainOutline | GSDrawSkipLayerColorContent | GSDrawSkipLayerCornerHighlight

or similar.

@Mark2Mark
Copy link
Contributor Author

Should the option set also offer anchors? I think currently they are hidden along with the outlines, if I’m not mistaken. Could imagine cases similar to your blue corners.

@florianpircher
Copy link

It may make sense to consolidate anchors and other stuff like metrics, mark cloud, etc. into the option set. NSUInteger has 64 bits, so there should be more than enough room for any current and future options.

@schriftgestalt
Copy link
Owner

That goes out of hand very quickly. So keep the options low. Also adding things later needs to be done in a way that we don’t need to update all code that uses this to add the new flags.

@florianpircher
Copy link

florianpircher commented Apr 10, 2024

The idea would be to suppress specific, small things per bit in the option set. That way, a reporter can be selective about what it needs suppressed. For common groups, we can offer named constants combining multiple small things, e.g.

GSSuppressDrawingLayerContent = GSSuppressDrawingLayerMainOutline
    | GSSuppressDrawingLayerColorContent
    | GSSuppressDrawingLayerCornerHighlight
    | ...;

Adding things later would not be an issue as we would use the higher, previously unused bits for that. Existing reporters have those bits set to 0, so they would not suppress new things unless they opt into doing so with an update.

The named groups, like GSSuppressDrawingLayerContent can get changed in a Glyphs update, so if a reporter is not selective and just wants to get rid of ”all layer content drawing“ or “all metrics drawing” or similar, those reporters would use the named option groups and be automatically updated to suppress new stuff as it is introduced by Glyphs, as long as the new stuff fits into one of the existing named groups.

@schriftgestalt
Copy link
Owner

But if that extra bit means we do not hide certain things any more (if we e.g. discern between anchor and corner highlights), then all code that relies on hiding both needs an update. Or we need to provide enums with various levels of hiding so that we split a bit but provide the old enum with a new value that triggers both new bits. That is confusing.

@florianpircher
Copy link

The old bit would become legacy. Say bit 3 hides anchors and corner highlights. Reporters use bit 3. Time passes. We now want to discern between the two. Bits 0–5 are already assigned. So bit 6 becomes anchors and bit 7 becomes corner highlights. For backwards compatibility, if bit 3 is set, we assume 6 and 7 are set.

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

No branches or pull requests

3 participants