-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[core] Port symbol-z-order symbol layout style spec property #12783
Conversation
I know I will need to change the submodule to point to a commit on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow so much boilerplate for such a simple change! Thanks to everyone who implemented all the codegen tools...
Overall this looks great. I had one nit about variable naming, and then the other thing (and something I'm still trying to get disciplined about) is that the native SDK teams would like us to include CHANGELOG entries with each PR (in macOS/iOS/Android/Node).
src/mbgl/layout/symbol_layout.cpp
Outdated
const bool mayOverlap = layout.get<TextAllowOverlap>() || layout.get<IconAllowOverlap>() || | ||
layout.get<TextIgnorePlacement>() || layout.get<IconIgnorePlacement>(); | ||
const bool zOrderByViewport = layout.get<SymbolZOrder>() == SymbolZOrderType::ViewportY; | ||
const bool mayOverlap = zOrderByViewport && (layout.get<TextAllowOverlap>() || layout.get<IconAllowOverlap>() || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Maybe we should follow gl-js and rename mayOverlap
to something like sortFeaturesByY
? The flag now encodes more information than just whether they can overlap...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🍏 🚀
d985ad8
to
d7dd816
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is pretty awesome – it accounts for the difference between puck-like and pin-like markers, which are both very common in mobile applications.
The feedback below largely pertains to improvements we could make to the iOS/macOS API for consistency with Apple APIs. It’s very much a fit-and-finish thing, one that we’d either do in the same release as this PR (perhaps as tail work) or not at all.
Symbols will be rendered in the same order as the source data with no | ||
sorting applied. | ||
*/ | ||
MGLSymbolZOrderSource, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on similar enumerations in Apple frameworks, perhaps names like MGLSymbolZOrderByScreenY
(“relative to their y positions in the screen coordinate system”) and MGLSymbolZOrderBySource
would be more familiar-sounding to iOS/macOS developers.
Unfortunately, platform/darwin/scripts/style-spec-cocoa-conventions-v8.json only offers a way to override the names of properties, not enumerations. Maybe overriding the value names in platform/darwin/scripts/style-spec-overrides-v8.json would work, but I’m not certain. On the other hand, these enumerations are not nearly as prominent as they once were, now that expressions can accept embedded string literals.
/cc @friedbunny
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I tried overwriting the enum names and descriptions in style-spec-cocoa-conventions-v8.json but instead of overwriting the existing enums, it simply added two new ones. In other words, there would now be MGLSymbolZOrderSource
and MGLSymbolZOrderBySource
so I'm not sure this is possible with the current setup, unless I'm missing something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, looks like you’re right. I guess it isn’t worth building out the capability to override individual enumeration values, given that the literal string values are more common and can’t change anyways (since they can be built up through concatenation etc.).
/cc @friedbunny
`$zoomLevel` variable or applying interpolation or step functions to feature | ||
attributes. | ||
*/ | ||
@property (nonatomic, null_resettable) NSExpression *symbolZOrder; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For what it’s worth, Apple frameworks like MapKit avoid the terms “z-order” and “z-index” in favor of circumlocutions like “overlay level” (see MKOverlayLevel
, NSWindowLevel
), while “z” is reserved for non-discrete values. Meanwhile, there’s also a concept of sorting in the standard libraries, as seen in NSSortDescriptor. But maybe “z order” is more discoverable in this case; not sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ZOrder
does indeed look strange in Cocoa — since we try our best to follow platform conventions, I’d be in favor of renaming iOS/macOS methods/properties. Docs could still reference “z-order”.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to target only the iOS/macOS names? I'm not really familiar with the Native codebase yet but I'd be happy to open a new PR to fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, each entry in platform/darwin/scripts/style-spec-cocoa-conventions-v8.json overrides a property name.
platform/ios/CHANGELOG.md
Outdated
@@ -2,6 +2,9 @@ | |||
|
|||
Mapbox welcomes participation and contributions from everyone. Please read [CONTRIBUTING.md](../../CONTRIBUTING.md) to get started. | |||
|
|||
## master | |||
* Add `symbol-z-order` symbol layout property to style spec [#12783](https://github.com/mapbox/mapbox-gl-native/pull/12783) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The iOS and macOS changelogs typically refer to style properties as they’re exposed in the runtime styling API, which is the primary way that these developers control the properties. There also isn’t much of a distinction between paint and layout properties in the runtime styling API.
Added an
MGLSymbolStyleLayer.symbolZOrder
property for forcing point features in a symbol layer to be layered in the same order that they are specified in the layer’s associated source.
MGLSymbolZOrderViewportY, | ||
/** | ||
Symbols will be rendered in the same order as the source data with no | ||
sorting applied. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specify this z order if the order in which features appear in the source is significant.
*/ | ||
typedef NS_ENUM(NSUInteger, MGLSymbolZOrder) { | ||
/** | ||
Symbols will be sorted by their y-position relative to the viewport. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In platform/darwin/scripts/style-spec-overrides-v8.json, we should be able to override this to say:
Specify this z order if symbols’ appearance relies on lower features overlapping higher features. For example, symbols with a pin-like appearance would require this z order.
d7dd816
to
7c5fd38
Compare
81e1655
to
31cca05
Compare
Nice work, congrats on your first commit to |
Ah darn, sorry about that! Thanks for the links. I will make sure I tag everything properly next time. |
Launch Checklist